State of Drupal presentation (September 2013)

Last week in Prague, I gave my traditional State of Drupal presentation. A total of 1,830 Drupalists were present at DrupalCon, a new record for our European DrupalCon!

In good tradition, you can download a copy of my slides (PDF, 31 MB) or you can watch a video recording of my keynote. The keynote starts at 11:42, but don't miss out on the singing carrots introduction. A video recording of the keynote is embedded in this post.

Moeke Hasselt

Liefste Moeke Hasselt,

Vandaag is het een vreemde dag. Ik kan helaas niet bij je zijn maar ik denk aan jou en deel de pijn.

Ik denk terug aan de liefde die je ons hebt gegeven. Met goedheid en lieve zorgen heb je ons omringd.

Kon ik nog maar een keer goed met je praten, of kon ik je maar laten zien hoe ik mijn leven zou gaan leiden.

Maar vrees niet, want je hebt ons een erg goed voorbeeld gegeven. Je was een vrouw met een groot besef van plicht. Bedachtzaam, bescheiden en tevreden -- die dingen staan nu ook in ons hart en in ons verstand geschreven.

Vandaag is het een vreemde dag. Verdrietig om het gemis, dankbaar voor de goede herinneringen, en trots op wat je ons hebt gegeven.

Moeke Hasselt, geniet van je rust, verlost van alle pijn, en van eindelijk bij Vake Hasselt te zijn.

Bedankt,

Je kleinzoon, Dries

Party

Announcing Acquia Cloud Free

