You are here
Last summer, a number of Drupal community members as well as key figures from other major open source projects met in Portland for the first-ever Drupal governance sprint. The proposal from that sprint recommended the creation of a number of chartered "working groups" to better formalize the existing governance of various aspects of the Drupal project, now that our community is at its current scale. We have now chartered the first of these working groups: the Community Working Group. Thanks very much to everyone who participated in the vigorous community discussion and drafting efforts around this.
However, while the governance proposal coming out of Portland provided some fairly solid direction on the governance of the Drupal project itself, it left some pretty big questions unanswered as it related to the governance of Drupal.org. Drupal.org isn't just some ordinary website. While it was originally a small portal with a few hundred members hosted on a friend's shared server, it is now serving millions of page views to over 2 million unique visitors per month, as well as terabytes of data, and is home to almost a million active members, among them thousands of contributors committing code, reviewing patches, improving documentation, etc. at all hours of the day. The old "do-ocracy" model of getting things done on Drupal.org isn't scaling for our community anymore, and lack of clarity around decision-making has cost us repeatedly, in the form of slow progress on the Drupal.org Drupal 7 upgrade, Drupal Association funding challenges and staff inefficiency, and various community volunteer frustrations.
I've therefore spent time over the past few months talking with a number of members of the Drupal Association, various Drupal.org volunteers, Drupal core/contrib developers, as well as other interested parties, in order to determine how to put into place a structure that clarifies the decision-making processes around Drupal.org. The following is the overall proposal for Drupal.org governance we've come up with, as well as links to more specific draft charters for community review.
Note: the finer points of this can be found in http://buytaert.net/files/drupal-governance-plan-2013.pdf.
While "governance" can sometimes sound like a scary word, really it's about coming up with a way to:
- Make decisions fast,
- In as lightweight a way as possible
- Allowing affected parties to have a say,
- With clearly-defined processes and easy to understand decision-making.
Cracking this problem for Drupal.org provides us with less frustration/uncertainty among volunteers, more money and resources funneled into improvements, and better community velocity overall.
Governance mostly comes down to establishing "working groups" around major areas of the project, many of which already have governance in at least an ad-hoc basis. Working groups will consist of a chair, plus 3-5 members who are empowered to make decisions, then a team of N volunteers and/or DA staff to help carry out their tasks/policies. The working groups are only empowered to make decisions as a whole, not on an individual basis.
Drupal project governance / Drupal.org governance compared
For the Drupal project, we are working towards developing a number of working groups related to various aspects of the community (security, documentation, conflict resolution, Drupal core, etc.), with myself as the final decision-maker:
The working groups might be compared/contrasted this way:
|Community working group||Technical working group||Security team||Documentation team||Drupal core X working group|
|Guarantee a friendly and welcoming community for the Drupal project by upholding the Drupal Code of Conduct.||Maintain technical policies, procedures, and standards as required to keep the technical side of our community operating smoothly.||Maintain technical policies, procedures, and standards as required to keep our projects secure||Make sure that we have high quality technical documentation for Drupal, including the Drupal handbook and API documentation||Provide technical leadership and project management for Drupal core development.|
In the case of Drupal.org, however, it makes sense for this final decision-maker to be the Drupal Association, since they are ultimately responsible for the website, purchasing hardware, etc.
The working groups might be compared/contrasted this way:
|Drupal.org infrastructure working group||Drupal.org software working group||Drupal.org content working group|
|Responsible for all infrastructure-related needs of the Drupal project, including the servers, Git repositories, mailing lists, DNS management, e-mail management, network, server access and security.||Responsible for guiding the planning, architecture, development, and maintenance of the Drupal.org websites.||Responsible for maintaining policies around the major content areas on Drupal.org. They also manage the overall look and feel and voice of the website, including its information architecture and design elements.|
Needless to say, groups will often have to work together. For example, to answer the question of whether to keep developing project module or move our collaboration tools to Github, we'll have to get the following groups together: (i) the Drupal.org software working group because it affects the features of drupal.org, (ii) the Drupal.org hardware working group because they may need to host new features, (iii) the technical Working Group because it impacts how we collaborate on software development, and (iv) the Drupal Association Board of Directors because they have to write the check.
Draft charters for review
This is a work in progress. Please help shape the future of Drupal.org governance by reviewing and commenting on the following proposals:
- Drupal.org Infrastructure Working Group
- Drupal.org Software Working Group
- Drupal.org Content Working Group
- Technical Working Group
- Community Working Group (Already formalized)
Our plan is to allow everyone in the community to provide feedback during the next 3 weeks. Then, around the end of March I will post updated drafts based on community feedback, with the aim to finalize the charters by the mid-April.
Onward and upward
I'm really excited about the possibilities for Drupal.org in the future with this governance structure. My hope is that this helps address some of the ambiguity and confusion around the current structure, while at the same time not being overly constrictive.
Thanks in advance to everyone for their participation in helping to shape the future of Drupal.org!
Note: some of the information on this page is out of date. For the latest information about how Drupal releases are managed, see http://drupal.org/core/release-cycle.
As of Monday, February 18, Drupal 8 feature completion phase has officially ended. Since December 1, the original code freeze date, we've managed to add numerous awesome features that were previously in-progress, such as:
- WYSIWYG with CKEditor
- In-Place Editing
- Entity Reference Field
- Date and Time Field
- Revised content creation form
- Tour module to offer step-by-step help
- API support for Multilingual configuration
- Revamped and far more usable UI for configuring translatable entities and fields
- A RESTful API for entity CRUD in Drupal core
- Support for Views to be output in JSON, XML, or other formats made available by contributed modules
- Important under-the-hood improvements to allow for native ESI/CSI/SSI caching support in Drupal.
There are also a handful of features that were RTBC by Feb 18, but not quite ready for commit. They are still undergoing consideration. All things considered, I'm glad we extended the code freeze.
What happens now?
We now enter the "clean-up" phase of Drupal 8, where focus turns to refactoring of existing subsystems, better integrating features, and improving the consistency and coherence of the existing functionality. While APIs can and will still change as this coherence shapes up, contributed module authors are nevertheless encouraged to start porting their modules now, as there is still time to influence and fix APIs and the overall developer experience in Drupal 8. This will become much harder as we get closer to code freeze.
So ... REALLY, what happens now?
In the course of adding all of the great features we've added so far to Drupal 8, we've accumulated some technical debt and are currently well over the issue queue thresholds for Drupal core. We roll a release candidate of Drupal 8 when there are 0 critical bugs and tasks remaining. Our over-arching goal should therefore be to reduce the number of threshold issues over time.
At the same time, there are a lot of small, non-destabilizing features that would make Drupal 8 better. Especially for the kinds of iterative improvements that we would allow into 8.1 or 8.2, it doesn't make sense to hold those up until then, if we're able to get them into 8.0 without it delaying the 8.0 release date.
To help with this goal, catch and I have discussed a plan for allowing some features to continue to be committed to core up until RC1, providing we are under thresholds. To help guide us towards release, we plan to reduce the critical task/bug thresholds by one per week, starting the week of code freeze:
- July 1: 14
- July 8: 13
- July 15: 12
- September 2: 5
- September 9: 4
- September 16: 3
- September 23: 2
September 23 is the week of DrupalCon Prague, and our goal would be to come out of the conference with a first Drupal 8 RC by fixing the last two critical bugs and two critical tasks (or however many there actually are) at the sprint. :-)
However, there are some caveats:
- Features can't require any new major/critical follow-ups, as that would impact the timing of release. In general, this means no new "big" features, as those tend not to be possible to accomplish without some fairly large follow-ups needed (e.g. Responsive Layout Builder, Project Browser, a new core theme, Symfony Form API). These kinds of issues will likely be moved to Drupal 9.
- Primarily, this means small, self-contained, iterative improvements that we'd be willing to backport to Drupal 8 (see http://groups.drupal.org/node/210973).
- Committer attention will generally be prioritized on tasks/bugs first, rather than features.
For now, we've decided to leave the major bugs/tasks threshold at 100 throughout release, and not tie them to the release date trigger for Drupal 8. I will re-evaluate this as we get closer to release.
What isn't bound by thresholds?
We obviously want Drupal 8 to ship as a coherent product, so a major focus will be around better integration of existing features. For example, work required to get the Symfony pieces of Drupal working well with blocks and enabling ESI/CSI/SSI caching. Turning administrative pages into Views so that they can be better tuned for the task at hand. Completing conversions of major APIs such as Twig, new Entity API, CMI, and so on, to fix rough edges such as the inability to translate/in-place-edit node titles.
General guidance on what constitutes a task or a feature is available at http://drupal.org/node/1181250. As we work through the list of these integration items, some features may be recategorized into tasks. At the same time, some issues currently categorized as tasks go beyond strictly integration and polish and will be descoped or recategorized as features.
While we still have a lot of work to do, I want to pause and give a sincere thanks to each and every one of the 1,077+ contributors to Drupal 8 so far. You've all done absolutely amazing work and helped establish Drupal 8 as a far more usable, flexible, designer-friendly, future-proof framework for all of us to use for the years to come. Now let's band together and get our baby polished up and out in the world for everyone to enjoy! :-)
I'm happy to announce that Lee Hunter has been appointed as the new Documentation Team Lead for Drupal. Lee has been a long term member of Drupal's Documentation Team, and has been a technical editor for thirteen years of his professional career. To read about Lee's vision for Drupal's documentation, please check out his announcement blog post. The short version is that he will focus primarily on coordinating the effort to document Drupal 8 and exploring ways of making Drupal a more effective tool for technical communication.
From 2010 to 2011 the Drupal Documentation Team was led by Jennifer Hodgdon (jhodgdon) and Ariane Khachatourians (arianek), and up until July of year just Jennifer. Without their leadership and effort, tens of thousands of people would have faced great challenges in using Drupal. I'd like to thank Jennifer and Ariane for the tremendous effort that they put into the documentation team.
Documentation is one of the most important aspects of Drupal, and not one that we should take for granted. Please join me thanking Jennifer and Ariane for their work, and in welcoming Lee as Drupal's new Documentation Team Lead.
Today is bittersweet for the Drupal Association, as Jacob Redding has transitioned the Executive Director role to Holly Ross. Jacob did a phenomenal job growing the Drupal Association, Drupal.org and Drupal as a whole. Jacob’s special attention to the community has helped create a culture that many of us are proud to be a part of; his passion and dedication for Drupal has always been evident.
Under Jacob’s leadership we have broadened our activities, streamlined operations and significantly increased revenues. The Drupal community members grew by 1143% to 800,000 and we gained 3286% more committers to 23,000 in just three years. That said, our DrupalCon sizes and attendance expanded, which has helped increase Drupal adoption throughout the world. The Drupal Association staff of 12 has settled into Portland and is well positioned in Oregon's active open source community.
With Holly onboard, our vision remains to become the largest open source, non-profit organization that continually increases its support to the community and project. Jacob, thank you for all your hard work and tenacity! I look forward to continuing to work with you in the community.
When we first announced the Spark authoring experience initiative for Drupal in May of last year, we chose Drupal 7 as our target in order to develop the features and get them in front of testers as quickly as possible. After DrupalCon Munich in August, the team shifted efforts towards Drupal 8 core instead, in order to more directly improve the experience of Drupal itself. Since then, we have successfully worked with the community to drive home a redesigned and mobile-friendly toolbar, support for draft revisions, in-place editing, numerous mobile improvements, and have WYSIWYG and unified in-place editing on the way.
This has kept the team pretty busy, however, and so the Drupal 7 version of Spark has not been receiving many updates in the meantime. Olivier Friesse (noisetteprod) of Radio France graciously offered to sponsor work to help things along. Thanks to this sponsorship, we were able to have Théodore Biadala (nod_) of Acquia's Professional Services team spend 3 weeks on getting the in-place editing feature production-ready for Drupal 7, including:
- Full backport of Drupal 8 code, including Create.js/VIE.js integration
- Integration with CKEditor module to provide WYSIWYG support for rich text areas, which resulted in numerous upstream improvements
- Removed requirement on jQuery 1.7 so that Edit module can work on stock Drupal 7 installations without jquery_update module
- Removed requirement on PHP 5.3 so Edit module can also work in PHP 5.2 environments
- Basic support for Views/Panels in-place editing
- Numerous bug fixes to help further stabilize the code base
Working towards a stable release for Drupal 7 naturally identified bugs with the Drupal 8 implementation of inline editing, which are being tracked in this issue: https://drupal.org/node/1894454.
In short, the needs of Radio France have brought tremendous value for the entire community, in both Drupal 7 and Drupal 8. If you'd like to try out the work that we've done, download the 7.x-1.0-alpha7 release of Spark or Edit 7.x-1.0-alpha6!
Thanks once again, Olivier and Radio France, for your support! If other companies would like to sponsor further work on Spark, please let me know.
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.
A major focus of usability efforts in Drupal core has been around making it easier to edit things on your site. In Drupal 7, we introduced the Contextual links and Overlay modules to make it simpler for content authors and site builders to jump directly to the parts of the administration that relate to the things they see directly on the page, such as blocks or menus. Drupal 8 has now upped the ante with the new in-place editing feature, which allows for direct modification of content on your site, within the context of the page it is displayed on.
The next logical step is to take in-place editing to the next level by unifying contextual editing paradigms: combining the concept of "edit mode" with the ability to contextually edit more than just fields on content, in order to allow for contextual editing of everything on the page, in a mobile-first way.
Specifically, we need to address the following challenges:
- Conflicting patterns confuse users: There are contextual gears to edit content, local tabs to edit content, and "Edit mode" to edit content. These patterns need to be streamlined.
- Tasks are not intuitive enough: Seemingly simple tasks can often result in "pogo-sticking" around in the admin backend trying to locate where to change a given setting.
- Unnecessary information slows users down: Drupal forms tend to be long and full of advanced/confusing options, which can overwhelm users trying to complete simple tasks.
- Interactions don't work with smaller devices: With Drupal 8's Mobile Initiative, it is critical that these tools be as easy to use on the desktop as they are on a smartphone or tablet.
Here is a video showing what we'd like to propose for solving these problems in Drupal 8 core:
We've now performed several rounds of internal usability testing on this functionality, and it has tested really well so far, with a high emotional value: in general, people can't believe this is Drupal. :-) Check out the prototype yourself at https://projects.invisionapp.com/share/U2A4IAGX.
I'm very excited about these changes, and feel that if we can get this into Drupal 8 it could be game-changing. But what do you think? If you like it, we'd love help with implementation and reviews in the core issue at http://drupal.org/node/1882482.