Open source is not black and white, it has multiple dimensions of openness, transparency, collaboration, and trust. For some open source is any project on Github, for some it has to pass the OSI definition, and for some, there it has to comply with the unwritten but commonly accepted open source norms. Here I’ll share with you how I think about evaluating open source projects by looking at some of the business and technical aspects first and then exploring the community management customs.

Disclaimer

• These are my personal opinions and not of my employer or the software foundations and projects I'm affiliated with.

• This is not a legal or professional opinion (I’m not a lawyer, nor specializing in OSS evaluation), but a layman’s opinion.
  Update: I got feedback from multiple open source lawyers and updated the article!

• This blog post is sponsored by the subscribe and share buttons, hit these buttons to express support.

Intellectual Property

The very first question to ask about an “open source” project is about the ownership of intellectual property. The good news is that, even without understanding these legal implications, there is a simple Litmus test you can apply. Does the project belong to a reputable open source foundation that you trust? For example, FSF owns the copyright for the projects it host, and more often, foundations (such as ASF, LF) aggregate the rights to license contributions to their projects, through contributor license agreements. In either case, you can trust that they will act as good decentralized stewards and won’t change a project’s future direction overnight. If a project doesn’t belong to a reputable software foundation but is backed by a single company, the question is if you trust the company as a supply chain partner. If the answer to these questions is yes, move to the next section. If the answer is no, then you better investigate and find out who the copyright owner is, and what are their long-term prospects and potential risks for you. A single vendor open source project today, can become closed source tomorrow.

License

The reason why trademark comes before the license is because the rights-holder (usually the author) of software grants the end-user permission to use one or more copies of software through a license. A free-software license is a notice that grants the recipient of the source code or its binary form, rights to modify and redistribute that software. Without the license, these actions would be prohibited by copyright law. The important point here is that the rights-holder can change their mind and change the license. The rights-holder can decide to distribute the software under multiple licenses or change the license to a non-open source license at any point. It is also possible the software is in the public domain, in which case it is not restricted by copyright law. Public domain does not equate to an open source license and this is a less popular approach we can ignore here. 

Again, without being a lawyer, here is a layman's Litmus test for a license: Is the project licensed under an OSI approved licenses list? If the answer is yes, then you can rely on the due diligence of these foundations for reviewing, classifying licenses and pointing out any limitations. If the answer is a no, ask your company lawyer to review and interpret every word on the license and the possible license compatibility implications. 

Governance

With the remaining checks, we are moving from more business and legal aspects, towards technological and community concerning areas of open source projects.

Opens source evaluation framework

Assuming that there are no concerns about the trademark holder party (your future partner), the license (the terms under which you consume the open source software), the next question is governance. Governance is the rules or customs by which projects decide who gets to do what, how they're supposed to do it, and when. It defines the duties, privileges, and authorities associated with different project roles, and how people get assigned to and removed from roles. Examples here are small day-to-day activities such as who has the power to approve a pull request, to vote for a release candidate, agreeing on the project architecture, defining a project roadmap, and electing the project governance board. 

If you are evaluating a project that is strategic for your organization, you want to know who is in charge. Not only that, you might even have the ambition for your developers to have a say in the direction of the project. 

There is again a simple Litmus test: for projects in open source foundations, there are clear rules on who can vote on important decisions, and how you can be part of decision-taking committees. In some foundations such as ASF, it is based on individual community member merit, and in some such, as CNCF it starts by being an employee of a paying member organization. In the blockchain based open source projects it is based on the vote of the token holders. Other foundations have different rules but they all strive for neutrality and decentralization of power among multiple participants. If a project is governed by a single company, or a single individual, you are trusting them to make the best decisions in the interest of the project and the community. Some of these projects may have written down governance rules that they follow, and some might not at all. It is up to you to figure the governance dynamics and their importance for your project involvement. In addition to having governance transparency and taking decisions in the open, the other aspect here is the level of trust and reputation of the governing body. When you look at the governance board of a project, is there a leader or a group of leaders with proven technical and social skills that give you the confidence that they can take the project to the next level? Or do you see a group that is constantly arguing in political fights? These are some indicators of whether an open source project will be successful and grow in the long term, or headache and stagnation are to be expected.

