Passive income and Open Source

Everyone dreams of making money while asleep. The term "passive income" is often defined as income that is received on regular intervals without requiring a great deal of work to sustain it. Usually some effort has to be put in upfront, but the payoff from passive income can last for years. Passive income is particularly relevant when it comes time to retire. Two techniques often recommended by financial planners are (a) rental properties and (b) dividend investing. Both can work well, not only as a retirement plan, but as a way to build steady income. Certainly the idea of collecting checks for the rest of your life with minimal effort sounds appealing.

Quite a few people that try to retire early are documenting their journey publicly. For example, Jason is trying to retire by 40 by investing in dividend growth stocks and Mr. Money Mustache retired at the age of 30 through rental properties. Many other great examples exist online; I love reading up on their stories and progress. There is a lot to like about their lifestyle too; a common theme among them is that they live frugally.

So what does this have to do with Open Source? I love Open Source and Drupal and would like to see even more contributors. I think a lot of developers would love passive income so they have the freedom to contribute to Open Source more, preferably even full-time. Many developers also live a frugal life; passive income may be a good option to explore. But also, what about a third passive income technique: (c) websites? I know several people who have a number of websites, some of which they haven't touched for months, yet they still bring in around $500 a month. Owning a few websites could provide a wonderful chance to earn passive income, and it so happens that many of us in the Drupal community have a talent for building websites ... Food for thought.

Growth of Acquia Cloud

It's been a while since I wrote about Acquia Cloud so I wanted to give you a quick update. Acquia Cloud has experienced incredible growth so far in 2013. We recently crossed a milestone that I'm proud to share; we’re now running over 6,000 cloud instances on behalf of our customers in six Amazon regions stretching across North America, Europe, Asia and Australia. These instances are used to run a wide variety of Drupal sites; from e-commerce to collaboration to marketing sites, and more.

All that capacity served over 18 billion requests in May, with many more requests served via our CDN partnerships. Compared to last year, Acquia Cloud's traffic is up 200%. We also served over 232 terabytes of data in May. This astounding growth solidifies the scalability of Acquia Cloud. And it's only going to grow faster as Acquia is signing up larger websites.

Acquia cloud may

State of Drupal presentation (May 2013)

Two weeks ago at DrupalCon Portland, I gave my traditional State of Drupal presentation. A total of 3,500 were present at DrupalCon, a new record for DrupalCon attendance.

In good tradition, you can download a copy of my slides (PDF, 29 MB) or you can watch a video recording of my keynote (keynote starts at 14:00). The video of the White House guest appearance and the Drupal 8 demo video area also embedded in this post.

WYSIWYG and in-place editing for structured content

Karen McGrane gave a great keynote at DrupalCon Portland on future-friendly content with Drupal. It's worth watching the video recording. I agree with Karen's vision for the future. With the proliferation of different devices, screen sizes and input devices, there is a growing need for structured content that can be reused in multiple channels.

From the early days, Drupal has been doing structured content and content reuse better than most competitors. Drupal's node system was introduced in Drupal 3 in 2001, and was ahead of its time compared to the "page tree"-model used by most competitors. With every release, Drupal has gotten better and better at structured content and content reuse, leading to things like CCK and Views in core. Still to date, Drupal is one of the leaders in modeling structured content and content reuse. It is is one of the primary reasons we've seen so much growth. It was great to see that recognized by Karen.

One of the biggest gaps in Drupal has been the authoring experience. Two of the most noticeable authoring experience improvements that we are adding to Drupal 8 core are WYSIWYG editing and in-place editing. Where I disagree with Karen is with her belief that in-place editing and WYSIWYG editing are bad. Sure, WYSIWYG and in-place editing definitely can be problematic when combined with structured content. However, I believe we’ve implemented them in a good way -- it can't be compared to Microsoft Word's blob-like approach. I wish that Karen better understood how we have implemented this functionality. It would have been helpful if she had offered concrete suggestions on what better solutions would look like. Until we know what better tools look like, I'm convinced that Drupal 8's approach to WYSIWYG and in-place editing are a big step forward. It makes for another intermediate step towards a bigger vision.

We've been talking about the advantages and disadvantages of WYSIWYG for more than 10 years now, and we still haven't figured out better approaches. The best we've been able to do is to evolve WYSIWYG editing and in-place editing to apply to individual chunks instead of the entire page, to generate clean markup and to better guide authors to make them aware that their input may end up in many forms of output.

While implementing Drupal 8's WYSIWYG and in-place editing functionality, a lot of attention was spent on ensuring that these features are compatible with structured content:

  • WYSIWYG editors used to generate bad markup. Drupal 8's WYSIWYG editor guarantees clean markup thanks to the new "Advanced Content Filter" feature in CKEditor.
  • Drupal applies WYSIWYG editors to individual form fields instead of the entire page. You are encouraged to break up your content in many fields. Similarly, in-place editing is triggered on the entity level, not the page level, which means the user declares his intent to edit a specific entity and can then edit a specific field within that entity. In-place editing is only designed for quick edits, it wants to delight the author for those small edits, rather than forcing him to go back to the potentially overwhelming back-end form every time. At no point are authors given the impression they are editing the entire page.

For a more detailed explanation, see Wim's article: “Drupal 8: best authoring experience for structured content?”.

Want more features in Drupal 8? Help fix bugs!

