[Business Guide] Add a chapter about mechanics of open source in business #688
Conversation
Signed-off-by: Cornelius Schumacher <[email protected]>
|
|
||
| ## Drivers | ||
|
|
||
| This section describes how open source can function as a driver of a business models. They are elements. Real-world business models will often use a combination of these drivers or vary how they are used. |
There was a problem hiding this comment.
"of a business models" -> "of business models"
"They are elements. Real-world business models" -> Would simply remove the half sentence for "They are elements"
|
|
||
| Wide adoption opens business opportunities because there is a user base which cares about the software, and it has already proven its relevance and value. | ||
|
|
||
| **In short, adoption creates the market on which businesses can build.** |
There was a problem hiding this comment.
Would emphasize two more aspect for wide adoption:
- Network effect where happy users become promoters, even other domains or markets, that are not addressed by the original go-to-market strategy.
- Easy to integrate for users compared to other licensing models where engineers need to involved other department like procurement, legal, management before having access to the technology.
|
|
||
| ### Shaping a project through contributions | ||
|
|
||
| Most open source projects welcome contributions with open arms. This gives everyone the opportunity to take a part in shaping the project by putting in work, by contributing. This way a project can be adapted to serve the business interests of particular users, especially when these needs are also appealing to others. |
There was a problem hiding this comment.
I would remove the ",by contributing" to improve the reading flow. At least to me, it becomes clear that we talk about contributions due to the previous sentence.
| Most open source projects welcome contributions with open arms. This gives everyone the opportunity to take a part in shaping the project by putting in work, by contributing. This way a project can be adapted to serve the business interests of particular users, especially when these needs are also appealing to others. | ||
|
|
||
| Even when the original authors are reluctant to contributions, open source licenses always allow to fork the project as a last resort. Then you can develop it independently of the original authors yourself. While this is not a desirable situation it gives a guarantee that changes can not be completely blocked. It also gives the original project an incentive to look for ways how to accommodate contributions. | ||
|
|
There was a problem hiding this comment.
How about the aspect that spending 20% effort on adapting an existing solution to your use case might be better compared to building 100% of your own solution.
Another viewing angel from a product manager perspective is that Open Source allow the customer to directly implement and add their requirements to the solutions. If done and managed well this avoids over-specialization of the technology and allows to keep using the technology in different contexts.
|
|
||
| Open source licenses grant free use of the software at zero costs. This is part of the definition of open source. This lowers expenses wherever licensing fees would otherwise add up. It is particularly relevant in models that scale, such as running large numbers of instances where usage-based pricing could otherwise become prohibitive. | ||
|
|
||
| Zero license costs also reduce the costs of a software stack on used as the base for building further solutions. The value creation shifts upward, while the base layers become a commodity. In these commodity cases, open source often evolves as the predominant solution because it provides the most cost-effective model, especially in highly collaborative development situations. |
There was a problem hiding this comment.
"software stack on used as the" > remove the "on"
| Open source licenses grant free use of the software at zero costs. This is part of the definition of open source. This lowers expenses wherever licensing fees would otherwise add up. It is particularly relevant in models that scale, such as running large numbers of instances where usage-based pricing could otherwise become prohibitive. | ||
|
|
||
| Zero license costs also reduce the costs of a software stack on used as the base for building further solutions. The value creation shifts upward, while the base layers become a commodity. In these commodity cases, open source often evolves as the predominant solution because it provides the most cost-effective model, especially in highly collaborative development situations. | ||
|
|
There was a problem hiding this comment.
To me it seems the Zero license cost and Wide Adoption are connected. So far it seems to make sense to keep them separate but maybe we add a sentence how these drivers differ from each other.
For instance, the wide adoption adds to a standardization effect which is not emphasized too much in the zero license cost. WDYT?
There was a problem hiding this comment.
I see it as two sides of the same thing. Wide adoption is the outgoing effect, this is the perspective from the open source project point of view. There the number of adopters is the interesting number. Zero licensing costs is the perspective from the individual user, there the licensing costs are the interesting number.
These two things are related. That's probably also the case for some of the other drivers. Maybe we could try to make a graph of how they influence each other or something like that?
| Open source provides full transparency to a piece of software, because the source code is available to all users and in almost all cases to the general public as well. This is the prerequisite to be able to analyze how the software works and perform an independent assessment of quality of the code, security, and other aspects. | ||
|
|
||
| Transparency is crucial in situations where trust in a vendor's statements is not enough. It for example gives everyone the ability to make sure their requirements are met, or it can be used to lay open used algorithms for the scrutiny of a community to ensure fairness and correctness. | ||
|
|
There was a problem hiding this comment.
Would explicitly mention security when it comes to trust, e.g. encryption. Only if the implementation is open we can verify that the component actually does what it is supposed to do and do not rely on "security by obscurity".
|
|
||
| ### Volunteers | ||
|
|
||
| A lot of open source software is developed by volunteers. They do that to scratch an own itch, to learn, or to build up personal reputation. Motivations vary, and open source provides an environment to follow them while also offering the opportunity to make a big impact. This can be such a strong motivating factor that it brings together teams of developers which would not be possible to bring together by commercial means. |
There was a problem hiding this comment.
Just an idea, does it makes sense to you here to differentiate between intrinsic and extrinsic motivated developers? One might be able to make the case that volunteers are way more intrinsically motivated to create a good solution compared to developers that are mostly extrinsically motivated through money and their work contract. But maybe this is going the wrong direction.
There was a problem hiding this comment.
It's an interesting aspect. I do think there is a difference between volunteers which are doing it on their own time and volunteers which are on a payroll. Being on a payroll is probably often not really volunteering, but there are many people who are and do have freedom to decide at least to some degree what they do in terms of open source. Needs a bit more thought, I think.
|
|
||
| Contributing voluntarily also gives a lot of freedom to follow your own interests and work in your own pace, because it doesn't come with the obligations of a paid assignment. This can open the room for experiments which would not be commercially viable. | ||
|
|
||
| Many volunteers will even contribute to projects which serve as the base of a business of somebody else. They do so if they have the feeling that they get something in return, for example that the software they contribute to is well maintained and their efforts are multiplied. |
There was a problem hiding this comment.
, or that they solve their own problems by adding value
|
|
||
| Volunteer contributions can be a delicate element of a business model. Volunteers owe nothing to a business exploiting their volunteer work, and unfair treatment of volunteers might not only harm a community but also seriously affect the reputation of a business. If done right, they can be a powerful multiplier of good will and a source of valuable contributions. | ||
|
|
||
| While volunteers are the backbone of many open source projects, it's important to acknowledge the challenges of sustaining engagement. This can be especially taxing when a project is in high use with corresponding load and demands towards maintainers from commercial entities without compensating them adequately. |
There was a problem hiding this comment.
Or when commercial entities try to outsource their requirements to volunteer contributors without providing the necessary assistance.
E.g., there have maintainers that close their projects or get frustrated when they get asked by downstream users to adapt their security protocols to fit into the processes of the companies.
|
|
||
| ### Support and maintenance | ||
|
|
||
| Selling commercial support and maintenance for open source projects. This includes guarantees for security updates and other services required for business to operate open source within an environment with service levels and similar requirements. |
There was a problem hiding this comment.
"and other service" -> "and other services like a support hotline"
| Drivers: | ||
|
|
||
| * Model directly scales with *adoption*. The more adoption, the more need for support and maintenance of these projects. | ||
| * Model relies on *contributions*, so that fixes can be made on the timeline of the required support. To keep this economical they need to go back to the projects. |
There was a problem hiding this comment.
To be honest, I do not fully get this point. Maybe there is a way to re-formulate that sentence.
Because, do I really need external contributions to provide support for the software? It might make providing support even more difficult if one has not fully written the software.
But I agree that having external contribution is
a) a good way to extend the capabilities of the supported software
b) allows customers of the support contract to shape the software according to their internal needs while still being able to get the guarantees through the support contract.
There was a problem hiding this comment.
The point I was trying to make is that if you have to maintain a fork to be able to provide support for a piece of open source software this will quickly get expensive and very hard to handle, if you don't contribute the changes back to the upstream project.
|
|
||
| * Model directly scales with *adoption*. The more adoption, the more need for support and maintenance of these projects. | ||
| * Model relies on *contributions*, so that fixes can be made on the timeline of the required support. To keep this economical they need to go back to the projects. | ||
| * *Zero license costs* are a factor because range of support only depends on own ability to deliver not on the accessibility of the software supported. Scales well to large number of support offerings. |
There was a problem hiding this comment.
This opens the market for other competitors to provide support (at least in theory) which makes it more attractive for customers compared to offerings where they are bound to a single vendor when choosing a specific solution and technology.
| Drivers: | ||
|
|
||
| * Income directly scales with *adoption* | ||
|
|
There was a problem hiding this comment.
Do we have a good example for this model?
Like well maintained images in the marketplaces of the hyperscalers?
|
|
||
| ### Professional services, custom development | ||
|
|
||
| Adapt and extend open source software to meet specific requirements. |
There was a problem hiding this comment.
how about
"to meet specific requirements" > "to me specific individual requirements"
|
|
||
| Drivers: | ||
|
|
||
| * Key factor is *contributions* which allows to offer custom development for all open software. Model depends on expertise, not on availability of underlying software. To keep it economical contributions need to get back into the projects. |
There was a problem hiding this comment.
is contribution really a driver here? I mean one could offer the same for proprietary software and prioritizing specific feature requests. The driver here to me seems more the adoption. Maybe we find a way to reformulate this aspect. Because I get the idea that the software becomes attractive through other contributions which increases the likelihood of a customer to be willing to extend the software for their particular need as well.
There was a problem hiding this comment.
It's hard for a company to build a business of doing custom development for proprietary software, because the source code usually is not available and contributing to the vendor's code base usually is not feasible. To stay competitive (i.e. reduce organizational and operational overhead) contributing upstream does seem to be a driver if you offer custom development and support, doesn't it?
|
|
||
| ### Hosting, Software as a Service | ||
|
|
||
| Running software as a service is associated with constant work and attention and incurs running costs. It requires expertise with the software as well as with hosting software. Many people and organizations don't have the time or expertise or are willing to manage the risks associated with this. Providing this as a service for a subscription fee is a valid and popular business. |
There was a problem hiding this comment.
"It requires expertise with the specific software as well as with hosting software in general"
There was a problem hiding this comment.
"and popular business" > "and popular business that often scales better if one entity handles the hosting for multiple customer instead of each customer building up the environment and knowledge to run it by themselves"
| * Wordpress | ||
| * Aiven offering managed data services | ||
| * Instructure with Canvas | ||
| * Cloud providers offering managed open source based services |
There was a problem hiding this comment.
It is interesting that most of these examples except for Wordpress were not the initial contributor to the projects for which they provide SaaS even to me these were the classic providers of such services. Maybe we mention companies like MongoDB, GrafanaLabs too?
| Drivers: | ||
|
|
||
| * *Adoption* defines the size of the market | ||
| * *Zero licensing costs* allows to set up this model for software you didn't develop yourself. |
There was a problem hiding this comment.
Not sure myself, but one could make the case that "Transparency" adds to this. WDYT?
Because if I know what my provider runs it improves trust compared to a completely closed solution. However, there is still the gap that one does not know for sure that the vendor exactly executes the Open Source software itself or just provides a compatible solutions.
One dimension of this transparency is that it enables the customer to move away to another vendor since the offerings should (in theory) be API compatible. But here one could make the argument that this is already part of the zero licensing cost driver.
WDYT?
|
|
||
| Examples: | ||
|
|
||
| * Almost all software developed today. According to studies, 70 % of software are open source components. |
There was a problem hiding this comment.
There are even studies suggesting higher numbers than 70% like Sonatypes "State of the Supply Chain" stating "up to 90%". But this a vendor that who positions their products in this field so you have to take with grain of salt: https://www.sonatype.com/state-of-the-software-supply-chain/introduction?_gl=1*ci5wss*_up*MQ..*_ga*ODM0MTAyNDgxLjE3NjExNDM3ODQ.*_ga_08HT33J01V*czE3NjExNDM3ODMkbzEkZzAkdDE3NjExNDM3ODMkajYwJGwwJGgw*_ga_3W70E95Z6Q*czE3NjExNDM3ODMkbzEkZzAkdDE3NjExNDM3ODMkajYwJGwwJGgw*_ga_2TMM6KZPXQ*czE3NjExNDM3ODMkbzEkZzAkdDE3NjExNDM3ODMkajYwJGwwJGgw
| * Instructure with Canvas | ||
| * Cloud providers offering managed open source based services | ||
|
|
||
| ### Development with a shortcut |
There was a problem hiding this comment.
Not sure whether this qualifies as an individual business model because as mentioned in the text almost all modern software is developed with OSS components.
Maybe we find another naming here to make it more clear that the business model is often not based on the software itself but other business or services from completely other domains that require the software component. In other words, OSS here is used to have non-differentiating functionality and companies contribute in the hope have cost sharing and achieve commoditization.
|
|
||
| Offer the same software under two licenses, an open source version, which can be used for free, but restricts users in non-open scenarios, and a proprietary version, which doesn't have these restrictions, but needs to be paid. | ||
|
|
||
| Usually a strong copyleft version is used in this model. This can be seen as an abuse of the free software idea, because it's not meant to pass on freedoms, but to play into concerns about detrimental effects of strong copyleft to proprietary business. |
There was a problem hiding this comment.
"is used in this model" > "is used as open source license in this model"
There was a problem hiding this comment.
While I do not disagree, a wording like "abuse" to me seems a bit opinionated which I would try to avoid in such a document.
At the same time, one could make the argument that dual licensing at least gives users the option to decide whether they want to support the project by paying or by contributing.
|
|
||
| Usually a strong copyleft version is used in this model. This can be seen as an abuse of the free software idea, because it's not meant to pass on freedoms, but to play into concerns about detrimental effects of strong copyleft to proprietary business. | ||
|
|
||
| This model only works, if the vendor of the commercial version has all rights on the open source code as well. This can be challenging in terms of community engagement. |
There was a problem hiding this comment.
add something like: "because fewer external contributors might be willing to license their content to you under these circumstances."
|
|
||
| ### Level market through standardization | ||
|
|
||
| In a closed market, where dependencies on vendors are strong, and it's hard to switch vendors because of lack of standardization, open source standards and (reference) implementations can create more openness and choice for customers. So establishing an open source solution increases competition and brings down costs. |
There was a problem hiding this comment.
Should we differentiate between situation where the open source solution essentially becomes another "free" vendor forcing competitors to improve their offering and situation where the competition between vendors transforms into a competition who can offer services around the open source solution best making the switch easier? Not sure myself whether this is getting too detailed or not.
|
|
||
| * Qt is one of the original examples of this model | ||
|
|
||
| ### Level market through standardization |
There was a problem hiding this comment.
To me level (or alter) the market through open source solutions, e.g., as a user community against a player that takes advantage of their market position and standardization can be seen as two different models even though they have many connections.
For instance, for standardization the argument might not always be to enable better interchangeability of different vendors but purely efficiency driven or to reduce complexity. One (maybe not the best) example could is the alignment on SBOM formats which makes it easier to handle the SBOM information for all players along the value chain instead of building complicated integrations for each customer/supplier.
|
|
||
| ### Own the platform | ||
|
|
||
| Scalable platforms provide a business model where the platform owner provides a market for providers and users of platform services to engage in business and takes a share of the transactions which are mediated via the platform. The more scalable the platform is, the more important it is to drive down the transactional costs. Open source software is mandatory to keep the costs low. |
There was a problem hiding this comment.
To "Open Source software is mandatory to keep the costs low": While I want to agree, how does this align with the iOS Appstore platform from Apple?
There was a problem hiding this comment.
Ok, just saw the next sentences which explain it a bit, but maybe we can make this business model a bit clearer.
|
|
||
| ### Advertising | ||
|
|
||
| If open source software or platforms are so wide-spread that they become attractive targets for advertising, this can be a source of income, which can sustain a business. |
There was a problem hiding this comment.
Not sure whether advertisement has much of a difference compared to "development with a shortcut" or where to draw the line between the two. Maybe you can extend on this differentiation a bit more?
There was a problem hiding this comment.
In addition, the line between Advertising and Sponsorship can also become blurry, e.g., in cases like Mozilla where money is spent to influence the development of the software . But I understand that the relationship between Google and Mozilla for making the Google search the default setting in Firefox goes beyond the type of sponsorship outlined here. But at the same time, Mozilla does not solely exist to sell adds even it is through Google an indirect source of income.
|
|
||
| ## Shaping open source projects to drive the business | ||
|
|
||
| To use open source effectively as a business driver, the corresponding open source projects need to align with how they are supposed to work as drivers. Projects need certain traits that support this, for example in terms of licensing, governance model, technical architecture, etc. This linkage matters because business models such as support, SaaS, or open core rely on projects being shaped in a way that actually enables the drivers they depend on. |
There was a problem hiding this comment.
One could add "characteristics of the community member" to the list of traits. For instance, for some projects you want more corporate developers using and extending the software for their employer while other models work well with or better with volunteers.
|
|
||
| The Mozilla paper defines a list of benefits of open source, which are then reflected in the archetypes, although there is no clear-cut direct mapping. There will always be a combination of benefits, archetypes, and business drivers. | ||
|
|
||
| The table below links the business drivers introduced above with the archetypes benefits identified by Mozilla and indicates which archetypes are most likely to realize them. This table is some guidance, not a formula. |
There was a problem hiding this comment.
Maybe add something like "Even the original authors of the Mozilla paper emphasize that most projects in practice will display a mix of the theoretically described archetypes."
There was a problem hiding this comment.
I wouldn't call them theoretical archetypes but rather phenomenological ones. AFAIK, the way they were found was by analyzing a wide range of Open Source projects and looking for common traits that would allow to characterize or analyze open source projects. And you're right, in practice you often find a primary archetype with some aspects of others. Obviously this holds true both for existing projects but also when developing an open source strategy and asking what archetype to aim for...
|
|
||
| In the same sense open source software is not a business model either. | ||
|
|
||
| But open source is more than just the artifact of software under an open source license. It's also a development model, an approach for collaboration. It is a culture of how people can interact to produce software effectively and with great fun and purpose |
There was a problem hiding this comment.
Maybe this goes to far or is too idealistic, but we could add the dimension of ettiquette meaning that most open source communities developed a common understanding of process, working and governance models that goes beyond the pure licensing. I am talking about things such as meritocracy, contributor-maintainer model, Pull-Requests for proposing and discussing changes etc.
But I would understand if this is part of development model and culture for you.
3 participants
No description provided.