Infrastructure

Having an open source license may qualify a project technically as open source, but that doesn’t say if a project is built the open source way. There are many examples of software released under an OSI-approved license but developed behind closed infrastructure. By infrastructure, I mean chat channels for quick questions by users. Forums and mailing lists where deeper developer discussions happen. Source code management systems where pull requests are reviewed, and build servers where tests are run and nightly binaries created.

For business people and lawyers looking at an open source project, these might not be important, but for the techies that are going to use an open source project, these are some of the assumed benefits. The check to do here is to explore if the software is developed the open source way using an open infrastructure and not behind closed doors. Here are a few example questions:

• Can a user ask a question on the project chat and get an answer from another user without a middleman?

• Can a developer reach out to project committers and get a deep technical question answered?

• Can you run the latest build and confirm a reported bug is fixed?

• Can an architect the weekly community call and figure out the future direction of the project? 

With a closed infrastructure, you have to create a support case and pay to get answers to similar questions. With an open infrastructure and open participation, the answers are available for those who know how to work the open source way.

Community and Adoption

One of the main benefits of open source software is that it allows great ideas to be developed and spread around virally. You may have the greatest technology, the most permissive license, and open development, but if the software doesn’t have a growing community and increasing adoption rate, that is a sign to investigate. Different projects will have different adoption rates. Some may quickly grow into the mainstream or be replaced by others who do that. Some projects may have a small but persistent growth rate and a niche community lasting for decades. Community size and adoption rate are the ultimate longevity indicator for an open source project. Here are some of the example questions you can ask:

• How many active developers (committers) are in the project and what is the average commit rate?

• How many users are subscribed to the user forums and how many questions have been asked in the last month?

• How many times the latest stable version of the software has been downloaded?

• What other projects and services are dependent on and using this project?

• How many commercial organizations are backing this project?

• Are there commercial organizations offering products, support, and services around it?

• How many StackOverflow questions are about this project?

• How many books, conference talks, and job descriptions are mentioning this project?

Running these questions will give you an indication if the project is growing and becoming a de facto standard in its domain or stagnating and likely to be replaced with the next big thing. 

Typically, open source is associated with fast-paced development and innovation. At the same time, open source is also a mechanism for creating wide adoption and creating unofficial standards. Many open source projects have turned into standards such as Kubernetes for container orchestration, Apache Kafka for streaming, Apache httpd for web servers, etc. One of the most expensive things in software is finding people with the right skills. Using open source projects that have a high adoption rate will give you a better chance of finding skilled people and allow them to reuse their skills for longer.

Conclusions

Depending on the criticality of the open source project, there are different risks and criteria for evaluation. For strategic, hard to replace projects, that will be at the foundation of your IT infrastructure, you want well-established projects that have turned into de facto open source standards in their fields. It is important here to identify who owns the trademarks of the project and who is going to be your long-term partner. Typically these partners would be the member organizations of the software foundation where the project belongs or the single company holding the project IP. For the latter, you may want to consider the long-term risks such as the chances of core developers forking the project, a hyperscaler offering the project as a service, company acquisition, etc. 

For non-strategic, tactical, short-lived projects where the speed of delivery is most important, you can let your developers to drive the selection and pick a project based on openness, community collaboration, and hotness (important for some frontend technologies). Here short-to-medium term risks such as regular security fixes, developer support, and license compatibility checks might be enough.

In either case, there are no single evaluation criteria that fit all. You will have to balance among long term business risks, technology stability on one hand, with the latest hotness, innovation and developer satisfaction, on the other. The framework here will give you an overview of the areas to explore and some of the risks to consider. Good luck!

