tl;dr We observe sustained growth in what we call non-software-industry user-led open-source consortia. These are open-source consortia (non-profit organizations) created by companies from outside the software industry with the goal of developing the applications these companies need to run their business. Their behaviors are different from other open-source consortia and we can see this expressed in their governance rules.
To understand this phenomenon, we first need to explain the difference between user-led and vendor-led open-source projects resp. consortia and then how historically software as an application domain played out differently from other domains.
The two use cases
Software has two main use cases. It can be a component in a product, and it can be an application for business (or hobby) tasks.
- As a component to a product, software is a material, i.e. an input to production. Example components are libraries like Apache Commons and frameworks like React or Vue.
- As an application, a software is capital, i.e. a means of production. Applications are used to perform some business task, and examples are gcc, Word, or Blender.
Both components and applications are resources. They can be flexible, so what is a means of production to some, is an input to production to someone else. The Python programming language and libraries are a means of production for data scientists, yet they are an input to production to Python vendors like Anaconda or ActiveState.
Open-source consortia
Software is increasingly being developed as open-source software. A community open-source approach suits everything that is competitively non-differentiating between those who are developing the software, be it applications or components.
We call those who use software as an application to perform a business task users, and those who use software as a component in their products vendors. Consequently, we call a project that is predominantly led by users a user-led project, and a project that is predominantly led by vendors a vendor-led project. Leading does not necessarily mean writing code (you can pay others to do that).
Finally, economically significant open-source software is usually put under the guidance of an open-source foundation or consortium. Thus, we call consortia user-led consortia if it is users leading the development of applications for their business or vendor-led consortia if it is vendors leading the development of components for their products.
| Agent / Role | Use case | Project | Consortium |
|---|---|---|---|
| User | Application | User-led | User-led |
| Vendor | Component | Vendor-led | Vendor-led |
Application domains
Every application has a domain. Applications for the software domain are compilers, editors, version control, etc. Open-source projects for the software domain were among the first open-source projects, when the world was still figuring out how to make open-source collaboration work. As a consequence, these projects were usually unique, experimenting with governance and coming up with different solutions. Common to them, however, is an egalitarian approach with no significant distinction whether the software is to be used as input to (vendor role) or means of (user role) production.
This is notably different for users from outside the software industry. Many years of vendor-lock-in and the resulting price pressure, innovation blockage, and operational risk have led software application users from outside the software industry to increasingly worry about their software fate. One result is the creation of said user-led consortia by non-software-industry companies and institutions (automotive, energy, education, etc.)
A main concern of these user companies is to not end up at the mercy of software vendors again. They clearly want to remain in the driver’s seat. This is expressed in the bylaws of the consortia, often through the introduction of membership levels with different powers, and sometimes through the use of a copyleft license for the software being developed. The specifics depend on the industry and how the used-led consortium wants to structure the ecosystem of vendors and consultants who build on the software of the consortium.
Putting things together
The following figure displays the two use cases of software lined up against the domain of the software. Each cell provides three examples of an open-source software for that use case for that domain.
Open source started out as applications in the software domain. The users were often software developers who needed the applications, i.e. development tools, to go about their business. The same users soon realized in their vendor role that they could also use open source as an approach to collaborate on non-differentiating software components for their products. While there are some notable exceptions (e.g. Blender, 1994), community open source outside the software domain gained traction only during the last twenty years.
In domains that are not the software domain (everyone but the IT industry or about 90% of the world’s GDP), we find both vendor-led and user-led projects. The same company can both be a user and a vendor. Audi, for example, is a user in the user-led consortium openMDM (for the development of measured data management in car production lines), and a vendor in vendor-led consortia like Automotive Grade Linux (mostly the infotainment stack). Audi (Volkswagen) is clear about the purpose of its engagement and acts accordingly: For the development of the openMDM application Audi simply pays consulting firms, while for the development of components that make it into their products, Audi uses its own developers (because it wants the know-how in-house).
For our research, we have sampled the world for user-led consortia; the count is in the three digits: Education, libraries, health, insurance, automotive, logistics, banking, you name it, it is all there already. Welcome to a new world of open source!
Questions and answers
Q: But everyone is a software business they tell me!
A: Well, yeah, no. Software has become both a critical means of production and an input to production for many non-software-industry companies, but for an automotive OEM the product is still a car and its services, for bank the product is still financial in nature, and for a logistics company the product is still the delivery of cargo.
Q: Don’t user companies ever contribute to component development?
A: Of course they do, but only if these components end up in applications they want to use.
Q: I’m a vendor, and I use a component in my products. Why am I not a user?
A: Using an application has a different meaning here than using a component in a product. Feel free to suggest alternative terms to user and vendor!
Q: What is a developer foundation then?
A: I don’t know. How is it defined? A developer can both be a user or a vendor. You might be talking about foundations in which members are capable of programming. While this may be a reasonable definition, it is independent to my point here.
Q: How does a foundation like the Apache Software Foundation (ASF) fit in?
A: The ASF accepts only natural people as members. However, people can act on their own behalf or as agents of companies (this is clearly expressed by requiring both an individual and a corporate contributor agreement to be signed). Arguably, the ASF is a developer foundation then, and home for both user-led and vendor-led projects, except that it does provide little to no room to formally express that distinction. By taking the high road (everyone is equal) and not providing this space for customized governance, the ASF is missing out on this important trend.
Q: I’m still confused.
A: OK, no dinner for me and I will cry myself to sleep. Tomorrow is another day!
Leave a Reply