|This page is part of the drupal learning project | view pages|
Personal blog of Dries Buyttaert
leader of the overall drupal project
- 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:
- Upgrade to Drupal 7 any time between now and 3 months after Drupal 8.0.0 is released.
- 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.
- 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
Today Morten Birch Heide-J [?]
- 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.
- Acquia acquired TruCentric
- Acquia raises $50 million series F
- Drupal 8 Q&A session at DrupalCon Austin[?]
Do you have questions about the upcoming Drupal 8 release (or Drupal 9 and beyond)? On Thursday, June 5 at DrupalCon Austin, I'll be moderating a question-and-answer core conversation with a panel of key Drupal 8 contributors. Questions are submitted in advance online, and anyone can submit a question. I will curate the submissions to ask the panel the most interesting and relevant questions.
This is a rare opportunity for the community to communicate directly with the trailblazers who are shaping Drupal 8 into the best release of Drupal yet. Help us make the most of of it -- submit your questions now!
- The investment case for employing a Drupal core contributor
I've long been convinced that every well-run Drupal agency of 30 people or more can afford to hire a Drupal core contributor and let him/her work on Drupal core pretty much full-time. A healthy Drupal agency with 30 people should be able to do $5MM in revenue at a 15% net profit margin #1. This means they have $750k in profits that can be invested in growth, saved as reserves, or distributed among the owners.
There are many ways you can invest in growth. I'm here to argue that hiring a Drupal core contributor can be a great investment, that many Drupal agencies can afford it, and that employing a Drupal core contributor shouldn't just be looked at as a cost.
In fact, Chapter Three just announced that they hired Alex Pott, a Drupal 8 core maintainer, to work full-time on Drupal core. I couldn't be more thrilled. Great for Alex, great for Drupal, and great for Chapter Three! And a good reason to actually write down some of my thoughts.
The value of having a Drupal core contributor on staff
When Drupal 8 launches it will bring with it many big changes. Having someone within your company with first-hand knowledge of these changes is invaluable on a number of fronts. He or she can help train or support your technical staff on the changes coming down the pipe, can help your sales team answer customer questions, and can help your marketing team with blog posts and presentations to establish you as a thought-leader on Drupal. I believe these things take less than 20% of a Drupal core contributor's time, which leaves more than 80% of time to contribute to Drupal.
But perhaps most importantly, it is a crucial contribution that helps ensure the future of the Drupal project itself and help us all avoid falling into the tragedy of the commons. While some core contributors have some amount of funding [?]