Open Source Eras and relative adoption trend lines

In this post, I will look at open source evolution broadly, try to analyze what are some of the triggers and enablers for the change, and where it might be heading next. Let’s start with the main open software development eras by summarizing the main trends and then focus on the big picture with an attempt to predict the future.

Free Software (1980)

The term “free software” is attributed to Richard Stallman around the 1980s for using it for the free-software movement. During these early days of computing, Richard started the GNU project in an effort to cultivate collaboration among the early hacker community and create a freedom-respecting operating system. He campaigns for software to be distributed in a manner such that its users receive the freedoms to use, study, distribute, and modify that software. This era set the origins of open source and more importantly the free software licenses (such as GPL) that flourish later.

At the time, the main software creators in the open were the individual hackers and in their view of the world, the software had to be free as speech and remain so. Free software grew because personal computers became more widely available to these hackers and they used CDs, floppy disks, and the early internet to distribute software and spread their ideology.

In this pre-internet era, manual distributions of software, supporting documentation, consulting services (installation, development), selling-exceptions were some of the popular monetization methods.

Open Source Software (2000)

The term "open source" was used by a group of people from the free-software movement around 2000. The motivation for this new term was to free itself from the ideological and confrontational connotations of the term "free software" and make it more appealing for the business world. The supporters of the open source movement stress the subtle difference from free software where free software requires any changes to be submitted to the original maker for redistribution, and any derivative software must also be distributed as free software. This new term set the beginning of a new movement and the forming of Open Source Initiative to educate and advance open source culture. The open source movement allowed smaller companies to play a more significant role in the software economy by giving them access to the software needed to compete in the global market. Before that, it was the larger corporations, the producers of the networks and hardware who had the power.

Open source sparked from the early hackers community but grew rapidly into open source businesses, enabled by software foundations, the internet, and the wider adoption of open source by companies of all sizes. The primary monetization mechanism for the open source software is through support and the open core models where additional accompanying value is created around the core open source project. While this open core (enabled by permissive licenses such as MIT, Apache) allows everybody to benefit from it, it is also its Achilles' heel as we will see next.

Shared Source Software (2020)

Open source licenses give more freedom to the users, but they don’t give many advantages to the producers of the software. Many small projects with a handful of maintainers create huge economic value which ends up captured by other companies with better operational capabilities to monetize. This leads the maintainers of these projects to remain below the poverty line. Other companies hire open source maintainers as full-time employers and bet their company existence and brand into the success of their open source project. Yet they got disrupted and threatened by even larger hyperscale SaaS providers who have the scale to capture the economical value more efficiently and faster from the same projects.

This new economic reality started forcing individual maintainers and small companies to move their software away from business-friendly open source to other free software inspired derivative licenses and pursue dual-licensing models. This new family of licenses is not proprietary, but they don’t fit the open source definition either as they protect the trademark owner from the competition by discriminating against certain ways of software distributions such as SaaS. This transition of new and existing open source projects to non-open source licenses indicates the start of a new era. Keeping the source partially open is primarily for marketing and user adoption purposes rather than collaborative development and keeping software useful for everybody. This shared source software era is triggered by the existential threat of not being able to offer the software in a way demanded by consumers (as a SaaS) and efficiently capture economical value by the creators whether they are individual contributors or large companies with an open source business model.

Open source software eras and main characteristics

Protected by these new licenses, the enablers for the modern-day independent hackers are the powerful online services that allow them to offer good quality software through globally available automation tools based on git, build tools, software scanning, and distribution services, etc. These hackers can build enough critical mass of supporters through social media and are able to capture economical value through services such as Github sponsors, Patreon, Tidelift, and many others. The other group, the disrupted open source companies are transitioning to the SaaS based distribution of software as vertical cloud services on top of the hybrid cloud infrastructure to compete with cloud providers. This allows the creators of the software to offer their service on multiple clouds and at the same time align with the way users prefer to consume software, which is as a service.

