You are here

Drupal

Help me write my DrupalCon Amsterdam keynote

For my DrupalCon Amsterdam keynote, I want to try something slightly different. Instead of coming up with the talk track myself, I want to "crowdsource" it. In other words, I want the wider Drupal community to have direct input on the content of the keynote. I feel this will provide a great opportunity to surface questions and ideas from the people who make Drupal what it is.

In the past, I've done traditional surveys to get input for my keynote and I've also done keynotes that were Q&A from beginning to end. This time, I'd like to try something in between.

I'd love your help to identify the topics of interests (e.g. scaling our community, future of the web, information about Drupal's competitors, "headless" Drupal, the Drupal Association, the business of Open Source, sustaining core development, etc). You can make your suggestions in the comments of this blog post or on Twitter (tag them with @Dries and #driesnote). I'll handpick some topics from all the suggestions, largely based on popularity but also based on how important and meaty I think the topic is.

Then, in the lead-up to the event, I'll create discussion opportunities on some or all of the topics so we can dive deeper on them together, and surface various opinions and ideas. The result of those deeper conversations will form the basis of my DrupalCon Amsterdam keynote.

So what would you like me to talk about? Suggest your topics in the comments of this blog post or on Twitter by tagging your suggestions with #driesnote and/or @Dries. Thank you!

The business behind Open Source

A few days ago, I sat down with Quentin Hardy of The New York Times to talk Open Source. We spoke mostly about the Drupal ecosystem and how Acquia makes money. As someone who spent almost his entire career in Open Source, I'm a firm believer in the fact that you can build a high-growth, high-margin business and help the community flourish. It's not an either-or proposition, and Acquia and Drupal are proof of that.

Rather than an utopian alternate reality as Quentin outlines, I believe Open Source is both a better way to build software, and a good foundation for an ecosystem of for-profit companies. Open Source software itself is very successful, and is capable of running some of the most complex enterprise systems. But failure to commercialize Open Source doesn't necessarily make it bad.

I mentioned to Quentin that I thought Open Source was Darwinian; a proprietary software company can't afford to experiment with creating 10 different implementations of an online photo album, only to pick the best one. In Open Source we can, and do. We often have competing implementations and eventually the best implementation(s) will win. One could say that Open Source is a more "wasteful" way of software development. In a pure capitalist read of On the Origin of Species, there is only one winner, but business and Darwin's theory itself is far more complex. Beyond "only the strongest survive", Darwin tells a story of interconnectedness, or the way an ecosystem can dictate how an entire species chooses to adapt.

While it's true that the Open Source "business model" has produced few large businesses (Red Hat being one notable example), we're also evolving the different Open Source business models. In the case of Acquia, we're selling a number of "as-a-service" products for Drupal, which is vastly different than just selling support like the first generation of Open Source companies did.

As a private company, Acquia doesn't disclose financial information, but I can say that we've been very busy operating a high-growth business. Acquia is North America's fastest growing private company on the Deloitte Fast 500 list. Our Q1 2014 bookings increased 55 percent year-over-year, and the majority of that is recurring subscription revenue. We've experienced 21 consecutive quarters of revenue growth, with no signs of slowing down. Acquia's business model has been both disruptive and transformative in our industry. Other Open Source companies like Hortonworks, Cloudera and MongoDB seem to be building thriving businesses too.

Society is undergoing tremendous change right now -- the sharing and collaboration practices of the internet are extending to transportation (Uber), hotels (Airbnb), financing (Kickstarter, LendingClub) and music services (Spotify). The rise of the collaborative economy, of which the Open Source community is a part of, should be a powerful message for the business community. It is the established, proprietary vendors whose business models are at risk, and not the other way around.

Hundreds of other companies, including several venture backed startups, have been born out of the Drupal community. Like Acquia, they have grown their businesses while supporting the ecosystem from which they came. That is more than a feel-good story, it's just good business.

Fostering inclusivity and diversity

The past few weeks, I've been thinking over and over again trying to rationalize how to best foster a culture of inclusivity and diversity. This in the context of creating a productive work climate of trust and respect.

I think it is fair to say we all want other people to feel welcome and respected. Where that gets difficult is that feeling welcome and respected means something different to different people. What seems harmless to you could be hurtful to another. For example, some people tend to be more concerned about the use of crude or sexual language than others. It's a complex issue based on a range of factors including gender, race, age, geographical location and more. There is also a lot of academic research about the fact that derogatory and vulgar language or sexually graphic behavior creates a hostile environment. These two facts combined, makes it a popular topic in the context of diversity and inclusion.

However it is not just a popular topic, it is also a very difficult topic. Why do we feel defensive and argumentative when confronted with a value and belief system different from our own? It is one thing to challenge someone's take on, say, a country's healthcare system, it is another thing to challenge someone's beliefs. Challenge someone's beliefs, and you challenge their sense of self.

Given all this, is it possible to be inclusive of everyone? For example, can we be inclusive of those who are easily put off by sexually graphic or vulgar language and at the same time be inclusive of those who often use crude or sexual language? Does supporting one group of people mean turning away others? I hope not, but I'm not sure. Can we find a balance when we have conflicting behaviors? Sometimes we need to change behavior (eg. tone down or refrain from using bad language), and other times we need to understand when no offense was intended, and try to accept and accommodate cultural differences.

Answering these questions to define our culture is very difficult. It is even harder to put them into written rules. I strongly believe that being inclusive is a mindset first. It is about wanting to be a good person to all other people. Once you have it in your mind that you want to make others feel respected and comfortable around you, you'll find that you'll be looking for ways to do so. The key is to be appreciative of our differences. If you show respect and sincerity and remain open to hearing differing opinions, we will automatically become more aware of how our actions affect people different from ourselves. We'll automatically become more inclusive and more diverse.

By the same token, being appreciative of how we are different also means you should be willing to give the benefit of the doubt in case you are offended. It's only through fostering an environment where it is safe to make mistakes and learn from each other that we can achieve diversity and inclusiveness in our community.

Last but not least, it also presents a tremendous opportunity to learn about new cultures. I hope to learn from people who are different than me and talk honestly about our differences. If you are one of these people, I hope to ask you questions respectfully to learn more about how your values differ, and would love to find out how you want to be treated.

I'll continue to think about how to best foster a culture of inclusivity and diversity, but I wanted to stop and listen first ...

Drupal 6 support

The policy of the Drupal community is to support only the current and previous stable versions of Drupal. If we maintain that policy, Drupal 6 support would be dropped the day that Drupal 8 is released. We'd only support Drupal 8 and Drupal 7.

We're changing that policy slightly as there are still around 200K known Drupal 6 sites in the wild, and we want to ensure that sites that wish to move from Drupal 6 to Drupal 8 have a supported window within which to upgrade.

The short version is that Drupal 6 core and modules will transition to unsupported status three months after Drupal 8 is released. A three month extension is not a lot, but continuing to support Drupal 6 is difficult for many reasons, including lack of automated test coverage. This gives Drupal 6 users a few options:

  1. Upgrade to Drupal 7 any time between now and 3 months after Drupal 8.0.0 is released.
  2. Upgrade to Drupal 8 after it is released, but before Drupal 6 is not supported anymore. There's already a Drupal 6 to Drupal 8 migration path in core which can be used for testing. Keep in mind though that if your site relies on contributed and custom modules, you may need to port the code and write the migration paths yourself if they're not done by the community in time for Drupal 8's release.
  3. Find an organization that will provide extended support for Drupal 6. We hope that organizations that rely on Drupal 6 will step up to help maintain it after community support winds down. The Drupal Security Team will provide a method for companies or individuals to work together in the private security issue queue to continue developing updates, and will provide a reasonable amount of time for companies to provide patches to Drupal 6 security issues that also affect Drupal 7 or Drupal 8.

You can read the details on https://drupal.org/node/2288521.

About today’s Drupal Association Board resignation

Today Morten Birch Heide-Jørgensen stepped down from his role on the Drupal Association's Board of Directors. The Drupal Association's Board of Directors supports Morten’s decision. The Drupal Association and the Drupal community value inclusivity and diversity, and our leadership must demonstrate those values as well.

We want to thank Morten for his service; he came to the board with a mission to foster improved transparency and communication. He helped both the board and staff embrace those principles in a way that will carry into the future.

Today’s development underscores the need for a broader discussion that we need to have about inclusivity and diversity. Creating and maintaining the right culture and environment is vital to Drupal's success. Therefore, we have asked the Community Working Group to define a process to help our community address these issues and identify positive, proactive, and concrete steps we can take to ensure that everyone feels welcome in Drupal.

Morten is vacating a community elected seat. The Board of Directors will discuss how and when to fill this vacancy at the next board meeting.

Respectfully,

Drupal Association Board of Directors

State of Drupal presentation (June 2014)

I gave my traditional State of Drupal presentation this week at DrupalCon Austin. You can watch the recording of my keynote if you are interested in learning about my vision for the future of the web, the challenges and opportunities ahead of us, how Drupal fits into that. In good tradition, you can also download a copy of my slides (PDF, 120 MB).

A method for giving credit to organizations that contribute code to Open Source

If we want to encourage more organizations to contribute to Drupal and hire core developers, we should start to give them credit for their contributions. I'd love to see us maintain a page on Drupal.org that shows which companies contribute to Drupal and in what capacity. This credit provides these organizations a tangible benefit in recruiting developers, demonstrating their expertise, and more. Credit is a powerful motivator for individuals, but also for businesses. It is a form of trust currency.

It is great that we give individual contributors credit for their contributions, and we should continue to do so. However, I'd like to extend that to organizations, both to the Drupal agencies as well as their customers. Mapping out how contributions get funded can be great for individuals, customers and digital agencies.

A great way to start doing this, is to adopt a new format for Git commit messages. I'd like to propose the following format:

$ git commit -am "Issue #n by INDIVIDUAL@AGENCY*CUSTOMER: message."

We prefix agencies with @ and customers with *. I believe this provides us the necessary flexibility. We could choose to store this in Git Notes, if we prefer, but that is not the main point.

Contributed a feature as an individual consultant directly for a customer or end-user:

$ git commit -am "Issue #n by INDIVIDUAL*CUSTOMER: message."

Contributed something in your spare time and don't want to give credit to your employer:

$ git commit -am "Issue #n by INDIVIDUAL: message."

Let's put it all together with a real example. Imagine Sam, Megan and Tim collaborated on fixing a performance bug. Sam helped in the "20% time" provided by her employer Acquia, Megan helped in her spare time after work, and Tim worked on this on behalf of his employer, Pfizer, who is affected by this bug. Ideally, the commit message would look like this:

$ git commit -am "Issue #42 by Sam@Acquia, Megan, Tim*Pfizer: fixed performance bug."

The great thing about this approach is that we can adopt it today and worry about analyzing the data later. It also works regardless of where your Drupal code is hosted (Drupal.org, GitHub, etc) or what your source code management system of choice is (Git, SVN, etc). In fact, I believe all Open Source projects would benefit from this level of transparency and that giving credit directly into the commit message makes it very transferable.

If adopted, we'll want to build tools to help us create these commit messages (i.e. have contributors provide proper attribution in a new project issue field so the maintainers/committers don't have to manually create it).

With this level of transparency, we can start to study how our ecosystem actually works; we can see which companies contribute back code and how much, we can see how much of the Drupal project is volunteer driven, we can better identify potential conflicts of interest, and more. But most of all, we can provide credit where credit is due and provide meaningful incentives for organizations to contribute back to Drupal. I believe this could provide a really important step in making Drupal core development more scalable.

I'd love to hear your thoughts about us giving organizations credit.

Pages

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