How modern open source projects work

By definition, “open source” has little to do with how software is actually created.

Instead, open source refers to how the source code for a software development project is distributed and consumed by software developers working on other projects. It is essentially a blanket term that refers to any software that makes its source code available to others. To be open source, the software project must be released under an open source license, of which there are two main categories: Copyleft and Permissive.

• Copyleft licenses such as the GNU GPL place a series of restrictions on how the source code can be used with the aim of ensuring that code changes are always publicly available. These licenses are used by software projects that provide a core feature to the entire community (e.g., the Linux operating system).
• Permissive licenses such as the MIT and BSD licenses place few restrictions on how others can use and redistribute the source code. As a result, these licenses promote adoption in other open source projects. After all, if there are few restrictions to worry about, you’re more likely to use the source code.

Back in the early days of open source (the 1990s), open source developers were seen as hobbyists that were not financially motivated to make software, but instead dedicated to “software freedom.” However, in today’s rapidly evolving digital world, open source is a requirement to keep up with the needs of organizations and technology. If every software developer had to “reinvent the wheel” by creating all the components of their software from scratch, we’d be stuck in a technological purgatory that would make Windows XP seem cutting edge. Plus, the cloud as we know it today simply wouldn’t exist.

And while open source has spread like wildfire in the software industry these past few decades, so have new open source-focused tools, processes, and practices. The open source development tool that created the biggest shift in open source developer culture is GitHub. GitHub is a version control and collaboration platform that supports all of the needs of an open source project and those that participate in it. Plus, by making it easy to find other open source code, it promoted cross-project code adoption and helped popularize permissive licenses.

Unlike the early open source developer cowboys of the 1990s, modern open source developers place a lot more faith in the open source ecosystem and less on individual ownership. It’s assumed that if one developer quits from an open source project, another will take their place. Similarly, developers don’t feel as the code is theirs in a possessive sense. When a modern developer says “this is my code”, it’s more like “this is my aunt” (something they’re associated with but don’t own) versus “this is my laptop” (something they own).

When it comes to money, modern developers are rarely concerned with how it is generated. Since open source software is a critical component of nearly all software projects, it generates revenue somehow. And developers working on open source projects also get paid somehow. The actual specifics of where the money comes from and who is paid varies tremendously, but most open source developers work for some organization. This nonchelance regarding money also means that the modern open source developer doesn’t have the same hatred of closed source software companies (e.g., Microsoft) that defined early open source developers of the 1990s. When Microsoft bought GitHub, most open source developers really didn’t care. Instead, modern developers are more like YouTube content creators; they care more about having good tools and a platform that promotes their work to others than lofty open source principles and code freedom.

So how does a modern open source project evolve?

There are usually three main phases that any open source project goes through:

1. Creation. This is often done by one or a few developers to create a minimum viable product (MVP).
2. Evangelism. The original developers that created the software promote the heck out of it by talking at conferences, posting online, and so on. The aim is to get other developers interested in either adopting the software, joining the project team, or both.
3. Growth. This is when the the original developers of the project step back and provide less coding as other developers join the project and momentum builds. The original creators usually hand off the project to others at this point, or stay on to do more non-code-related stuff like approving changes and triaging issues that others bring up.

Who participates on a modern open source project?

In general, there are four main roles in any modern open source project:

1. Author. This is the developer (or developers) that created the original release of the software. In other words, the person who was intrinsically motivated to create something new to solve a project. Most authors hand over the reins to someone else (a maintainer) after their interest wanes. In other words, they hand over the commit bit (permission to make changes) in the software repository (i.e., GitHub repo).

2. Maintainer. This is the current lead developer (or developers) on the project. While there is no standard definition for this role, maintainers are generally focused on things that are in the best interests of the overall project, and often deal with bug reports and test infrastructure. Maintainers can also get a lot of unwanted flack by software users (questions, feature requests, and general time wasters). Consequently, successful open source projects usually have people (or bots) that help curate or ignore these requests appropriately (e.g., moderators that push certain questions onto forums where they can be easily answered by other users). Additionally, maintainers work with the other developers on the project and set the rules for contribution. To ensure that things run smoothly, they often produce and enforce code style guides, linters, as well as templates/checklists for submitting code changes (called a pull request on GitHub). All of this means that as an open source project grows, it’s more likely to become modular so that each module can have separate maintainers. Modular projects also reduce technical debt. Technical debt occurs when developers take coding shortcuts to fix critical/security bugs fast; these developers will eventually have to rewrite (or “refactor”) these coding shortcuts properly at some point in the future (ugh).

3. Contributor. This is any developer who contributes code to an open source project. In most projects today, more than half of all contributors only contribute once and are called casual contributors. Conversely, a small number of developers are typically responsible for most (e.g., 75%+) of all code changes and are called active contributors. Most active contributors have a vested interest in the open source community and maintain a good reputation. And a good reputation usually ensures that code changes are quickly approved by the project maintainer.

4. User. This includes anyone who copies the source code from an open source project. Users that are more involved in the project are called active users because they educate (blogs, videos, live-coding, presentations), support (answer questions online), or submit bug reports. Another interesting aspect of open source is that when a project is used by a moderate or high number of users, it’s usually maintained forever. Ever heard of COBOL?

How do we determine the success of an open source project?

Open source projects vary tremendously in size, importance, and growth. While some projects attract more contributors than others, this isn’t a good measurement of success. After all, most successful JavaScript frameworks have a very low number of contributors but a very high number of users.

In general, the larger the number of users overall, the more important the software is, regardless of contributor or user growth over time. Moreover, if the project is used as an integral part of another project that has a high number of users, then it should also be considered successful.

Open source projects that never garnished a solid user base, or have fallen out of relevance (e.g., due to better competing projects) are seldom actively maintained. In these projects, there’ll likely be little maintainer activity, or a backlog of open issues and code contributions from other developers, all of which can be easily determined by viewing the project’s repo on GitHub.