In every open source project, at some point, the Benefactor Dilemma will occur. This dilemma can take shape in two forms. Either an open source project has a benefactor, or it doesn’t.

First, I think it is important to recognize the lifecycle of an open source project. The largest open source project (by utilization) is some flavor or another of GNU/Linux. Period. We can argue about specific distributions and different open source licenses but Linux (which I will use generically) powers phones, desktops, servers, automobiles, tablets, tvs, smart speakers, etc. etc. etc. It is literally the fertile soil that has driven internet innovation for decades. Here are some fun facts from The Linux Foundation:

• 100% of supercomputers use Linux
• 50% of global auto shipments supported by OEMs using Automotive Grade Linux
• 82,371 Commits to the Linux Kernel in 2019

Do you know how many individual contributors power this core of every human digital interaction? In 2019, only 4,249 contributors are listed. Four thousand two hundred forty nine. Let that number sink in, not relative to other projects but relative to value as well as businesses that use Linux. In 2019, Google surpassed 100,000 employees, Microsoft reaches approximately 144,000 full-time employees, and Oracle with 135,000. These are just some of the companies who rely on Linux as a core or part of their operations and business models.

With Linux as our example, we can say that this project is at the end of its lifecycle. I really like Red Hat’s description of the stages of an open source project. I have broken down the larger thoughts into bite-sized pieces, Understanding the open source software life cycle:

1. Solve a Problem
2. Formalize the Project
3. Public Collaboration
4. Community Building
5. Reliance
6. Support
7. Public Innovation
8. Maturity

It’s no accident that these stages similarly follow the stages of startups. From Lauren Bass, 5 Phases of the Startup Lifecycle: Morgan Brown on What it Takes to Grow a Startup:

1. Problem/Solution Fit
2. Minimum Viable Product (MVP)
3. Product/Market Fit
4. Scale
5. Maturity

So we can take the open source life cycle and with the startup cycle and combine a few of the items for a smaller list that we can cover:

The Benefactor Dilemma List

1. Solve a Problem
2. Minimum Viable Product (MVP), which includes:
   • Formalize the Project
   • Public Collaboration
   • Community Building
3. Community and Market Building, which includes:
   • Reliance
   • Support
4. Scale and Innovation
5. Maturity

At some point, in my opinion, somewhere between the end of stage 2 through the end of stage 3, benefactors appears. By benefactors appearing, let me very clear, money appears. People begin putting together business models, bootstrap or acquire capital, start generating revenue. Up until benefactors appear, the community rules the project, the members drive innovation, foster personal connections, and define what it means to be a part of the project.

Benefactors Drive Scale and Innovation

The monied benefactor eventually appears in successful projects because they are either a successful business utilizing the project (most likely the founder), or enough users have accumulated enough momentum to draw the eyes of investors where in the best positioned businesses will split the investments.

Two well known projects which have recognizable benefactors are WordPress (via Automattic), and Drupal (via Acquia). The benefactors each support the projects with significant contributions of cash as well as people. They traditionally hire and dedicate development time to the projects, from management to coding to marketing. This is incredibly important to the stability and scale of the project.

The Real Dilemma

At some point the fiscal and corporate requirements will clash with the community. It is absolutely certain that this will occur because the community, very much in a political sense, is made up of a multitude of constituencies. Contributors may have passion for the code, passion for the network, or passion for just contributing. The goals and motivations of one or more constituencies will not necessarily align with those who have the most money, and therefore the strongest “vote,” in the direction of the project.

So maybe the project foregoes the option of ever having a benefactor. Joomla is the perfect example. While there have been successful businesses built around the project, the very nature of project governance actually dissuades if not outright prevents the emergence of a benefactor. The project 100% volunteer based, and many of the volunteers spend significant time, and thereby creating momentum to continue a very flat organization. Scale and stability are completely dependent upon volunteers, and when there is excitement, this can be quickly and easily achieved. When excitement recedes that’s when a project begins to have issues. In the case of the Joomla project, getting the next major release of Joomla launched has taken significantly longer than expected.

Benefactors can provide consistent revenue and support to the project and help grow the economies of the project. On the whole this will make more people happy but can still cause political issues. It’s no accident that the nomenclature Benevolent Dictator for Life (BDFL) appeared amongst open source. When that BDFL has significant financial pull, this may exacerbate tensions. We saw this most recently when WordPress.com announced a professional services product that people felt competed against the larger community.

The Dilemma Solutions

I think there are a few solutions to the dilemma. First you can always take the ball away and go home – maybe not the best metaphor but open source is alway fork-able. That’s right, take the project, go home, and rebuild whatever is most important to you (just be careful of infringing copyrights which belong to the project).

Second, and less drastic, work to create a distribution and community around that distribution, Linux has been very successful in this regard, and I feel that a project like WordPress may soon see this happen. Well it is already happening to some degree from the hosting perspective, WP Engine has a different “distro” compared to Convesio compared to WordPress VIP, but those are very SaaS based.

Last, embrace the friction, what made the project compelling was solving a problem, problems will always appear, whether technical or competitive. I say lean into the newest challenge because the competition will seed new innovation in a project community, and there may me multiple options.