I'm excited to announce that Acquia is launching Acquia Cloud Free, a no-cost development sandbox for Drupal development. While Acquia has always had a freemium offer for development purposes, it had an expiration date, and it required a credit card. We've changed that with Acquia Cloud Free. Acquia Cloud Free comes packed with great tools including, but not limited to:

  1. A free development sandbox on Acquia Cloud with development and staging environments, Drush integration, Git repository and more. (The sandbox can't be used to run production sites.)
  2. Drupal development workflow tools that allow you to deploy code between dev and staging environments, replicate files, make backups and more.
  3. Acquia Insight which will scan your site for security problems, performance improvements and general Drupal best practices. Every day, we run thousands of tests on your site. Our team keeps adding new tests based on what they learn every day.
  4. Acquia Search which supercharges your site's search capabilities with more accurate search results, faceted navigation, search analytics and more.

We've put a lot of thought and effort into creating the Acquia Cloud platform and continue to invest it in heavily. As a result, we have seen tremendous adoption. I believe that giving everyone access to a free Acquia Cloud development sandbox is one way we can give back and help grow Drupal. Give it a try if you want!

Three important start-up lessons I learned

The blog post below was a guest article I wrote for Inc Magazine and was published in September 2013. It has been a while since I shared a startup lesson on my personal blog so I'm cross-posting my article here.

When I started working on Drupal in my college dormitory 12 years ago, I had no idea that one day it would be used by 2 percent of the world's websites. What is even more exciting is the open source community that has grown up around Drupal.

I co-founded Acquia six years ago to support the growing number of organizations that rely on Drupal, and also co-founded Mollom to solve the spam moderation challenges for website owners. Six years later, Mollom was acquired, and Acquia has almost 400 employees. As I've encountered challenges every step of the way. Here are three lessons learned.

1. Think big

So often I meet entrepreneurs who are working on a startup concept. They have a great idea and a business plan to bring it to market, but they're thinking too small about what they're trying to do.

I believe companies are most successful when they have a mission to change the world. When you set ambitious goals, you'll better position yourself for success. You become what you believe.

Being shortsighted can be a big barrier to success, because you can easily miss the window to capitalize on an opportunity. It's why I founded Acquia in the United States; I immediately had access to a larger market. We moved quickly to be a global company to maximize our opportunity, and it's made all the difference.

2. Fail fast

"Fail fast, succeed faster" is a philosophy that's been adopted across the company at Acquia. It's perhaps counter intuitive, but the idea is that in building a startup, you're going to fail. There will be problems, and the faster you run into them, the faster you can learn, adjust, and grow.

Implied in the fail-fast philosophy is that you'll be open to failure, and that can be hard for entrepreneurs who are so focused on success. People don't like to fail, so they're not inclined to celebrate their failures and embrace the lessons learned. Yet doing so means you'll more quickly make the needed – and often painful – adjustments to get on the right path faster.

In the initial business plan for Acquia, we expected to support a specific distribution of Drupal that we'd closely manage. Early prospects told us repeatedly it was a great strategy, yet when we took our offer to market, the buyers weren't there. We realized very fast that our business plan needed a big change, that we needed to support Drupal in whole. It was a terrifying proposition at that stage of our business, but we realized that was what the market needed most. We made the change, and it quickly put us on a successful course.

3. Passion makes the difference

I think some people get inspired to launch a startup because of its potential rewards, but launching a successful business starts with having a passion to solve a problem. I was passionate about building websites; it was my biggest hobby before it was ever a business opportunity.

When we started Acquia, our lead investor told me the key to a successful startup isn't in a good idea, but rather is in having a good team. A good team will figure out how to make something great happen. They'll pivot, they'll change, and they'll claw their way to success. Find talented people who share your passion, and together you'll find your way toward building a great business.

Why the big architectural changes in Drupal 8

There has been a lot of chatter about Drupal 8. Will Drupal 8 be performant? Will Drupal 8 be easy to develop modules for? Will I have to learn Symfony? I want to address these concerns and explain why Drupal 8 introduces such big changes.

Lessons from the past: the pain before the gain

The reason Drupal has been successful is because we always made big, forward-looking changes. It’s a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.

The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to this change. I first wrote about it in 2006 when trying to get Drupal 4.7 released:

"So let's capture that thought for future reference. Sweeping changes are required to make major advances in technology, and often times there is a lot of pain before the pay-off."

We decided that big changes were required

Drupal 7 is a fantastic CMS, but at the same time there are some fairly big limitations, including an incomplete Entity API, a lack of separation between content and configuration, leading to deployment challenges, a lack of separation between logic and presentation in the theme layer, and more. We created solutions for those challenges using contributed modules, but those solutions were in many cases incomplete. In Drupal 8, we decided to tackle a lot of these problems head-on, through the Configuration Management Initiative, the Twig templating layer, and a complete Entity API.

The web landscape has also dramatically changed around Drupal since January 2011, when Drupal 7 was released. Mobile browsing is ubiquitous, and so are third-party services that people may want to integrate their Drupal sites with. Web site users expect a much higher bar when it comes to ease of use. We anticipated these trends and as a result, we spent the past 2.5 years working on Drupal 8's mobile features and user experience improvements.

But are all these great improvements enough?

We need to modernize Drupal 8

One of our biggest challenges with Drupal, is that it is hard for organizations of all sizes to find Drupal talent (developers, themers, site builders, etc). Drupal 7 didn't address this problem (e.g. we held on to procedural programming instead of object-oriented programming), and in fact made it a bit worse with the introduction of even more "Drupalisms" (e.g. excessive use of structured arrays). For most people new to Drupal, Drupal 7 is really complex.

The most effective way to address the Drupal talent issue, as well as the complexity issue, is to bring Drupal in line with modern frameworks and platforms, so there is less Drupal-specific knowledge to learn in order to become proficient. We decided to adopt modern PHP concepts and standards, object-oriented programming, and the Symfony framework. While a lot of the Drupal concepts (Fields, Views, Entities, Nodes) continue to exist in Drupal 8, they are now implemented using object-oriented programming design patterns.

The advantages and disadvantages of object-oriented programming are well-understood. The disadvantages are size, verbosity, the amount of work it takes to write (including the design planning that goes into it) and slower performance. For people new to object-oriented programming there may be a steep learning curve; some of the key programming techniques, such as inheritance and polymorphism, can be challenging initially. The advantages are encapsulation (both to hide implementation details and to avoid tampering with internal values), faster development thanks to re-use, extensibility, and better maintainability. Compared to procedural programs, object-oriented programs are easier to maintain, extend and refactor. So although a lot of work is spent to write the program, less work is needed to maintain it over time.

For Drupal 8 this means that the code will be more abstract, more verbose, and slower, yet also be more maintainable, more modular, and more accessible to non-Drupal developers. The end result is that Drupal 8 should help us attract new people to Drupal in a way Drupal 7 didn't.

This is exactly what happened with other projects like Symfony; Symfony 2 was a complete rearchitecture of Symfony 1. A lot of people were alienated by that, yet at the same time Symfony 2 took off like a rocketship. The same thing has happened with the major releases of Drupal as well, despite how much change each one brings.

Change is scary for the existing Drupal developers

However, as we get closer to the release of Drupal 8, existing Drupal developers have become increasingly aware of the massive changes that Drupal 8 will bring. This has resulted in some fear; some people feel like they have to re-learn everything they know, and that developing for Drupal 8 has changed to the point where it's no longer fun. This fear is completely understandable. Change is hard, it can be scary, and often takes a long time to be absorbed.

But even if we completely streamlined the Drupal 8 developer experience, Drupal 8 will still look and work radically different under the hood. As mentioned, there are advantages and disadvantages to object-oriented programming and modern design patterns. But if we care about the long-term success of Drupal, we can't preserve the past. The risk of sticking with the old Drupal 7 architecture is that we won't be able to attract many more Drupal developers, and that over time, Drupal will become the odd one out.

There is a lot of work left to be done

Part of the fear out there is well-founded because in the current state of development, Drupal 8 isn't good enough. While there are many things to like about Drupal 8, I'm also the first to admit that we have work to do on the Drupal 8 developer experience (as well as performance) before Drupal 8 can ship. Creating a well-designed object-oriented application takes more time and design work than creating a procedural one. Some major improvements have already landed, but we're still working hard on improving the developer experience. We need more help, especially from Drupal 7 developers, on how we can make Drupal 8 more approachable for them. I'm not afraid to make major API changes if the developer experience improvement is suitably large. So if you have concerns about Drupal 8, now is the time to step up and help. In return, I promise we'll work on Drupal 8 until it is ready. Thank you!

Open Source code: by the people, for the people

Many organizations adopt Open Source for reasons like flexibility and agility. Everyone needs to do more with less. But in government, Open Source drives both civic engagement and government participation like never before. Because of digital, the world feels much smaller and more connected. And Open Source gives people the opportunity to rally around a cause, no matter where they live.

Think about how we petitioned our government before we had the We The People website. I bet you have to think pretty hard about how it was done (I do!). Now, a website has brought to life the First Amendment rights of U.S. citizens. Millions of people's voices are heard. People pull together based on common concerns. The White House built We The People using Drupal and shared the code on GitHub, opening up the opportunity for other governments to easily create their own online petitioning systems.

Now, all kinds of open government data made available through the Data.gov project makes it possible for any developer, anywhere, to create a civic app. These apps have made us see our cities and towns in a different light.

Open City is one example of a group of local volunteers who create Open Source apps using government data. While the group is based in Chicago, the idea is that any city can grab code from an Open City app and make it their own.

Here are a few interesting examples: Clear Streets tracks a city's plows in real time. Living outside of Boston, I know we could use an app like that! Crime in Chicago lets citizens compare crime statistics in certain areas of town, which could be useful for people making decisions about where to move their families.

What is perhaps the most gratifying is that as open-source developers, we can collaborate on projects and help people around the world. It's part of what gets us out of bed in the morning. Earlier this year, participants in DrupalCon Portland launched a website in 24 hours to help people in Moore, Oklahoma, find transportation and housing after the tornado. Two weeks later, the site was discovered on Twitter in Germany and was repurposed to help people affected by the flooding in northern Europe. This type of project inspires us all to see how technology can make an immediate difference.

Other events, such as the National Day for Civic Hacking, encourage developers to use open government data to "collaboratively create, build, and invent". The idea that hackathons can help build and create a healthy, citizen-powered technology ecosystem within government is relatively new, and full of promise. Tim O'Reilly believes that government can escape the "vending machine" mentality (citizens put in tax dollars and get out services) by thinking of "Government as a Platform" for participation. I couldn't agree more.

Open Source ideals are already spreading in governments throughout the world, with good reason. A global network of developers is motivated to help. It's one of the best examples of civic engagement. As digital citizens, we all now have the power to contribute. One person's time and talent can make a huge difference. That is a movement I'm proud to be a part of.

(I originally wrote this blog post as a guest article for VentureBeat. I'm cross-posting it to my blog.)

Pages

© 1999-2014 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.