What Will Software After Open Source Look Like?

The start of a new trend doesn’t indicate the end of the existing eras, but a new addition to the mix. Free and open source software will continue growing at a huge pace. At the same time, I believe we will see an acceleration of the trend towards the so-called shared source and source available licenses too. This will double down on the dual-licensing of smaller library projects by individual developers and the SaaS-based distribution of bigger projects. The open core and open source models will remain here, but the open core of the projects will get smaller and smaller, practically useless for the competitors. We will see projects starting as open source during bootstrapping and initial adoption phases, and then transition to source available licenses when threatened by more operationally mature competitors. Unfortunately, this initial phase of uncertainty and adaptation in the shared source era will limit collaboration among competitors and demonstrate the importance of open governance and open funding through neutral software foundations or decentralized technologies.

Then we will see cycles repeating and independent hackers flourish again, innovating as in the free software era. But this time they will be better equipped with better infrastructure to support their livelihood as independent small businesses of one. They will start projects in the open to scratch their itch, but quickly turn them into businesses or let them die. They will be less ideological, and more practical. These independent hackers will not need to be part of the traditional horizontal software companies that bundle engineering, marketing, sales, support, education, etc to be successful in the software business. Instead, they will be able to consume unbundled vertical online services and deliver enterprise-grade software. We will see a rise in the tools and platforms that offer reliable project governance without joining a foundation or consortium. Independent software builders can use decentralized infrastructure, tokenize their projects, and customize the governance through on-chain community voting. The economical and governance aspects of the projects will be merged with the source code and licenses into a holistic entity enabled by blockchain technology and create opportunities for individual hackers to create million-dollar companies.

The infrastructure for independent techies will not be only for the software builders but for the whole ecosystem. Creating software is not enough, it has to go through the full pipeline of budgeting, building, marketing, hosting, sales, support in order to grow and remain sustainable. Speculators will put money into project tokens to help bootstrap projects and gain returns. Developers will build. Indies will create niche services complementing larger projects. Subject matter experts will provide consulting services and online training, and bounty hackers will hunt for ad-hoc work. Sometimes all of it will be driven by a single person, and sometimes a whole decentralized ecosystem forming around a project without the dominance of a central business entity. This will take a generation of software builders...

Conclusion

At the beginning of the open source era, Eric S. Raymond described a decentralized software development process called The Cathedral and The Bazaar. This era proved that the bazaar is the superior software development model. But at the same time, this era also showed us the limitations and the narrow mindedness of this model when it is not accompanied by a holistic governance and monetization view. The next era will improve on the same decentralized development principles by incorporating decentralized monetization and governance too. This will take us the full cycle of Decentralized and Sustainable Open Software nirvana.

If you like my explorations of opensource, blockchain, monetization, sing up to the newsletter or follow me on twitter.

The meaning of open source in 2021

In the past, the value of open source was in the source code and we can see that in the essential freedoms of free software and the distribution criteria of the open source definition. That is no longer the case. Today, open source is produced fast, but more importantly, it is rotting and getting obsolete even faster. There are other characteristics of open source projects than access to source code that is valued. The value of open source is in adoption that sometimes can be up to the point that a project becomes the de facto standard for a certain class of technology (such as Apache Kafka for messaging). The value is in the loosely coordinated, open collaboration and partnership among competing participants towards a joint goal (such as Kubernetes SIGs contributors). The value is in the long term sustainability of a project, that can outlive a company acquisition or bankruptcy (such as Oracle and the Jenkins project). Today, the successful open source model is more an epitome of user adoption, healthy community cooperation, and long-term sustainability, along the free as in free speech source code.

Key ingredients of successful open source projects

First, I’d say that is the license. The license dictates how the source code and its derivatives (binaries, services) can be distributed or not. It is the single non-negotiable yay or nay factor for many users. It is what qualifies a project as open source or not. Unfortunately, the license alone cannot guarantee that a project will deliver the full potential of open source project benefits.

