By drapeau on Mar 05, 2009
I'm here to learn more about the Drupal community: I intend to learn more about the big problems the community wants to address, their main customer pain points, the technical and non-technical problems they face, how the community works...and ultimately, how Sun can play an important role in the Drupal community.
Sun has a table at DrupalCon, and we're getting a lot more people stopping by the table to talk to us than in previous conferences I've been at. It's a great opportunity for us to learn what people want, and how (or whether) we can help. Lots of people use MySQL, and they pretty much all seem to be aware that Sun purchased MySQL. I was a bit surprised at how many people use VirtualBox, but not everybody knew that It's a Sun product. (so we're telling them, and hearing how they use VBox). General feedback I hear from visitors is that they are glad to see Sun showing support for the Drupal community and for open source in general. I wouldn't say people are rushing to our table, but generally when we ask them questions, they happily stay and talk with us about what they're doing.
Here is what I'm learning so far about why Drupal is so successful: it is simple to extend, by design. (built in PHP, you can get up-to-speed on how Drupal is built pretty quickly and the barriers to you contributing something new are reasonably low) You don't have to contribute code to the core part of Drupal; you can create your own "module" to add new features, or you can contribute themes to help others' web sites look cool. These are lower-risk ways of including the maximum number of people to add to Drupal, and they do. Drupal really wants a lot of people to contribute, and they make it pretty easy to do it.
Also, Drupal is simple to get running; you can have a simple web site running in less than an hour, and you don't have to be a database administrator or a developer to do it.
There is a commercial entity formed by Drupal's founder, Dries Buytaert. That commercial entity, called Acquia, contributes a lot to Drupal but they take steps not to try to assert too much control over Drupal. In fact, of all the committers to the Drupal core, only one works at Acquia (Dries).
Time and time again I have heard from Drupal fans that they see Dries spending a lot of time and energy to make the community open and welcoming; getting people to contribute appears to be a cornerstone of Drupal's direction. I've talked to a lot of people building web sites and asked them why they're at DrupalCon; many of them say they're looking for people to hire, and they use Drupal because it's easy to find developers who already know Drupal. It's your classic developer play: Drupal succeeds in part because they have a larger developer base than competing open source CMSs like Joomla! or Wordpress. I like this aspect because it shows the payoff of spending enormous energy in opening your community; the payoff is a huge ecosystem of features and add-ons, and an army of Drupal-trained workforce that makes it easy for customers to get somebody to build their websites in Drupal for a good price.
I installed Drupal on my OpenSolaris distro, running inside VBox on my MacBook Pro. It took about 20 minutes from start to finish, including the time to download the software, unpack it, read the instructions, activate the WebStack components (MySQL, Apache), and configure the database for Drupal to get going. If I were to do it again, it would take me about 10 minutes to get Drupal going, maybe 5.
Two main themes I'm hearing about what's important to work on for Drupal: simplicity, and performance. Simplicity seems to be the much bigger issue, because Drupal is trying to expand its community by an order of magnitude. They made it easy for PHP developers to contribute and build web sites, but they want to attract people who don't want to learn PHP. Maybe these people know a little HTML, maybe a little CSS, but not PHP. Drupal has to make things even simpler to create web sites with interesting content. Anything to make it easier to install, configure, and run Drupal with a usable set of modules is a huge benefit to the Drupal community.
Performance seems to be not quiet as important, but still plenty worth talking about. For smaller sites that don't get a lot of concurrent users hitting their web sites, performance of Drupal and the underlying software stack on a single server is plenty fine. But when the web site starts to grow its audience, performance issues start to come into play, and I think there's a lot that Sun can do if we can show that we understand how to optimize performance on the whole software and hardware stack, from Drupal on down to the server. I believe we can do that, and more: Sun has some interesting technology to make snapshots and test environments quick, easy, and reliable to do (ZFS comes into play here). And we have a great tool for observing performance of Drupal sites live, in deployment (DTrace). These are not for everybody -- I hear a lot of people saying they don't want to spend their time learning how to do detailed performance tuning, they'd rather spend their time getting web sites live -- but I think that people who see these tools at our BOF on Friday will see how these tools can be a real help.
One nice thing they're doing at the conference is the use of Twitter as a public address system: follow the twitter user "drupalcon" and you get updates about where lunch is being served, parties happening after hours, reporting on status of wi-fi downtime (mostly wireless access has been great, but when it goes down, the DrupalCon people tweet about it right away and ask people to tweet back saying where they find dead spots). When slides get posted to web sites, it's announced on twitter. Same with videos of the talks. Somebody lost a phone; drupalcon tweeted a lost-and-found message. It's a great use of Twitter.
I'll leave this entry with a quote from the opening keynote. It was attributed to Clay Shirky, to represent the approach of the Drupal community: "Replace planning with coordination". Simple example: going to lunch as a group. Before cell phones, if you want to go to lunch as a group you have to talk about it before-hand and plan where you're going to go, because communication is complicated in a group. With web-enabled cell phones, you can call, text, or tweet your mates in real time, coordinating what you're doing right then. Interesting approach; I'd say it's a good summary of the open source way of doing things that I've seen in my own career working with open source.
More soon; the conference is a firehose, and I'm having a blast drinking from it.
Powered by ScribeFire.