In Drupal core, we use issue thresholds to manage technical debt. Both critical (release-blocking) and major (non-release-blocking, high-impact issues) are considered. When we have more open issues than our thresholds, we do not commit new features.

Currently, we have 27 critical bugs, 41 critical tasks, 155 major bugs, and 149 major tasks. This is more than twice our current thresholds for critical issues, and about 50% more than our thresholds for major issues. We need your help to resolve these issues so that we can resume adding new features to Drupal 8. That would be a very exciting place to get to!

There are many ways to help, including not only programming but also updating these issues' summaries, testing the patches, and making sure the patches still apply. I encourage everyone to collaborate on major and critcal issues, and to consider making them a focus at the DrupalCon Portland sprints.

Reducing risk in the Drupal 8 release schedule

Post-Drupal 8's feature freeze, we find ourselves in a similar state as we did after Drupal 7's feature freeze:

  • Some initiatives are mostly done, and now onto clean-ups.
  • Others are mostly architecturally there, but still have some pretty big gaps.
  • Still others are either not yet architecturally complete, have a major amount of integration/conversion work left, and/or have many outstanding critical/major bugs.

From here on out, we need to be more strategic about what patches we do and do not allow into Drupal core directly, and this means we have to make some tough decisions. Every patch we commit needs to not move Drupal 8 further from a "shippable state".

There are essentially two categories of initiatives (both official and unofficial) that are incomplete:

  1. Code already in HEAD, that we do not plan on reverting, and completion of which is critical to releasing Drupal 8. Examples are CMI, Entity NG, Router conversions. Incremental patches committed to these issues help move Drupal towards release.
  2. Code not currently in HEAD, or libraries that are sitting around effectively unused by the rest of Drupal. Examples are Twig, CSS re-organization, and parts of SCOTCH. Incremental patches committed to these issues move Drupal towards "uncharted territory", and could put the release of Drupal 8 at risk.

Therefore, the core committers plan to employ the following strategy when deciding what we do/don't commit to Drupal 8 going forward:

Commit decision flowchart

First, a patch will be evaluated to see if it belongs to a larger "meta" issue. For the vast majority of issues in the Drupal 8 queue, the answer will be no. For example, routine bug fixes and self-contained DX (Developer Experience) improvements can simply be committed once they're ready.

If an issue is part of a larger meta issue, the question will be whether that meta issue is critical to shipping Drupal 8. If so, the "does this move us towards release?" question is satisfied, and these patches will be committed as they're ready. An example of this is individual CMI conversions; we cannot ship Drupal 8 without all parts of it being deployable through the configuration management system. Similarly, we cannot ship with two methods of declaring routes.

If the meta issue is not deemed critical for release, but we can still ship Drupal 8 with part of it done, then we will also commit patches as they're ready. Views conversions are a good example of this. While it would be nice to ship Drupal 8 with all administrative pages converted to Views, we can still ship Drupal 8 with some converted and others not.

If the patch is part of a larger, non-critical meta issue, but getting part of it done is worse than getting none of it done (an incomplete state will hold up release of Drupal 8), then we're in a "danger zone" and need to look at possible options:

  1. First, we should see if the patch can be re-worked, or parts of it split off, into self-contained issues. Then those issues' patches can just be committed via the normal process.
  2. If there is no other option than completing the entire meta issue, then core maintainers will work with each individual team to determine a "cut-off date" for their work (which allows sufficient time prior to July 1 for integration), as well as the safest way for their work to continue without holding up the release. Possible strategies could include:
    • a larger patch containing the meta issue in its entirety, with no follow-ups, where it is still feasible to use a patch-based workflow (e.g. CSS re-organization).
    • a branch off the Drupal core repository that is merged in when deemed acceptable in the case of larger conversion efforts (e.g. Twig)
    • a sandbox project where larger refactoring is still necessary (e.g. SCOTCH).
    If the work is ready in its entirety (i.e. working upgrade path, passing all core gates) by the cut-off date, it will be eligible for Drupal 8. However, if not ready in time, it will have to be postponed to Drupal 9. While this is definitely painful for teams that have worked so hard but yet still miss the deadline, it is preferable to delaying the Drupal 8 release indefinitely.


The bottom line is that every patch we commit to Drupal 8 from now on has to help us get to a shippable state: it has to work, be performant (or be a required stepping stone towards more performant code), be well-documented and well-tested, and provide the right developer experience (DX). Getting Drupal 8 ready for release will take a big effort, and the core contributors could use all the help they can get. Now is the time to jump in and help.

Alex Pott

I'm pleased to share that Alex Pott (alexpott on has accepted my invitation to become another Drupal 8 co-maintainer, to help move along important issues as we gear up to head into code freeze and then release.

Alex has been working in Drupal for almost 6 years. While relatively new to the core development team, he has nevertheless been an instrumental force in the Drupal 8 Configuration Management Initiative (CMI). This development experience has given him a detailed understanding of various underlying Drupal 8 APIs, which makes him ideally suited to the task of reviewing and signing off on highly technical patches. Alex is furthermore thorough and patient in his technical reviews, and he has been a reliable leader and problem-solver during the Drupal 8 cycle. He is also currently taking time off from work, in order to have more time to dedicate to his family and to Drupal. It's a perfect fit.

When catch, webchick and myself were discussing who would be best to join the core maintainer team, Alex's name was enthusiastically +1ed from each of us. Please make him feel welcome!


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