You are here
Opinion
On hiring Drupal talent (2)
Because the demand for Drupal talent exceeds the supply, it's incredibly hard to hire talented Drupal developers. In a recent blog post I advised people to hire good Java or PHP developers, and to get them up to speed on Drupal.
In an interview with CNET, JBoss founder Marc Fleury was asked where they found Open Source developers:
We tried once to create an open-source developer out of a normal developer, but it completely failed. We never tried it again. Truth be told, I had an aversion to it. An open source developer is a self-starter. He's competitive - this is someone that wants to prove that they can do something better than you can. As such, it's a great recruitment/qualification vehicle, because you can see their work before you ever think of hiring them. You can see if they'll work out for the company. We definitely took that approach to hiring.
I believe there is a lot of truth in that. First, developers with impressive resumes don't necessarily grok Open Source software development. Second, having experience with Open Source software development is becoming an increasingly valuable asset on any developer's resume. So let me refine my advise:
Hire good Java or PHP developers that are active in the Open Source community (at large), and get them up to speed on Drupal.
On hiring Drupal talent
A lot of people have been looking to hire talented Drupal developers but can't seem to find any. I know because every single day, I get e-mails from people asking me if I know any good Drupal developers looking for a job. Alas, I don't, so please stop e-mailing me.
The problem is that the demand for Drupal talent exceeds the supply. As such, most of the Drupal developers I know are maxed out.
So for months, I've been advising people to hire developers with a formal education in computer science and to train them to become Drupal developers. Hire good Java or PHP developers, and let companies like Lullabot get them up to speed with Drupal. It strikes me as the winning strategy.
But still, it begs the question: how can we grow the pool of Drupal talent and help Drupal companies scale? But also, how can we raise the bar for Drupal professional services firms?
These are important questions to ask so let's collect some ideas and prioritize them by importance, viability and ease of execution.
Growing pains
Growing is learning to take on more and bigger problems. When you were a 4-year old kid, you basically had no problems, except maybe that you didn't feel like eating all those potatoes on your plate. Similarly, newborn open source projects have no problems either.
Once you start school, you might start to lose some sleep over your grades, whether you'll ever make your way through school or why you're not allowed to stay up a little longer at night. Remember how these used to be your biggest problems?
Later when you're done with school, you look back and you realize how ridiculous it was to even worry about your grades. If you'd have to go through school again, it would be the easiest thing on earth, you believe. However, you're now faced with new and seemingly bigger problems: will I ever find the right person to share my life with? How am I supposed to pay the rent? How to raise my kids? How am I going to cope with the loss of a close relative?
So growing is learning to deal with more and bigger challenges. It is no coincidence that the biggest challenges tend to be ahead of you. This is true for your personal life as well as for the life of an open source project.
Right now, Drupal's hardest challenge is to manage its explosive growth. We have raw and untampered ambition but we're left wondering how we can scale our infrastructure with the available resources, how we can attract more top-talent to help get all the work done, how to maintain -- and raise -- the high quality of our work, and how to make Drupal easier to work with. We're also learning how to deal with legal issues, we're figuring out how to better market ourselves, and how to efficiently organize large conferences.
This sounds a lot like "How will I be able to pay the rent?" (infrastructure) and "How can I score more girlfriends?" (more top-talent, easier to use, better marketing). So by that standard, Drupal is a young adult that just moved out from its parent's place. We have many new things to learn and to explore, but we have unlimited motivation and ambition.
I'm convinced that one day we'll look back and realize how ridiculously simple it was to scale our infrastructure, to organize a 400-attendee conference or to better market ourselves at drupal.org. After all, we no longer lose sleep over high-school problems either ...
DabbleDB = CCK + Views + 12 Duvels
Peter Van Dijck sent me a link to this DabbleDB demo, referring to it as "Drupal's CCK and Views after twelve Duvels". :)
Peter is right. DabbleDB is awesome, Drupal can do much of what DabbleDB can do, and has been able to do so for a long time. Witness this one year old Drupal screencast. Where Drupal fails short is in making this functionality easy to use.
I still believe that it is of strategic importance that we move more of the CCK and Views into Drupal's main distribution, as opposed to keeping them contributed modules that you need to install separately. And when we do, we need to look at tools like DabbleDB, as there is a lot to learn from their user interface and interaction design.
I wish we had more people willing to make this happen. I'll be the first in line to help, because together we can get the CCK and Views to the next level.
On being able to be the best
What are your chances of becoming the world's foremost expert on a proprietary content management system (CMS) or on proprietary software in general? Unless you're working for the company owning the software and you get access to proprietary documents or high-level meetings within corporate walls, your chances are slim -— you simply won't get access to all the internal information.
Contrast this scenario with Drupal development, or Open Source development in general. As a developer, you have access to Drupal's complete source code. You can read up on all the discussion that led to any design decisions, and you can tap right into the brains of the best Drupal developers in the world.
Why would you want to provide consulting around proprietary software when you know that you will never be able to truly master what you claim to be an expert in? For people with raw ambition, the thought that they can't become the best must be frustrating.
Not so with Open Source software. There is nothing that stops you from becoming the best Drupal developer in the world. The only limitation is your willingness to learn ...
For me that simple and liberating idea makes all the difference.
Streamlining processes
Mark Celsor, Senior Technologist for Clear Ink, writes on the Clear Ink blog how they use Drupal to streamline the information architecture, prototyping and content gathering process. It's funny because it's true.
PHP is dead ... long live PHP!
People are getting increasingly worried about PHP5's adoption rate. And rightly so. PHP5 has been released more than two years ago. If you look at the adoption rate in the graph below, you see that after more than two years, PHP5 commands for less than 20% of PHP's install base. With the current adoption rate (even if it is assumed to be exponential), PHP6 is dead before it is even born.
PHP5's adoption rate based on data from <a href="http://www.nexen.net/">Nexen</a>.
A naive forecast of PHP5's adoption rate. As the major Linux distributions (RedHat, Debian and Ubuntu) started shipping PHP5 recently, I was optimistic and assumed PHP5's growth to be exponential. Based on data from <a href="http://www.nexen.net/">Nexen</a>.
As Nick Lewis pointed out: PHP is dying, and if we don't migrate to PHP5, the Drupal project will die along with the PHP project. It won't happen overnight, but it might happen several years down the road ... The point? Drupal's success depends on that of PHP.
Part of the problem is that the PHP team has their target audience wrong. If they want to drive PHP5's adoption, they need to make PHP5 attractive to ISPs and end-users, and focus less on application developers.
Many websites use a content management system, a forum or a blog tool and these systems work with both PHP4 and PHP5. And for a long time, they've worked better with PHP4 than with PHP5. I can only talk about Drupal, but from what I've seen, very few Drupal users show incentive to upgrade from PHP4 to PHP5. They are pretty much ignorant to what version of PHP they use, as long Drupal works well.
Isn't the Drupal team interested in using PHP5's new functionality? Sure we are. We'd love nothing more than to drop PHP4 support and to use PHP5's new functions. Unfortunately, we are dependent on our users too, and these users don't care about better OOP support, SimpleXML, PDO, DOM, etc. The only things they care about are performance, stability, compatibility and security.
If the PHP team would show that existing applications run faster by upgrading from PHP4 to PHP5, ISPs and end-users would have a strong incentive to upgrade. However, last time I checked, PHP5 was slower than PHP4. For anonymous users, Drupal is 13% slower with PHP5 than with PHP4. For authenticated users, this difference is only 4%. In other words, this gives them a good reason not to upgrade to PHP5.
If the PHP team would show that PHP5 is more stable than PHP4, people might start to care. Unfortunately, PHP 5.0 was rather buggy and less compatible than hoped for. Even today, PHP5.x+APC feels less stable than PHP4.4+APC.
Anyway, it is all about targeting the right users, and giving them a compelling reason to upgrade. Convince the ISPs and the applications' users to upgrade, not only the application developers. It would help us break out of this chicken-and-egg problem.
That said, the Drupal project can't just stand here and watch. Drupal's success depends on that of PHP, and PHP5's slow adoption rate is becoming annoying. So let us help the PHP project by giving Drupal users a compelling reason to upgrade to PHP5:
For example, let us start with making the module update notification feature, scheduled for inclusion in Drupal 6, depend on PHP5's SimpleXML parser. It is likely to upset some of our users and developers, but by giving back to the PHP project we help serve a bigger cause. After all, we really want PHP to shine.
And if projects like Wordpress, Joomla!, Typo3, phpBB, Gallery and phpMyAdmin would do the same (if not already), we can help drive PHP5's adoption before it might be too late ...
