Opinion
8 steps for Drupal 8
The Drupal 7 code freeze triggered a lot of retrospective about Drupal core, and the Drupal core development model. Some of these discussions are collectively referred to as "smallcore".
While I'd prefer to postpone such a retrospective until after Drupal 7 is released and we're about to open up the Drupal 8 development branch, the discussion is already beginning on the web, and it is my responsibility to internalize people's thoughts and recommendations.
I've brainstormed about this a lot the last couple of weeks, and talked about it with various people. In this post, I propose 8 steps to help improve Drupal core development going forward. Some of these steps make Drupal better for end-users, some of these steps make Drupal better for developers, and other steps focus on making Drupal a better product. They might not address every concern that has been raised, but I hope they make for a good start and that they provide some focus.
We'll obviously have more thinking and brainstorming to do about Drupal 8. I'd like to thank everyone for their suggestions, for bearing with some of the growing pains, and for helping us raise our game. It is what makes Drupal so great.
The 8 steps are as follows:
- Create better separation between framework and product
- Grow Drupal by making it a better product
- Select two strategic co-maintainers
- Distributions could help, if we do them right
- Experiment with distributed revision control systems
- Backport small changes to stable releases
- Continue to streamline the patch review process
- Aim for a shorter release cycle
Step 1: Create better separation between framework and product
As people start to build more products on top of Drupal, it is important that Drupal doesn't get in the way, and that it provides the flexibility and ease of customization for Drupal distribution builders. Drupal has always been king of flexibility, and missing or poorly designed APIs have always been considered and treated as bugs.
The current state of affairs is that, while Drupal is super-flexible, we do have some hard-coded assumptions, and not everything can be reused or replaced. Clearly the work on improving our APIs needs to continue, and creating better separation between the framework and the product will continue to be one of our goals during the Drupal 8 release cycle.
Over-engineering is a real threat though. When people fall in love with framework design, they tend to decouple everything, abstracting it up, down, and sideways. Before you know it, you end up with abstractions that make Drupal harder to develop for, and that could make Drupal a lot slower. When looking for a Drupal 8 co-maintainer, I'll look for someone who can help us walk this fine line. More on co-maintainers below.
I also don't like the term "smallcore" as a term for this work. First, the term seems to drive a wedge in the community -- which I don't support. Second, the term is misleading and deceptive as core is more likely to get bigger as we improve our APIs, add more subsystems and potentially add more features. Third, the term alarms people who see the value in having a strong Drupal product, as it sounds antithetical to that goal. Let's stop saying "smallcore".
Step 2: Grow Drupal by making it a better product
Drupal 7 became more mature as a framework but it is also shipping with new features, as well as a lot of usability improvements that help make Drupal easier to use for content editors and site builders. A number of people are wondering how to undo some of the usability changes, and now dream about an "easy to undo" CMS. Making the framework better is a great goal, but not at the expense of our users.
The single biggest barrier to the success of Drupal is its ease of use. This is repeatedly shown in studies, competitive comparisons and blog posts. The broader market is impeded by Drupal's usability, and not with the fact that Drupal isn't a good framework. It is a fact. This is why usability was the primary focus of Drupal 7, why I decided to hire Mark Boulton, and why this is worth making some trade-offs for.
To focus only on the power and flexibility of the framework mainly serves to keep the Drupal insiders happy, while the market and customer base passes them by to adopt tools that do not need their specialized skills because other products solve the market's needs out of the box.
There is a long history of how successful software projects evolve. In the end, there is only ever one winner in a market segment, and typically one runner-up. Everyone else becomes irrelevant in the big picture. This is true for desktop systems (Microsoft/Apple), server systems (Unix-Linux/Microsoft), ERP systems (SAP/Oracle), databases (Oracle/Microsoft) and so on ... It is what will happen in the CMS market too. My goal as the project lead, is to lead Drupal to become the dominant web platform. We do not want Drupal to be irrelevant.
We should all agree that at the end of the day, success should be measured by the number of people working with Drupal, not by the number of people working on Drupal.
A lot of the motivation for current discussions comes from frustrations with the core development process. I would like to shift the discussion, reframe the conversation, and focus on our goal to make Drupal the number one web platform. Fortunately, creating a better separation between the framework and the product aligns with that goal, but just focusing on making the framework better won't make us succeed. We should focus on making Drupal core a better and easier to use product as that is the number one barrier for Drupal's wider adoption.
We cannot afford to let Drupal remain a niche platform. Any user or organization that depends on Drupal also depends on Drupal's ability to grow. Failing to grow and improve will mean that the easier-to-use CMS competition will pass Drupal by as those products mature. This is what I called the The Ockham's Razor Principle of Content Management Systems back in 2006 and why I'm obsessed with driving both innovation and usability -- even if they sometimes seem to be at odds. I feel very strong about that vision, and can only conclude that so far, it has worked -- we've come a really long way since 2006.
If we want Drupal to be relevant longer term, it needs to be a capable, robust product that people can use out of the box. Distributions can exist to meet different market segments, but they need to build on the usability patterns set by Drupal core, as that is how we lower the total cost and risk of adoption of Drupal solutions.
Step 3: Select two strategic co-maintainers
Every Drupal release has had one or more targets for improvement. Drupal 5 focused on the installer, Drupal 6 focused on internationalization, and Drupal 7 focused on usability. Why? Neil Drumm (Drupal 5 co-maintainer) cared deeply about the installer, Gábor Hojtsy (Drupal 6 co-maintainer) was and still is passionate about internationalization, and Angie "webchick" Byron (Drupal 7 co-maintainer) cares deeply about usability. This isn't a coincidence -- I picked them with strategic objectives in mind.
I think Drupal 8 needs to have two general areas of focus, as reflected by "Step 1: Create better separation between framework and product ". To this end I am considering picking a Core framework co-maintainer and a Core product co-maintainer. The role of the Framework co-maintainer would be to tend to APIs and base level tools, and help steer us to our goal of achieving better separation between the framework and the product. The role of the Product co-maintainer would be to make Drupal the best CMS in the world, by increasing usability and adding and improving features. My role in this plan is to assist and manage both co-maintainers, and to help with decision making, vision and product management.
By picking and empowering two people, and assigning them separate areas of responsibility, all the while coordinating with both of them to guarantee a unified product at the end of the day, I hope to increase the velocity of development for the Drupal 8 release cycle. I also intend to accomplish the goal of making Drupal easier to use, more feature rich, and at the same time more architecturally flexible.
When looking for Drupal 8 Framework and Product co-maintainers, I'll look for people who share that same vision -- but who challenge me at the same time. A number of people come to mind, but is too early to share my current thinking. Watching people during the code freeze is a very important part of the recruiting process. After all, managing bug fixes, saying "no", and stabilizing the code base will end up being a critical part of any co-maintainer's job, especially after the development phase when the branch goes into maintenance mode.
Step 4: Distributions could help, if we do them right
So how do we improve Drupal as a product? We've had Drupal distributions since the Drupal 4.6 era and I first wrote about the potential of Drupal distributions in 2005. Drupal distributions have great potential -- turnkey solutions help us compete in new and different markets, something that could help Drupal become a significant player. The number of verticals is nearly unlimited and the opportunities are numerous.
There is a risk involved with distributions as well, which means that we need to approach them the right way. The risk is fragmentation, and it is why I feel it is important that distributions build on the usability patterns set by Drupal core. Distributions will be most helpful if they are tools that give you a head start towards building a particular type of Drupal site. Distributions that steal focus away from Drupal, or become hard to administer and extend using Drupal core usability patterns, will lead to fragmentation.
Drupal has a lot of momentum today, but we are still a niche player in the bigger CMS market. Drupal feels bigs, but we're still small. If by enabling more distributions all we do is create a lot of inconsistent niche products, some of which will be competing with one another, the Drupal project will lose momentum. If we can build competitive distributions that strengthen and accelerate the shared Drupal brand by using shared design patterns and user experience, we'll win.
Another risk is that small incompatibilities among distributions can drive distributions further and further apart. When distributions start building their own communities of contributors, having their own issue queues, all disconnected from drupal.org, then we have a problem. The difference between a distribution and a fork can be subtle. A proliferation of incompatible, incomplete and disconnected distributions could quickly become problematic. It would make it a lot harder for all of us to support and market Drupal.
We have written a lot of the the packaging scripts needed to put distributions together for Drupal.org, but we haven't decided yet how we want to use it and what a winning strategy could look like. What remains is a strategy discussion, not a technical discussion.
As a community, we have to take responsibility, and make sure that distributions collaborate rather than compete, much like the way that we attempt to work together on modules. That starts by centralizing all the code on drupal.org, by making Drupal core flexible enough, but also by encouraging shared design patterns and user experience. With distributions, community responsibility and leadership becomes even more important. Building one product is hard. Building a set of products in a way that strengthens and accelerates Drupal is much, much harder.
Step 5: Experiment with distributed revision control systems
If the road to success is making Drupal a better product (along with making it a better framework), we need to be able to add new features to Drupal core.
Some features in Drupal core, like forums, blogs, polls and aggregator, haven't evolved as fast as the Drupal framework itself. For many people these modules are fine as they are, but more advanced alternatives have emerged in the contributed module repository. It begs the question: should we advance the modules in core or are they sufficient for 80% of our users? But also; are there any modules that we should be adding to core to make Drupal a better product?
I think we should advance those modules, and add some more. This is what I want the Product co-maintainer to help me with.
Giving more CVS write accounts or splitting core in smaller projects could help those modules advance faster, but it will also hurt us. A much better implementation to accomplish the same goal seems to be to experiment with distributed revision control systems. There are various technical issues to sort out to make this feasible, but I think it is worth the experiment because it will allow us to interact in new ways; ways that empower individual contributors, ways that allow people to self-organize around features, and that enable me to pull in bigger changes in a controlled fashion so we maintain consistency, quality and vision. To do it in a way that I'm comfortable with, it will require a significant investment in the project module and the Drupal.org infrastructure though.
In other words, I see myself experimenting with a distributed revision control system like Git or bzr. Not immediately, but somewhere in the Drupal 8 development cycle. Right now, I want everyone to be laser focused on getting Drupal 7 out. At least initially, I'd want the CVS repository to be the main, canonical repository from which Drupal core is packaged. However, I'd additionally pull in changes through Git/bzr for some period of time, to help decide if Git/bzr is what we want.
Step 6: Backport small changes to stable releases
Some people suggested that the framework and the product could move at different speeds. I am uncomfortable with that concept.
Feature development drives API advancements. API improvements drive new and better features. It's an important feedback loop. My conviction is that feature development and API development are so related that it would be detrimental to try to do them asynchronously. Drupal's APIs have been changing for 10 years and there is no reason to believe that they will all be stable one day.
That said, there might be certain changes, like smaller usability improvements, standalone features, or new hooks that don't break existing code, that could be backported to previous Drupal releases during the development cycle. Of course the changes cannot break any code or invalidate existing documentation, but I think having a good test harness will help. Going forward, I'd be comfortable backporting certain changes that help Drupal advance, as long it is transparent to existing Drupal installations.
Step 7: Continue to streamline the patch review process
A key problem still seems to be that it is difficult to get solid patch reviews, making it slow for some patches to get committed. Finding solid reviewers is hard, especially as Drupal becomes more advanced. I still believe this is a primary source of frustration, and that we should continue to streamline the patch review process.
We've introduced new rules in the patch review process lately (e.g. wrapping at 80 character length, formatting of PHPdoc, capitalization rules, etc). The proliferation of rules makes it more difficult to get your patch in. As a frequent reviewer and committer, I've found that code-style reviews, while important, can add quite some noise to an issue, and that it can derail API and architecture review.
One way to streamline the patch review process is to automate code style reviews just like we automated testing -- at least to the extend possible because coding standards can be both complex and subtle. In an ideal world, code style reviews would take almost no comments, and would be reduced to a green or red status message just like with our automated testing. It could reduce the size of the 'needs review' queue further to things which actually merit review etc. By doing so, it would provide more focus, and help improve our velocity.
It doesn't necessarily solve the problem that one can't find enough good reviewers for one's patch but I think it will help.
Step 8: Aim for a shorter release cycle
There is a sentiment amongst developers that the Drupal 7 core release cycles was too long. It can make it frustrating to contribute to Drupal core development. Who wants to work on a feature that might not be used in production for another 18 to 24 months? Near the end of the code freeze, things heat up, and people submit a lot more patches. In other words, shorter release cycles could make it more compelling to contribute.
At the same time, I don't think the Drupal 7 release cycle was too long, per se. A lot of the big new features, such as the new database abstraction layer and Field API (formerly known as Content Construction Kit (CCK)), took several months of work, and many months more to be usable. We finished converting code to the new database abstraction layer over a year after the initial commit. Drupal 7's Field API is probably the biggest architectural change in the last 5 years -- it will take a couple more major releases for Field API to be truly integrated into Drupal. In other words, sometimes we need a longer release cycle to allow for big, game-changing changes.
How long the Drupal 8 release cycle will be I can't say yet, but let's aim for a shorter release cycle. The length of the release cycle depends on how fast Drupal 7 is adopted, how fast the contributed modules reach the "plateau of productivity", and how fast Drupal 8 shapes up to be a great release. You don't want it to be too long, but you don't want it to be too short, either. Furthermore, as a goal, the length of the release cycle shouldn't trump the larger, overarching goals of any given release. I'll take constant temperature of where we are and balance all the different pros and cons (eg. innovation versus stability).
Another adjustment to the release cycle could be separate code freezes for the Framework (APIs) and the Product (user features and usability). The Framework/API freeze would precede the Product/CMS freeze, and would let us focus on establishing the underlying changes earlier in the overall cycle, with focus shifting to features and usability later in the cycle. This will make feature development easier as the APIs will not be shifting around as much, and it will give a period of time after the Framework freeze where we can focus on bugfixing and performance improving the Framework, even while new features are still being developed.
Some closing thoughts
The 8 steps outlined above describe actions and steps that we can take to help make Drupal 8 rock. As we look forward to Drupal 8 development, I think it is important to focus on the right things. If we want Drupal to win and prevent Drupal from being stuck as a small player in the bigger picture, we need to focus on making Drupal easier to use for both end-users and developers, while maintaining our innovative edge. Some of these 8 steps make Drupal better for end-users, some of these steps make Drupal better for developers and some of these steps make Drupal a better product. I truly believe we can all win.
Drupal is a young adult
In my DrupalCon Paris presentation I talked about what it means for Drupal to grow up -- and I wanted to elaborate on that a bit more in this blog post. I hope that the analogy that I'll use in this post can provide a framework for thinking and discussion about it.
We, as a community, are growing up and there is not much you can do about it.
If you're my age (currently 30 years old), sometimes you remember how great it was when you were in your teens. Unfortunately, you have no choice to grow up: you can't roll back time nor freeze it. I think this will ring true with most of us, and frankly, the same is true for Drupal: Drupal is growing up, and we have no choice but to grow along with it. Growing up is inevitable. Life changes every day and excessive nostalgia kills happiness.
So if Drupal is growing up, where is it in its life?
For me, Drupal is a young adult in the early phases of its professional career. Drupal is fresh out of college with A-grades, did some highly-visible internships while in college, landed its first job in a high-profile company, and built up some initial work experience. He has everything it takes to become successful, but being a junior team member, hasn't yet proven himself in a big way. He has the raw talent to become a key part of the business. In fact, his first promotion is just weeks away, and it remains to be seen how he'll handle some additional responsibilities. Either he is happy with his life as it is, and takes it the easy way, or, instead, embarks on a bigger career path in a somewhat naive but admirable desire to conquer the world.
But, enough with the analogies. For Drupal, growing means we must continue to innovate at the framework layer by improving our code, our tools and our developer workflows. We have to continue to do what we have been doing the best. But, there is also a really big "and" that is key to us growing up ...
As a community, we have to embrace increasingly more end-users, content editors, designers, usability experts and organizations. It may sound obvious, but we have to learn to build software for the people that are our users, rather than mainly designing for ourselves like we've always historically been doing. We, developers, should be the primary target audience of "Drupal: the developer framework" and we should continue to invest heavily in it. But end-users, and content editors in particular, have to be the primary audience of "Drupal: the content management system". Both areas have to thrive and work together. We can either succeed at making that happen with a somewhat naive but admirable desire to conquer the world, or we can fail at making that happen and remain insignificant in the bigger picture.
There is a lot of richness in the Drupal platform that we haven't really figured out how to package in order to reach many more people. Drupal 7 will hopefully be a big help with that, but we'll need to continue that trend with Drupal 8 and beyond. Doing so may provide some initial discomfort as we break out of our traditional mindsets, but it is also tremendously exciting. It's like getting a promotion.
At the end of the day, it is all part of growing up and part of Drupal's natural evolution as a product and technology. Growing up is inevitable -- you can't freeze time. Part of growing is learning to take on more and bigger problems. 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. Being a young adult is one of the most exciting times of life, and is filled with lots of changes. What's not to like?
Maybe in a few year's time, I'll write about how Drupal is getting married, and that they are talking about getting kids. ;-)
State of Drupal (September 2009)
Two weeks ago at DrupalCon Paris, I gave my traditional state of Drupal presentation. The video of the presentation is available from archive.org, and you can download a copy of my slides (PDF, 8 MB) as well.
I don't want to give away the spoiler, but essentially, the state of Drupal is strong. :) We should be really proud of what we have accomplished with Drupal 6, and what we're about to accomplish with Drupal 7. In the presentation, I also talk about what it means for Drupal to grow up, and what the next phase of our life will most likely look like.
CIOs are starting to take notice of Drupal
Drupal.org recently featured a detailed use case about InterMedia Outdoors switching to Drupal. InterMedia Outdoors boasts a network of 16 websites, a portfolio of 15 magazines, 25 market-leading television productions, 2 syndicated radio shows, and more.
What the use case didn't mention is that they are migrating off of FatWire, a proprietary web content management system (WCMS) that is Forrester's current poster child in the Q2 2009 Forrester Wave for "Web Content Management For External Sites". To me, that is the most interesting part because it means that Drupal is starting to disrupt traditional web content management systems, including the leading ones.
In other words: CIOs are starting to take notice of Drupal.
Many of the proprietary content management systems are difficult to customize, expensive, hard to set up, and slow to adopt new trends. Contrast that to an Open Source solution like Drupal and you get the exact opposite: all the code is made available, anyone can change it, it is very extensible, well documented, and massively adopted. Developers are plentiful, it is bleeding edge, and best of all, there is no license fee -- which matters a great deal in today's economy.
Furthermore, on the business side, Open Source companies get a ton of sales and marketing for free while proprietary vendors presumably have to put more resources into sales and marketing. In other words, Open Source companies should be able to win on all fronts: technology, sales, and marketing. And we do -- I see it in the Drupal community every day.
But no matter how many times we've whacked proprietary vendors over the head with a foam clue bat, some still think that open source is a fad. That is why it is good to see organizations move from proprietary systems to Open Source solutions.
Excited about this event, I reached out to Howard Stevens, the CIO of InterMedia Outdoors. In an e-mail conversation, he asserted the following:
"The primary reason that we selected Drupal is the extensive flexibility that it provides us to enhance our sites over time. While we are very excited about the launch of In-Fisherman, we also recognize that it is a work in progress--the digital media landscape is evolving so quickly it was important for us to implement a content management system that enables us to continually improve our sites without the constraint of vendor roadmaps and proprietary code. The transparency of Drupal’s source code and engaged developer community ensures that any deficiencies in the code are quickly discovered and remedied, new features can be developed as necessary, and we will always retain the flexibility to keep our sites on the cutting-edge."
While use cases like InterMedia Outdoors are really helpful in convincing CIOs, we need to think about more and different ways to encourage CIOs to abandon their proprietary web content management systems. A common misconception among CIOs is that Open Source solutions require a lot more customization and development than proprietary CMS solutions. Howard Stevens wrote:
"One of the hurdles that dissuaded us from implementing Drupal originally was our very small in-house development team. The promise of an out-of-the-box proprietary solution was appealing as it seemingly mitigated the majority of the development risk and complexity. In reality, Drupal was much more effective at helping us manage those risks ..."
The reality is that with 4000+ contributed modules, Drupal has access to a lot more pre-built functionality than any proprietary CMS. Additionally, the number of developers who actively develop in Drupal combined with the number of developers who possess the prerequisite skills (and the plethora of published materials on developing in Drupal) greatly outnumbers the skilled resources with knowledge of nearly every proprietary CMS.
The point here, is that CIOs often look at Drupal differently than developers do. It is less about the technology, and more about finding ways to save time and money and to mitigate risks. Personally, I think the combination of commercial-grade support, Drupal distributions, electronic services and a healthy ecosystem of expert Drupal shops are key in removing barriers for CIOs. Other barriers to overcome include lack of a roadmap (I don't want to fix that), licensing issues (increasingly better understood), training and certification, and of course, functional gaps.
Personally, I'm most interested in identifying the functional gaps because closing those is what the Drupal community excels at. Whatever the functionality gaps, I'm confident we'll close them over time. If you're a proprietary vendor, you can't say we didn't gave you an advance warning. ;-)
State of Drupal presentation (March 2009)
Last week at DrupalCon DC I gave my traditional state of Drupal presentation in front of 1400 Drupalistas. The video of the presentation is provided below, and you can download a copy of my slides (PDF, 20 MB) as well. The video is available in alternative encoding formats from archive.org. Topics I talked about: the history of Drupal, the Drupal 7 release, the future of Drupal, etc. Have a look!
Source: archive.org.
My predictions for 2009
It is that time of year again. Time to reflect on 2008, and to put on my Drupal Nostradamus hat and look forward to 2009. But first of all, thanks for 2008! It's been a pretty crazy ride.
Drupal
My personal Drupal highlights for 2008 include the Drupal 6 release (the best Drupal release ever!), both DrupalCon Boston and DrupalCon Szeged, the Drupal.org redesign that is in progress, and, of course, beating Joomla and Wordpress at the Packt awards. ;-) As I predicted last year, more than ten books were written about Drupal, compared to a single book in 2007. The increase in Drupal books is another highlight as I actively helped connect authors to publishers. I truly enjoyed being part of the Drupal community in 2008.
My personal low for 2008 is regret that some key modules lagged behind the Drupal 6 release. The majority of these modules have now been released, and Drupal 6 is finally getting on the fast lane now. The message is clear: we'll continue to see tremendous growth and adoption in 2009.
Why?
- Drupal 6 is easier to use, runs faster, and comes with many great new features. The work we did on Drupal 6 throughout 2007 and 2008 will pay off in 2009.
- Economic pressure will help accelerate Drupal's growth, and that of Open Source in general. More site owners will discover that with Drupal, you can build a better website cheaper than with many of its proprietary counterparts.
- Social publishing (blogs, forums, wikis, social networks, etc.) will become more pervasive and continue to make inroads in organizations seeking to facilitate collaboration between teams and departments. These applications, while nothing new, make many aspects of business better, are here to stay, and will mature over time. Drupal continues to be in that sweet spot.
I'll continue to have a software love affair with Drupal in 2009. At the moment, I'm very excited about the community's growing interest in the semantic web -- and all the related interoperability and decentralization technologies. The seed of what I hope will become a strong marriage between Drupal and semantic web technologies was planted in my DrupalCon Boston 2008 keynote in February (with the help, hard work and preparation of many others), and will continue to grow in 2009. Drupal continues to be a technology pioneer in 2009.
I predict that Drupal 7 will be released in the fourth quarter of 2009. The two most exciting features in Drupal 7 core will be custom content types and radical improvements in usability. To reduce the risk of important modules falling behind in support or update path, a significant portion of the Content Construction Kit (CCK) related modules will move to core and we'll pave the way for the Views modules. The same holds true for other important contributed modules, including token module, path auto module, and image handling functionality. In 2009, core becomes bigger, not smaller. The Drupal 7 code freeze will be longer than expected regardless our new continuous test framework, and the upgrade path to Drupal 7 will be more painful than hoped for. But like always, we'll come out stronger than before ...
Despite Drupal being loved by many, we'll have to work hard in 2009. The thing that holds Drupal back is failure to execute many of the ideas and plans that we have. As a community, we need to grow more mentors in 2009, and we must all make sure that they are set up for success rather than failure. The community's responsibility to itself should be to remove barriers to participation and single points of failure. Alarm bells should go off when there is a desire to introduce red tape, unnecessary hurdles or dependencies, or when we fail to collaborate and make progress in key areas of the project. At the same time, we need to help more Drupal companies figure out how to contribute back to Drupal in substantial ways. Contributions are gold, talk is silver. Helping people contribute must become platinum.
Last year, I predicted that we would see the first signs of consolidation in the Open Source CMS market. I believe that prediction was correct. The "big three" (i.e. Wordpress, Joomla! and Drupal) continued to grow in 2008, while many of the other systems faded into the background a bit. I think that trend will continue in 2009. In the long run, the winners will be platform providers that enable people to connect, create and share value in different ways -- and that do so with the lowest barrier to entry. Expect other systems to (continue to) attack Drupal from both below and above. We're the best platform today, and others will have to move in to stay viable.
Oh, and IBM starts to embrace Drupal in 2009!
Acquia
I'm proud of Acquia. Acquia is the Drupal company that I started with Jay Batson. We announced the start of Acquia at the end of November 2007, and we announced our funding just before the end of 2007. People had a lot of questions about Acquia early in 2008, but throughout the year we demonstrated over and over again that we're committed to Drupal's success and that we want to do what is right for the community. We built a great team and grew from 2 employees early in the year to 30 people today. In September 2008, we launched our first products and started to offer commercial support for a defined software distribution called Acquia Drupal. Today, 3 months after we opened to doors for business, we are serving customers. We worked hard and made our milestones. It has been fun to see a new business take off. I also racked up way more frequent flyer points (i.e. air miles) than what is generally considered healthy.
The first thing you learn when selling in tough economic times is that you must figure out how to give customers exactly what they want and you must do it fast. It didn't take long for us to realize that people wanted more than Acquia Drupal: they wanted support for everything Drupal 6.x -- all modules, themes and custom code. The good news is that Acquia is a nimble company so the last weeks we worked on changing our support model to address customer demands. Starting tomorrow, we will support everything Drupal 6.x -- not just Acquia Drupal but all modules and themes available on drupal.org as well as custom code. I'm still a firm believer in Drupal distributions so Acquia Drupal still has a role as a packaged on-ramp for people getting started with Drupal. However, anyone will be able to connect any Drupal 6.x site to the Acquia Network -- helping us achieve our goal of helping people build and operate great websites with Drupal. Keep an eye on acquia.com if you want to learn more about these changes.
We're passionate about getting our value proposition right, so expect us to continue to tweak and extend our current offering in 2009. We'll also launch a number of new products. Some, like our hosted search service, we've already talked about, and I think we'll finally be ready to talk about a few others in the first quarter of 2009.
Regardless of the down-turn in the economy, I think that Acquia's business will continue to take off nicely in 2009. My heart and gut are convinced that Acquia has a tremendous opportunity to do well, and to do good. I believe (and hope) that Acquia will have the success it takes to continue to invest in Drupal.
Mollom
Together with Benjamin Schrauwen, I also launched Mollom, a web service whose purpose is to dramatically reduce the effort of keeping websites free of spam and the quality of user-generated content high. Mollom is a self-funded company and nowhere near the size or scope of Acquia (Acquia is my full-time commitment) but nevertheless, a lot of progress has been made. We announced Mollom in March, and opened the doors for business at the end of September 2008. Today, we're actively protecting 4,500 websites of which 75-100 have paid subscriptions. Mollom has caught almost 21 million spam messages since it started.
In 2009, I predict that Mollom will continue to experience steady growth and that we'll introduce a premium subscription (i.e. "Mollom Premium" in addition to "Mollom Plus" and "Mollom Free") with enterprise level features. I also predict that our efficiency in blocking spam will raise from our current 99.88% (i.e. 12 in 10,000 spam messages were not caught) to 99.95% or more (i.e. 5 in 10,000 spam messages or less were not caught). While this might sound like a marginal improvement, it actually means we make 2.4 times fewer mistakes.
Mollom has a ton of potential and is great fun, so I have all reasons to believe that 2009 will be a good year for Mollom. If fact, I predict that 'good' will be an understatement.
Conclusion
2008 was a great year, and continues Drupal's great run. The economic realities of 2009 will present challenges, but also opportunities. I believe Drupal's success will continue -- and accelerate -- in 2009, though we'll have to work hard. I predict we'll do exactly that.
Open Source and Free Puppies
Seth Gottlieb reported that Annie Weinberger of Interwoven, a proprietary CMS vendor, launched some good old Open Source FUD comparing Open Source to a free puppy:
"We look differently at the cardboard box full of free puppies outside the super market once we become adults. As children what could be more fun than to get a puppy who is going to be your friend for life? Why not mom…it’s FREE!! But as adults we have learned the truth. We know that taking home that puppy is going to cost us in the end. The free price tag hides all the costs we are going to spend on food, training, shots, and a new couch once the puppy discovers you are not coming home at 5:00 every night to walk him. Open source WCM solutions are very similar. The free price tag is attractive at first, but for online strategies that have multiple initiatives (intranet, extranet, portal, landing pages, micro-sites, etc.), the hidden fees lie in the heavy customization, maintenance and engineering work."
Puppy analogies -- especially those with free puppies -- are powerful stuff.
Is Open Source more expensive than proprietary systems? It depends. You can't generalize. Open Source implementations can be more expensive if you try to bend the software too much. However, you don't have to be a genius to understand that because there are no licensing costs, Open Source has the potential to be much cheaper than proprietary solutions, and that Open Source solutions come with freedom and flexibility not found in proprietary products. Implementation cost is an important factor, but it is in providing freedom and flexibility that Open Source wins and commercial vendors lose. Open Source puppies are "free" as in "free speechbark".
One thing is for sure: puppies attract attention; these days, Open Source does as well and proprietary vendors tend to be of the jealous type.
The great thing about FUD, though, is that it validates our work in the Open Source community. Blog posts like Annie's trigger the competitive gene in hundreds of Open Source developers around the world, and in the end, makes Drupal stronger.
A free puppy, anyone?