Second, I’d say project governance. The governance model sets the rules for making important project decisions and dictates how the “owners” of the project interact with the community. There are examples where the governance is managed through a trusted software foundation, that offers neutrality, stability, and transparency, but at the same time, it can cause a lack of flexibility and lead to community stagnation. There are also examples of projects governed by a single company, which can lead to changes to the project license and even transition to proprietary software models. 

As a user of an open source project, I want it to be open source so I can exercise my freedoms. At the same time, I want it to be widely adopted so I can find questions and answers, blog posts and best practices, developers, and support providers, even consume the software as a service. An open source project, w/o community, is a marketing tool in disguise. An open source project, that hasn’t reached the critical community mass, doesn’t deliver full value. Today, the value of open source is in the community, as much as in the source code. And a project’s license and governance directly impact its community health.

And the third aspect of an open source project is the financial model for long term sustainability. An open source project w/o continuous financial incentives for its supporters can become unmaintained overnight. An unmaintained project is a full of security vulnerabilities project. An open source project with security vulnerabilities is a dead project. A dead open source project is… nobody gives a damn about the freedoms of a dead project. 

We have seen many times how open source projects w/o predictable financial stability are left unmaintained, or get forced to change their license and become proprietary. Sometimes, such projects are run by a single company. An open source project in the hands of a single company does not deliver open collaboration benefits. It becomes a company project aligned with the company strategy, roadmaps, and tied to the company's financial health. That is not a bad thing, but it is not a true open source thing either. 

The long term financial health of project maintainers is very often the missing link between the source code and its community. The funding model of a project, or the lack of one, can influence the governance, the license choice, and even break a community. 

Key health indicators of open source projects

This is where a new broader open source vision and infrastructure is needed. When I go to Github, the things I notice about a project are the number of stars and forks. These are easily gameable metrics that are supposed to indicate community engagement. The second thing I notice is the license of the project that tells me what I can do with the source code. Those who are about to invest significant amounts of time, effort, and their professional reputation into an open source project, would also check the governance model. If the project belongs to a foundation, who is sponsoring the foundation. Who is in the project management committee and how are these elected? How to change any existing procedures, project features, and who are the gatekeepers, etc. On some occasions, these rules are written down on a Wiki page, but for smaller projects, they are not written, and the project owners can do anything they wish and do it even without community involvement or transparency. Unless a project is part of a software foundation, there are no open source governance frameworks that represent the best of breed practices. There is no way to apply a governance model to a project by adding a single file (similar to the license file). When there is a governance model, there is no automatic way to guarantee that these governance rules are respected.

The last thing I want to see about a project is its financial health and sustainability metrics. As explained earlier, a financially unhealthy open source project is a promise for unexpected changes and headaches. Today, there is not a single indicator of a project’s financial health status. If a project is part of a software foundation, we can see what benefits the project is getting from such membership, but usually, these are for sustaining the foundation rather than projects. If a project is run by a single company, there is no way to know the contribution of the project to the company finances. If the project maintainers are using Github Sponsors, we can see the current sponsors, or we can check Patreon for donations, or search tens of other places for similar indicators. None of these open source funding platforms is feature-complete, or popular enough with open source supporters to ensure the sustainability of the backed projects. Today, there aren’t any widely adopted long term financial commitment platforms for open source users. There aren’t any trusted financial health indicators for open source projects either.

The missing infrastructure for open source

Imagine a future world where open source is more than a development methodology or marketing opportunity. Instead, it is an open technological equilibrium where intellectual and financial values are exchanged. In such an open source dominated future, I want to be able to do:

1. Start an open source project by choosing a license, a governance model, a funding model, click the “Create” button, and get all the required infrastructure in one place in an open and trustless manner.

2. I want the governance model I pick to be based on existing best practices, be known by its name and offer certain assurances to the community (like the licenses).

