At The California Open Source Company, we're driven by the clear mission of fixing broken economic incentives in the open source ecosystem. What we've identified is a niche of projects that are critical to enterprises but have been neglected by the existing support structures. This is primarily due to the relatively small size of their target domains and their highly specialized nature, which causes them to become more susceptible to economic strains. We see enterprises relying on these projects while expecting a level of support they can't get unless economic incentives are brought back into alignment.

Economy of Open Source

The open source ecosystem operates within an economic framework where contributions are driven by distinct motivations, particularly for small-scale projects. These motivations reveal why many projects struggle financially, as they often lack sustainable incentives for maintainers. Below are the five primary categories that we identified that encapsulate the economic dynamics of open source contributions. These categories highlight the systemic challenges facing small projects and the precarious nature of relying on altruistic or unsupported efforts:

  • Early-Stage and Purely Altruistic Projects: These are projects typically in their infancy or driven by altruistic intent. Developers contribute without expecting financial rewards, motivated by passion, learning, or community goodwill. Common among new or niche efforts, these projects are financially precarious. Without transitioning to a model with economic incentives such as the ones presented below, they risk abandonment as maintainers' priorities shift or financial pressures mount.
  • Resume Boosting: Individuals often contribute to open source to enhance their professional profiles, showcasing skills and building a portfolio for future job opportunities. These are often non-critical projects from their employer where the company may gain incidental visibility, but the primary benefit accrues to the contributor. These projects often lack long-term maintenance, as motivation wanes once personal goals are met, leaving the software vulnerable to abandonment.
  • Direct Benefit: Organizations will support open source projects because they directly or indirectly support their revenue streams, often by aiding a separate product line or facilitating customer adoption of their sales leader. Because of this, the project's evolution is tied to the company's strategic goals, prioritizing features that benefit their use case, which might not necessarily align with the wider community needs. (E.g. BlueZ by Intel, TensorFlow by Google)
  • Standardization: Another reason why organizations foster open source projects is to establish industry standards. By promoting widespread adoption of certain tools, they create ecosystems where developers are trained in their preferred technologies, reducing recruitment and onboarding costs. These efforts also foster external innovation the company can leverage, shaping the industry landscape to their advantage. (E.g. React or PyTorch by Meta)
  • Too Big to Fail: Some open source projects become so integral to multiple stakeholders that their failure would cause significant industry disruption. Contrary to the case where a single company takes over, in this category organizations will contribute resources to a foundation who will then manage the allocation of resources accordingly. (E.g. Linux, Node.js, OpenSSL)

These categories reveal why niche projects struggle to secure funding, and why they need a different kind of support. They are too small for a single company to take over the financial responsibilities and too niche to be of any interest to a foundation. Meanwhile, 91% of commercial codebases contain open source components that are years out of date or no longer actively developed, while enterprises demand ever increasing reliability from them.

Letting the Market Decide

The approach we decided to take is to let market forces speak for themselves. Enterprises use these niche projects heavily and derive real economic value from them, so they should invest in them in proportion to that value. Donations and sponsorships can't do that job because they rely on generosity, and generosity comes with no obligations attached. A company can't hold a sponsorship accountable when a release breaks its product.

What these projects need is someone accountable for each of them: a team that maintains the code, answers when something breaks, and keeps the project healthy for the long haul, funded by the companies that depend on it. When several companies rely on the same project, they share that cost, and each pays a fraction of what maintaining it alone would cost.

That's the role we've taken on, starting with SimpleBLE.