You are here
If Steve Jobs was adopted by a Belgian family rather than an American family, it's extremely possible he may have ended up working in a bank instead of co-founding Apple. Why? Because starting a company and growing it is hard no matter where you are, but the difficulty is magnified in Europe, where people are divided by geography, regulation, language and cultural prejudice.
While entrepreneurship and startups have spread tremendously in Europe, a lot of aspiring young entrepreneurs leave Europe for the United States. Very little will stop a true entrepreneur from trying to reach his or her goals, including uprooting their entire life and moving it across the ocean to optimize their chances of success. From my interactions with them, the United States' gravitational pull is only getting stronger.
So, what can Europe do about it? Here are my three recommendations.
Focus on creating large companies
Europe produces plenty of small businesses: restaurants, small technology firms, clothing stores, hair salons, and so on. What it doesn't produce enough of are innovative companies that grow quickly and end up big. It's a problem.
Look at the 500 largest companies in the world (Fortune Global 500). According to Bruegel, a European think tank devoted to international economics, Europe created three new, large companies between 1975 and today. The U.S. created 26.
That number is even more incredible when you take into account the fact that Europe has about twice the population of the U.S. The reality is if Europe were to be competitive, it has to produce 25 times more large companies than it does today.
Access to capital continues to be a challenge in Europe. Getting seed capital (1M EUR or less) has become easier, but raising significant money (25M EUR and more) to turn your company in a global business continues to be difficult. Large companies also provide an important 'exit strategy' for startups. Without a vibrant exit market, it's harder to attract both entrepreneurs and investors.
Large companies also play an important role in creating successful innovation centers. They are catalysts for creating angel investors, for providing distribution, and serve as a breeding ground for talent and practiced management.
If you look at Silicon Valley, Hewlett Packard, among others, served that purpose in the early days, and more recently, a number of successful entrepreneurs have emerged from Google.
I recommend that European government stimulus focuses on companies that could become titans, not on small companies that won't move the needle. Too often, there are investments made in companies that have limited or no growth potential.
Level the playing field
Anyone who has built a global organization likely understands that European work regulations can shackle the growth of startups. Taxes are high, it's hard to acquire a European company, severance packages can be outrageous and it's extremely difficult to fire someone.
It only gets worse when you attempt to operate in multiple European countries, as anyone with the ambition to build a large company has to. Each country is different enough that it requires setting up a local legal entity, and having local accountants and local attorneys. Setting up and running these legal entities costs valuable time and money, a huge distraction that gets in the way of actually running and growing your business.
Europe needs to roll out unified labor laws that are competitive globally and unified across Europe. My biggest worry is the branches of government that try to promote entrepreneurship are not powerful enough to address Europe's labour rules.
Change our culture
A small business can be started anywhere in the world, but it takes a different level of ambition to aspire to become the next Apple. The biggest thing entrepreneurs need is the belief that it can be done, that it's worth taking the risk and putting in the hard work. Having the right culture unlocks the passion and dedication necessary to succeed.
Silicon Valley is a state of mind. To recreate Silicon Valley in Europe, Europe must first adopt Silicon Valley's culture. I believe Europe's culture would benefit from adopting part of the American Dream: the egalitarian belief that everyone is able to succeed through hard work, and that it is acceptable and encouraged to better oneself economically through hard work.
It doesn't mean Europe needs to give up its strong communal beliefs and its desire to look out for the greater good. I'm a firm believer that many modern businesses can "do well and do good". Businesses that generate value for their shareholders and that also have a positive impact on the world go beyond generating profits.
Our world does not lack business opportunities; there are plenty of people with needs that aren't met. Enabling entrepreneurship enables innovation, and innovation helps change the world. The entrepreneurs that succeed in building large businesses, especially those that are aligned with fixing the world's problems, will transform the lives of others for the better and introduce more opportunity on a global level.
Entrepreneurs, not the government, will change the world. It's time for Europe to help their companies grow.
(I originally wrote this blog post as a guest article for Forbes. I'm cross-posting it to my blog.)
To "assemble" means to build. Assembling also means that we come together. Sometimes, both aspects are true. When that happens and we work together to build, we are better off for it.
The open source community is a perfect example of this. When Linux creator Linus Torvalds spoke about how it felt to get contributions from a worldwide network of people, he remarked "I had hoisted myself up on the shoulders of giants". I'm lucky enough to feel the same way.
The Internet has created a culture of sharing, letting people connect and collaborate on areas of common interest. When I started developing Drupal in 2000 from my university dormitory in Antwerp, I never imagined I'd build a network of people who were interested in building a content management system with me. Yet word of my project spread, and before I knew it, I was getting contributions to my project from around the world. Soon I also was standing on the shoulders of giants.
We didn't know it at the time, but this founding group of Drupalists was creating the basis for the assembled web. The assembled web is the next stage in the evolution of the web. While the coded web will always continue to exist, it will be a minority.
Think of the assembled web almost as an app store model for creating a digital experience. For example, if you want your website to allow social comments to flow in from Facebook or Twitter, you can simply add a module that someone has already coded. If you want to add analytics, maps, or almost anything you can imagine — there's probably a module for that.
While the modules are built on a foundation of code, they require no coding to install and build with ... to assemble. Instead, the vision of a great digital experience can be accomplished by someone with no coding experience, who can now simply "snap" the pieces of a new web experience together.
So, why is the assembled web rising to prominence so quickly, and what does that mean for developers?
- First, there are more websites now than ever before, and there's no sign of that growth slowing down. Ten years ago, a company had one website. Now, that same company might manage dozens or even hundreds of sites.
- Second, the complexity of websites has skyrocketed. Applications, integrations with third-party systems, social media integration, and the mobile web have all driven this complexity. New technologies emerge and replace the old. For example, Flash has almost been driven to extinction, replaced by HTML5, CSS3 and other more modern standards.
These two trends, set against the way many sites are built today, make it difficult to keep up with the changing standards, much less innovate and move the digital experience forward.
There is only one way to keep up: do more with less. I first imagined the assembled web in 2005, when the widespread use of content management systems began to replace the webmaster role as we knew it. Webmasters were no longer hired to write HTML by hand, or upload code to an FTP. In a way, the CMS eliminated the middleman.
Beyond our own evolution as developers, outside forces have also fundamentally altered the web. Ten years ago, the global phenomenon of Facebook didn't exist. Twitter didn't exist. The iPhone had yet to be released and create the mobile ecosystem that we know today. Think about the amount of change that's happened in such a short period. Now what will the world, and the web, look like another 10 years from today? No one knows.
The best thing to do is to adopt a platform that can change at the pace of the web. Developers will be tasked with building new functionality, and expanding the world of possibilities that modules can deliver. The innovation that developers will bring is crucial, and will power the assembled web by lowering barriers and democratizing the experience of site building.
The assembled web doesn't just have implications for the way developers create websites. It will have a widespread impact on any person or organization that needs to keep up with rapidly changing external forces. That's pretty much everyone. Think about how the assembly line changed manufacturing the first time. And how 3D printing is changing it again now. We can build faster and smarter than ever before. Similarly, the assembled web gives more people the tools to build the web as we know it.
Anyone without coding experience will be able to use an open source CMS to assemble a site by simply snapping modules together. A marketer could build a site for a new product launch without relying on the engineering team. An entrepreneur could launch a company site without hiring a webmaster. This phenomenon frees up time for developers to create new ways to connect citizens to their governments, nonprofits to donors, businesses to customers, friends and family to each other. Launching a disruptive business idea or reacting to today's rapid market changes could be accomplished without technical assistance. Going from vision to realization, for the first time, would be a single step. This advantage would finally bring the speed of digital site building in line with the speed of the web.
This evolution isn't a scary thing for developers; it's an opportunity. The web has forced a constant reinvention of everything. Careers. The way we compete for business. Being more efficient in the way we assemble a website will allow us to focus on the things that matter more, like innovation and creativity. By standing on the shoulders of giants, we can make things look and operate more beautifully than we'd ever have expected.
Over the past twelve months, I’ve become a bit of an obsessive follower of Bitcoin. It started after I read Satoshi Nakamoto’s original Bitcoin paper. It was a fascinating read and my first introduction to crypto-currencies. I even had a couple of lunches in Boston with Gavin Andresen, Bitcoin’s current project lead.
I was close to buying some Bitcoin when I first got interested, but backed off. It was too bad because Bitcoin's value increased from $13 a year ago to around $1,000 at the time wrote this: a 4,000% increase in 12 months. I didn't buy my first Bitcoins until a month ago. I bought them with some reluctance but I figured that people felt a certain reluctance when paper money first came along. But I bought them because to me it seemed like Bitcoin could work and also because I wanted to have a better understanding of what it was all about.
Bitcoin is a purely digital currency. There are no records of Satoshi's identity so no one knows who invented it, no one controls it and it is not backed by gold. It is something akin to a digital version of gold. It's fascinating. At the core of the Bitcoin system is a global, public log, called the "blockchain", that records all transactions between Bitcoin clients. A user can send Bitcoins to another user by forming a transaction and committing it to the blockchain. The blockchain is maintained not by a central body, like a central bank, but by a distributed network of computers, called "miners". Everyone can be a miner, and the miners collectively record and verify all transactions.
Compared to traditional banks, the advantages of Bitcoin are significant. Bitcoin payments can be made at any day of the week, any time of day to anywhere in the world. The fees and delays involved are small compared to those imposed by banks; pennies compared to dollars and minutes compared to days. And unlike paper money, it is unforgeable. Unlike gold, its supply is perfectly verifiable. It is also immune to inflation: governments can't print more Bitcoins to pay off their debts.
The design and architecture of Bitcoin is both a curse and a blessing. The lack of central authority governing Bitcoin raises questions. Governments tend to enjoy power of observation; it makes it easier to fight money laundering, tax evasion and other crimes. As Bitcoin continues to gain popularity, governments may grow increasingly resistant and attempt to shut down Bitcoin. And banks don't like Bitcoin either. Money transfer is an important part of their business; it has almost zero risk, almost zero cost, yet provides them billions of dollars in revenue. In a world where Bitcoin is universally accepted, banks may have a diminished role.
The jury is out on whether Bitcoin is a fantasy destined for failure, or whether Bitcoin will underpin the future of finance. Some predict the value of one Bitcoin could climb to hundreds of thousands of dollars if it becomes universally accepted. While I risk losing some money, it could also turn out to be a massive investment home-run. I felt that the risk/reward decision made it a bet worth taking.
I certainly don't advise you to buy Bitcoin as I'm skeptical that Bitcoin will succeed. I predict Bitcoin to have an extremely bumpy ride, and at best, to follow Gartner's hype cycle. If Bitcoin ends up collapsing, I will be disappointed but I won't feel stupid. I already sold some Bitcoin and recouped my original investment; I'm long with my remaining Bitcoin.
So is Bitcoin a case of speculative greed, or a utopian cyber-libertarian ideology? In a world where everything is going digital, why not currencies? Bitcoin makes it faster, cheaper and easier to store and transport value. It was designed to overcome problems faced with traditional currencies and banks. At a minimum, Bitcoin has created a lot of debate throughout the world, and has shaken a stagnant banking market. Longer term, the concept of a crypto-currency makes a lot of sense to me. It is massively beneficial for the world that we can transfer money easier, faster and cheaper. I find it hard to believe that a hundred years from now, we'd still be digging up gold, and that we wouldn't have a global, digital currency to replace it.
If you believe a digital currency is the future of money, I'll leave you with one question: how would one launch a world-wide crypto-currency like Bitcoin? It can't be owned by a commercial organization, and I simply can't imagine all the world's governments work together to build and launch something like this. Creative disruption often comes from the outside, and not from the inside. It pretty much has to happen in a grassroots way, not unlike the way the Internet was created. Even today after 30 years, the Internet operates without a central governing body and is comprised of independent, voluntarily networks. It works well and changed the world.
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!
Every week, I get asked the "Silicon Valley question". This week alone, it came up at least three times. I had a phone call with a Belgian start-up asking me for my thoughts on whether to start their company in Belgium or in Silicon Valley. This afternoon, iMinds, a Belgian research institute that promotes entrepreneurship, visited me at Acquia to talk about similar topics.
There are advantages and disadvantages to being in Silicon Valley, and we could argue them to death. Not every great technology company is based in Silicon Valley, and there are many successful entrepreneurs who aren't in the valley. However, I bet you that deep inside every one of those entrepreneurs wonders whether it wouldn't be better to be in Silicon Valley. More often than not, it actually would be better.
This morning I got a message from Bart Becks, a well-known Belgian entrepreneur and angel investor. He asked for my thoughts on an article he is writing about whether Europe could replicate the Silicon Valley phenomenon. To me, this is the more interesting "Silicon Valley" question.
Europe has no choice but to reinvent itself to become more like Silicon Valley. Entrepreneurs, not the government, will actually change the world. While the government's role is to foster entrepreneurship, clearly the government on its own isn't capable of changing Europe fast enough.
Silicon Valley is a state of mind. To recreate Silicon Valley in Europe, Europe has to adopt Silicon Valley's culture first. That culture has developed around the desire to continuously reinvent everything, including oneself. That is what keeps Silicon Valley relevant, and what Europe needs to emulate most. Once Europe has established a Silicon Valley-like culture, it can slowly mix in the other ingredients that make Silicon Valley successful: money, smart venture capitalists, better engineering talent, better creative talent, and more. But let's start with the culture.
There are other aspects of the Silicon Valley culture that all of Europe should adopt. The Silicon Valley culture encourages people from all over the world with different cultural backgrounds and diverse skills to physically come together, inspire each other, and try to accomplish something unique and game-changing.
I also believe that Europe should adopt part of the American Dream: the egalitarian belief that everyone is able to succeed through hard work, and that it is acceptable and encouraged to better oneself economically through hard work. It doesn't mean Europe needs to give up its strong communal beliefs and its desire to look out for the greater good. I hope the European financial crisis represent a watershed moment that causes Europe to rethink some of its current models.
America's social history wasn't necessarily pretty, but it has created a culture where multiculturalism, ethnic diversity and thoughtful capitalism are part of the national character. I'm worried it may take Europe a couple generations to truly embrace such a culture. Until that happens, we'll see some regional and national successes, but not the European-wide "Silicon Valley" culture that Europe needs to successfully reinvent itself.
For Acquia, 2012 was a great year. In many ways, it's been our best year.
Last year, we saw more evidence of Drupal continuing to become a growing part of the mainstream. While this trend has been apparent for some time, in 2012 we were being adopted at a faster rate by more and more enterprise businesses and government agencies. Acquia, in many ways, has risen on the tide of this acceptance. Maybe we helped build this momentum. And along the way, as we've grown, we have worked to keep the philosophy of open source as the guiding philosophy of Acquia.
The Open Source Way
The concept of being guided by the philosophy of open source, which I call the Open Source Way, is reflected in Acquia's approach to our products and services. For example, we believe it is important to provide the capability to easily transfer data from one platform or solution to another, and not be shackled to proprietary vendors' platforms. The solutions we offer, whether PaaS or SaaS, allow innovation and agility by following the open source way, eliminating lock-in. We've coined the terms OpenSaaS and OpenPaas to refer to this.
This approach has resonated with enterprise business. This is reflected in our growth metrics for 2012. Our growth was reflected in our sales bookings, which grew at a record rate. We finished the year with 15 consecutive quarters of revenue growth, surpassing even our own aggressive goals.
Acquia grew by more than 160 employees last year, and now totals about 280 staff. In addition to Acquia's base in Burlington (Boston, MA), we have 28 employees in the UK office, 14 in our new Portland office, and 82 working remotely. Success poses many challenges. Hiring so many people is difficult. On one recent Monday, we have about 20 new staff undergoing orientation in our Burlington office. We've met the challenge of hiring, though, and we've assembled a staff of talented, passionate people. They are the reason for Acquia's success.
Our core strength is our ability to accomplish the aggressive goals we set for ourselves. This ability is the result of both the collaboration and the passion the Acquia staff brings to everything we do. Acquia's culture, in which collaboration and passion are key, also reflect the Open Source Way. We bring this passion and collaboration to our customers as well, and we work hard to ensure every customer's success. In 2012, the number of customers renewing with us was up, returning that commitment and loyalty.
Landmarks and trends
As we moved through 2012, we saw the growing acceptance of cloud computing. No longer was it "should we be on the cloud", but businesses asked "how best to move to the cloud". More often, the open, elastic cloud computing offered by Acquia was the answer. Platform as a Service (PaaS) and Software as a Service (SaaS) both continue to gain further acceptance and grow, again providing that ability to react to business needs rapidly, putting a larger portion of resources into building exactly what is needed when it is needed, rather than investing in expensive infrastructure and maintenance. The success of our cloud products means that Acquia will continue to invest and expand in this area in 2013, especially as we saw the trend last year that having many microsites, often one for each product or service, is quickly becoming the rule rather than the exception.
Other landmarks in 2012 were the growing number of health/pharma businesses moving to Drupal and the cloud, joining financial services companies and government agencies also making the move. Until recently, these industries were wary of open source and cloud-based services, fearing that these solutions weren't secure or reliable enough. The reality that the cloud can also be fault-tolerant and highly available, and that security and government compliance requirements can be met with confidence, opened up the cloud to more and more enterprise businesses in 2012. Their move to the cloud in 2012 reinforced the fact that freedom of innovation and agility of open solutions are driving factors for large-scale business as well as smaller organizations.
As the public moves rapidly to mobile platforms of all kinds, including smart phones and tablets, the need to provide a great user experience on these platforms is becoming increasingly important. UX also became important in 2012 as marketing rather than IT became the driving force behind more and more websites. Acquia responded with the creation of our Spark team, which took shape as a five-person team made up of some of the world's best Drupal experts.
Also in 2012, Acquia acquired Mollom, a company I created to address the challenge of managing social spam on websites. With the tremendous growth of user-generated content as part of the social media explosion, unwanted content has become a more important issue to take on. As a SaaS tool, Mollom fits in with Acquia's existing services.
In 2012, Acquia continued to invest in the worldwide Drupal community in a number of important ways. First, we sponsored over 82 Drupal events around the world in 2012. These events brought new people into Drupal and helped existing Drupal users learn new techniques. We employ more than 110 Drupal specialists, most of whom are significant contributors to the larger community. We've sent our Drupalists to more than 30 of these events (as well as hosted sprints ourselves at Acquia) to collaborate with others in the community on important problems for Drupal.
We also grew Acquia's Office of the Chief Technical Officer, or OCTO, in 2012. OCTO includes a dedicated team who work on Drupal full-time, on projects that include:
- Drupal core architecture issues.
- Authoring experience improvements via Spark.
- Spearheading process changes that help the community work better together.
- Forming the Large Scale Drupal program, which helps pool resources of numerous enterprises to provide solutions the benefit the entire community.
This year, like 2012, will be a key year for Acquia as we continue to develop products and services built on the open source philosophy.
Life-cyle management applications will be an increasing focus for Acquia in 2013. These applications will help craft great digital experiences by providing the tools to monitor and optimize digital content.
Of course, we'll continue to nurture and expand our vision of OpenSaaS and OpenPaaS. We'll continue to make the move to PaaS even easier, providing solutions that offer all of the functionality needed, but in a simplified package. We'll accomplish this by combining PaaS, Drupal services and Application Performance Management to produce comprehensive solutions that continue to make Acquia a no brainer when it comes to choosing a PaaS provider. PaaS platforms that embrace an open ecosystem provide faster business value, as many of our customers have discovered. We are working with our growing number of partners to help them build customer solutions on our open cloud platform.
As we start down the road of 2013, we enter the year just having raised $30 million in Series E financing, the single largest financing we have done to date. As we have grown and matured during 2012, these funds will assure sustained growth and success in 2013. No matter how rapidly we grow, or how large the Drupal community becomes, Acquia will put its open source philosophy at the core of all the work it does. In the end, the people of Acquia and the Drupal community, following this philosophy, are building the future of the digital experience. The Open Source way.
As mentioned last month, on July 16 - 17, 2012, several community leaders in the Drupal project sat down with several community leaders from other open source projects and tried to hash out a governance structure to support the Drupal community's continued growth. "Governance" in this case, encompassing all the things we do to organize ourselves, make plans and decisions together, get things done, and resolve conflicts.
Here are the proposals we came up with, and we are actively seeking community feedback on the ideas within.
What problems are we trying to solve?
We began the sprint by brainstorming a list of problems we're hitting, given the scale of our community. This list included items such as:
- No obvious answer to the question, "Who can make a decision here?" and as a result, important decisions can get stale-mated, or in the worst case leave smouldering craters where a healthy, functioning community used to be.
- Because the Code of Conduct punts on the topic of conflict resolution, a handful of already swamped individuals get tapped on an ad-hoc basis to intervene in conflict situations. This both burns out those individuals, and also leaves the vast majority of the community who don't know who those individuals are with no conflict resolution path apart from "repeat what I already said, but with more volume".
- While our "do-ocracy" model generally works well for our community, it can also lead to situations like "Tyranny of the person with the most time on their hands." We need ways for smart people who can't be on IRC 18 hours a day or read 300+ reply issues to participate and be respected as equals.
Over the course of two days, Drupal community members Dries Buytaert, Angela Byron, Randy Fay, Greg Dunlap, and David Strauss met and discussed a variety of these and other governance topics, and we also received input from Jono Bacon, community manager for the Ubuntu project, Jared Smith, former project lead of the Fedora project, and David Eaves.
Overview of proposed changes
We propose the creation of a number of "working groups" that essentially make more explicit community structures that already exist. Each working group would consist of ~5 people, appointed by Dries, in charge of collaborating with the community in order to establish effective policy. Each working group will have one "lead" member (chair) who communicates major items and works with Dries. Some working groups will have a set duration (e.g. life cycle of a Drupal core release), others may have terms. Dries, as project lead, also reserves the ability to terminate a group at any time if it feels like they are overstepping their scope (charter).
The summary, in essence:
- Establish clearly chartered working groups where currently loosely defined individuals are taking on things that are community-shaping in their scope.
- Empower these working groups to make decisions, so important community governance decisions do not get stalemated. Keep the groups small enough that decision-making can take place efficiently, but large enough that a diversity of opinions are represented.
- Make it more transparent and obvious, to newcomers and community insiders alike, where "the buck stops" with decision-making in our community in various areas, what the structure of the community is, what's expected of them, and who to turn to for help.
The "Drupal" groups encompass areas that touch Drupal core or contrib, or the Drupal community itself. The ultimate "buck stops here" with these groups is with Dries Buytaert, the Drupal project lead.
Inspired by the Fedora Community Working Group, this group would be responsible for maintaining a friendly and welcoming community, and their charter will likely consist of items such as:
- Maintaining and updating community-governing policies like the Drupal Code of Conduct.
- Helping with mentorship and on-boarding of new community members.
- Ensuring existing community members have their needs met.
- Intervening as mediators in cases of conflict resolution (where the conflict cannot be worked out among individuals first) or burnout.
- Issuing sanctions in cases of extreme policy violations.
In other words, this working group tries to make sure the "people" side of our community is functioning well. It doesn't set technical policy or intervene in any code-related matters; this is the role of the Technical Working Group. The ideal make-up of this group would be community-minded people with extreme amounts of patience, empathy, and diplomacy skills.
A corollary to the Community Working Group, this group would set and maintain policies around the technical aspects of our community, including:
- Develop and maintain policies around things such as:
- Establishing best practices and recommendations around bug/issue workflows; for example, strongly encouraging a workflow of idea -> architecture review -> implementation -> code style/clean-up.
- Recommending to the Drupal Association tool changes that will help accelerate contribution.
- Intervening as mediators in cases of technical conflict (where the conflict cannot be worked out among individuals first).
In other words, this working group tries to make sure the "technical" side of our community is working well. "People" problems would be escalated to the Community Working Group. Nevertheless, the ideal make-up of this group would be community-minded people who are also technical, known to be fair, and adverse to making new rules.
A lot of time was devoted at the sprint to discussing Drupal Core, and how to address some of the challenges surrounding its development. For example, there is currently a lot of tapping of internal networks to move things along in core, and those without access to those networks can feel blocked out. It's also very difficult to get an answer as to whether or not something is "core-worthy" until far too late in its development process, making major feature development a risky affair.
The recommendation from the Governance Sprint is something like the following, which would not take effect until the Drupal 9 development cycle.
Drupal Core Initiative Working Group
This group works with Dries Buytaert, the Drupal project lead, in order to tackle strategically vital initiatives within Drupal core. Membership includes the initiative leads. This would entail a bit more formalized structure, including milestones and progress tracking, bi-weekly meetings among the various initiatives, and so on.
This would be essentially formalizing what already exists today with the Drupal 8 initiatives and initiative leads.
At the Governance Sprint, we agreed to continue not to impose any additional governance structure on contrib, by design. This allows contrib to be an incubator not only for technical solutions, but also for governance itself.
The exception would be conflicts between maintainers or maintainers and their users which are not able to be resolved among the individuals. These would then go to either the Community Working Group or Technical Working Group, as appropriate.
Security and documentation teams
We have a few overall "Teams" that touch elements of the product, including the Documentation Team and Security Team (we also discussed the establishment of a Support Team). As part of the new governance model, we recommend creating charters for these teams that make it explicit to others what their roles and responsibilities are, how to join, and what is expected of them. It's likely these charters will be modeled after something like the Documentation Team and Leader Responsibilities page.
"Operations / Administration" groups
These groups act in support of the Drupal project and its community. The ultimate "buck stops here" with these groups is with the Drupal Association board instead of Dries. Many of these have a financial impact on the Drupal Association and greatly affect its ability to get things done in support of its mission.
And what about Drupal.org?
Next to Drupal core, this is probably where we spent the most time discussing. Drupal.org is special, in that it straddles both the community side of things, as well as the operations / support side of things. It functions through a combination of numerous volunteers as well as funding via the Drupal Association for support staff and development on major initiatives.
At the moment, the best place to put Drupal.org seems like it's at a halfway point between the "Drupal" and "Operations" sides of things, and for the charter of this working group to include the necessity to work with the Drupal Association and community members alike. Though eventually, for both legal and simplicity reasons, it would be better for this to be located under the purview of the Drupal Association board.
A few areas there was broad agreement on, however, were the following:
- Split off a separate "Drupal.org content" working group from the "Drupal.org webmasters" working group; different skills/levels of trust are needed for managing the content on Drupal.org versus managing access and performing moderation of abuse.
- Identify a much smaller subset of the Drupal.org webmasters group to form policy for this team. Currently, there are nearly 150 members with "site maintainer" privileges, and they often make and enforce policy on an ad-hoc, individual basis. Community members currently encounter very inconsistent experiences in the queue.
- While the Drupal Association doesn't manage these groups, it's generally expected that the charters of these groups will include directives to collaborate with the DA in their policy-making decisions in order to ensure the financial sustainability of Drupal.org.
We're very interested in community feedback on this direction, either in comments below or privately. We'll provide an update on the progress at DrupalCon Munich.
We encourage everyone to come and get involved in this discussion. As our community grows, it is essential that we come up with a governance structure that matches our core values and allows us our community to be more sustainable for the long haul.