3. I want the governance model to be executable, enforced, and audited automatically (through open source technology such as smart contracts).

4. I want to see not only the number of commits to a project but also metrics about accumulated (financial) funds, and future monetary commitments.

5. I want to see not only the git URL for cloning the source code of a project but also the smart contract address to validate the existence of its funds.

6. I want to see not only the release plan and roadmaps but also the release schedule of the funds and how they are intended to be used.

7. I want to see not only the breakdown of programming languages but also the breakdown of money allocation.

8. I want to see not only software foundations focused on the technological superiority of open source projects but foundations responsible for the financial success of open source.

9. I want to see new financial software foundations that are focused on educating, growing, sustaining, monetizing, and funding aspects of open source projects.

10. I want to see these foundations competing with each other to onboard new successful open source projects. I want to see foundations getting financial support from successful projects, not the other way around.

11. I want to see project supporters financially incentivised for taking the risk of supporting a project early and helping bootstrap it.

12. I want to see projects graduating from incubation, not only when they have enough contributors, but also when there are enough funds to become sustainable for a few months or years.

13. I want to see not only metrics for community activity but also metrics for financial activity, indicating underfunded projects that can motivate users to raise funds and prevent maintainers from moving to other projects.

14. I want to see developers joining a project community not only because of interesting technology but also because a project has a generous funding model. 

15. I want to see companies make a goal and outcome-driven fund allocations into specific open source projects, rather than sponsoring foundations for marketing purposes only.

16. I want to see not only occasional donations but also funds time-locked up for targeted project needs such as documentation, testing, training, community growth.

17. I want to see companies not only adding their names to the project users list but find their names in the supporting financial transactions lists.

18. I want to see not only employee retention programs but also companies investing in open source retention programs.

19. I want to see the reputation of different community members based on the work they have done for a project.

20. I want to see an automatic measurement of merit and distributions of funds and governance power based on it.

21. I want to see governance rules in control of project funds and have them executed only by people with proven merit.

22. I want to see companies being able to support open source projects safely and transparently, and that to be part of the project metrics, so I can make more informed decisions when I’m deciding to join an open source project or not.

Imagine you look at a software project, and you can see it has an open source license, transparent governance model, AND financial backing. This is the open source project with the fundamentals to deliver sustainable freedom for a long period. Some of this future vision is aspirational and some is explored and applied by blockchain projects. 

For example, SourceCred is a platform for communities to measure and reward value creation. It is a transparent and open way of tracking merit based on work performed in open communities. 

Dev Protocol is another one that allows OSS creators to tokenize their projects and distribute the incentives to the token holders. It also offers a unique funding model through staking where both maintainers and supporters earn yield.

Gitcoin is the leader in bounty offerings for the blockchain space. More interestingly, Gitcoin also offers gamified ways to learn and earn rewards, grants that are backed by the Quadratic Funding method that increase donations, etc. If you are interested in what's next for open source, go and check these projects and keep an eye on my twitter feed as I cover these projects next time.

Conclusion

I know the term open source was never meant to include governance, community, and financing aspects of the software. But today, these are key characteristics of open source projects that can indirectly limit user freedoms and benefits in the long term. A fully open source project requires a more holistic perspective. It is more than source code in the open. It is more than an open development methodology. It is more than a consumer marketing opportunity. It is more than a roadmap for more sales. It is all of these forces managed all in the open. At that point, perhaps it is not open source only any longer. It becomes a decentralized open source software (DOSS) with open governance and open funding.

Welcome to Open Source Monetization Newsletter by Bilgin Ibryam. This newsletter contains curated content, resources, tools, and other findings around open source monetization.

Expect quick informal updates that are longer than a tweet but shorter than a blog post. Occasionally I also blog my thoughts around open source funding inspired by the new platforms I investigate, and trends I observe while building my side project https://oss.fund. Sign up now so you don’t miss any update.

Subscribe now

In the meantime, tell your friends!