054.1 Lesson 1
Certificate: |
Open Source Essentials |
---|---|
Version: |
1.0 |
Topic: |
054 Open Source Business Models |
Objective: |
054.1 Software Development Business Models |
Lesson: |
1 of 1 |
Introduction
Companies that distribute proprietary software (also known as closed source software) have a relatively straightforward business model: They either sell the software outright or, more commonly, charge for a license on an ongoing basis in a subscription model.
In contrast, licenses for free and open source software often require that the recipient of a binary version of the program, or the end user of a SaaS offering, is entitled to have access to the source code. While a fee for the delivery of the source code can be charged, such as a DVD sent through postal mail, there can be no charge for the actual source code. Most often, the source code is made available for download over the internet to make the distribution of source code easy on everyone.
Over time, numerous ways have been tried to fund the development of open source software. This lesson looks at why a business would choose one of these models, and the trade-offs in these options.
Goals and Reasons to Release Software or Content Under an Open License
Although opening the source code of an application could make it difficult to derive revenue in the usual manner (i.e. by charging for the use of the software), there are many reasons developers choose to build a business on open source code.
Many open source developers hope to get bug fixes from their customers. Some customers take their contributions to an even higher level by adding new features, porting the software to a new environment, or making other significant improvements. Both bug fixes and higher-level improvements enhance the original software. If customers contribute them back to the original developers, the changes might make the code more desirable to other potential customers and encourage its adoption.
But a company can’t expect contributions and attention just by placing its code on a site such as GitHub, GitLab, or the Free Software Foundation’s Savannah. It’s one thing to encourage developers to join a project, but more challenging to keep them enthusiastic about it — so don’t underestimate the amount of work that community contributions call for. A company needs to put effort into recruiting developers, mentoring them, motivating them, and checking their code for flaws.
Another reason to open the code is to create an industry standard. Sharing code in an open manner could lead to better interoperability and other benefits. The team that developed the code has valuable expertise that might allow them to direct the future of the project and get paid for supporting others who use the code.
Some companies open their code in order to create trust among customers. First of all, customers know they can continue to use and improve the code if the company fails or decides to enter a different market and abandons the code. Second, customers can check the quality and security of the code for themselves or task an independent expert to do an audit, which is usually not possible with closed, proprietary software.
Finally, a company might have adopted a code base that is already open source, planning to build a commercial business on it. The license might be requiring the company to distribute the source code of its changes to any end-user of the program.
In short, some reasons to open a company’s code are:
-
Building on an existing free software project
-
Benefiting from customer innovation and contributions
-
Creating trust among customers
-
Promoting code as an industry standard
Common Business Models and Revenue Streams
The software industry, over the past several decades, has discovered many business models appropriate for proprietary as well as open source businesses. This section focuses on the most popular ones in current use among open source developers.
One model is to charge for support. Customers might have trouble installing and configuring the software, fixing bugs as they are found, adding new features for their exclusive use, and managing their systems. The staff who developed the software are excellent sources of support. In fact, this staff is probably already offering free support on forums where the software is discussed.
Thus, in the support model, a customer pays a vendor to install the open source software on the customer’s hardware (called a self-hosting distribution) or gets access to the software on the vendor’s hardware (a cloud-based model). Support contracts ensure that customers will get timely help from the company for their more complex needs. Companies using this model generally offer retainers, which clients pay for on a regular basis.
Another model -— really a set of overlapping models — is called freemium, a term popularized in 2009 by author and editor Chris Anderson. In this model, customers can use a product at a certain level cost-free, and are encouraged to pay for more features if they find the product useful. You probably know online news sites that offer a certain number of free articles and ask readers to subscribe for full access to their sites; this is a well-known example of a freemium model. Another example is a gaming platform that provides the base game for free, but charges money for specific inventory.
Because access to open source code can’t be shut off like proprietary code, open source companies often use another version of the freemium model known as open core.
In open core, certain basic features (the “core” of the product) are open source, and additional proprietary features can be licensed. Often, the open part is fully functional but works best for researchers or individual users, and becomes hard to manage when many people are sharing it across an enterprise. Therefore, the proprietary features might include convenient web interfaces for administration, tools for accounting and collaboration, and other things of particular interest to large sites.
Often, the open source part of an open core offering is called the Community edition and the proprietary part is called the Enterprise edition. Open core is a popular model for offering open source software with advanced features to enterprise customers. While an open core product may be hosted and charged as a subscription for customers, the Community and Enterprise editions are often used as self-hosting distributions of the software, so that end-users can run the software on their own equipment.
Other proprietary software companies base their freemium model on time: Try out the software free for three months and then pay in order to continue using it.
Companies can also build a web service on top of an open source code base, in the Software as a Service (SaaS) model. The web service can be run just like a service built on proprietary software. Customers pay on a monthly or yearly basis, and the company may show advertising or use the site in other revenue-generating ways.
Many companies who run SaaS web services or offer mobile apps make money through advertising. Some companies also collect date on users through the service or app and sell this data to third parties who can use it for advertising. Advertisements can be seen as annoying, though. Selling data is controversial, and some countries put restrictions on data collection.
Finally, companies might develop and release open source software without trying to derive any revenue from it at all. This model is available to companies who get revenue from things besides the software. For instance, automobile companies collaborate to create large bodies of free software to run in their cars (which nowadays are thoroughly computerized).
Major software companies who derive their revenues from proprietary offerings, such as Google and Amazon.com, sometimes release administrative software or other useful tools as open source, because these tools are not central to their core business. The organizations who release the code under an open license benefit from feedback, bug reports, and feature enhancements provided by the open source community.
Using Open Source Software in Other Technologies and Services
A lot of companies incorporate open source software into their products or web platforms. After all, open source software is free! But that’s not the most important reason (and perhaps not even a good reason) to adopt it. More importantly, a lot of this software is high-quality (although the development team should vet it carefully before adopting it) and may even be an industry standard.
Another advantage of open source software is that it will continue to be available if the developers or the community around it go away.
But free and open source software brings responsibilities. This section will quickly list the main issues to consider before adopting it.
The first issue applies to any third-party software or tool under consideration for adoption: Will it meet the users' needs now and as the company evolves? Is the software supported by a strong community that can offer technical support and continue to develop the software? Does the software suffer from significant security vulnerabilities?
Next, managers must consider the company’s responsibilities if it incorporates an open source project into its own software. If developers build new code around the open source code, they should check what they are required to do by the license from the open source software. Some licenses require developers to distribute the source code of their own changes to their end-users under the same free license as the original code base.
Even if a developer isn’t required to distribute their modified source code and is creating a proprietary product on top of the open source code, the developer might want to contribute certain things back, such as bug fixes and enhancements to the open source code. By contributing these fixes and enhancements, the contributing developer allows the project to incorporate them (if the core developers choose to do so) and maintain them. Developers who don’t contribute enhancements back might have to re-apply the fixes and enhancements every time they upgrade to a new version of the original code.
Because of this dependency, and for other reasons, company staff should consider becoming active members of the community that develops the code. Developers can learn a lot about the code by participating, and can help set the direction for future development. Of course, the organization should pay for the time developers spend in community activities. For a company that is serious about using free software, it is not cost-free.
Considerations of Open Source Software From a Customer’s Perspective
Opening code is very beneficial to customers for several reasons, but implies a different relationship between the company and its customers. The customers should understand the benefits as well as the implications of the relationship.
The main benefit to the customer, mentioned earlier in this lesson, is that they can have more trust in the software. They know that it won’t go away. Many proprietary companies shut down or take off suddenly in a new direction, abandoning customers with perhaps only a short time to migrate to a product the customers might not like. Open source software, in contrast, doesn’t depend on any single organization. If the project matters, other people in the community will continue the project when the original developers move away.
Customers can also check the quality and security of open source software. They can determine how easily they can add features of their own or port it to a new environment.
Because the source code in an open source project is open for all to examine, a wide range of developers can familiarize themselves with it. On a project that has an active community, many people provide support on the forum. Often, it’s easy to hire people to support the software or to administer and use it within the company, because the new employees already know the code.
It’s very reassuring to customers, who depend on code for day-to-day functioning, to know that they can fix a bug themselves or hire someone to do so. An obscure bug that affects only a few customers might take years to be fixed by the core development team, a constant frustration to users of proprietary software. In addition, when the source code is available, a bug and its suggested fix might be identified more quickly.
What about the relationship between the company and the customer? The company can choose to set up a relationship exactly like one offered by a typical proprietary software company, providing the customer with regular updates and a support contract. The customer never needs to look at the source code or join the community forums.
But most customers would benefit from the unique opportunities offered by open source projects. They can allow their own developers to contribute both information and code. Such participation deepens their staff’s understanding, helps them recruit new staff, and gives them a voice in future development.
Cost Structures and Investments
Programmers are in high demand, so any software effort is going to be expensive. People who know major open source projects are even more in demand, because those code bases are used so widely.
An open source project offers potential cost savings because different organizations and individuals can combine their efforts in a common code base. But running such a project introduces new costs.
If a company opens a project that was developed in-house, the company needs to invest in making it serve a larger (possibly worldwide) community. Some functions that met the company’s narrow business needs might need to be rethought so they serve other businesses as well.
If the code is poor or awkward, a company probably shouldn’t open it. Potential contributors as well as potential customers will be repelled by the quality. It behooves developers to fix these problems anyway, because poorly coded software is brittle: It is hard to update with new features and tends to develop complex bugs that are hard to fix. These problems are called technical debt, and the sooner they are fixed, the better it is for all users.
Finally, it’s surprising how often a company has embedded trade secrets, passwords, personal references to individuals, or other sensitive information in code. Developers have to invest time in stripping out such vulnerabilities. Passwords, API keys, certificates, and cloud access credentials should never be in code anyway; they should be managed externally through a secure service.
Let’s say that a company has opened its code, and is hoping to benefit from outside contributions. Some customers will pay developers for maintenance and new features. Others will put their own developers on the project, but the core development team has to allocate time to support them. The core development team needs to educate outsiders about the code and the associated coding standards. This team should also guide outside contributors about what to add and where to send back comments on their code.
Keep an eye out for outsiders who show talent. These individuals could be valuable recruits to the core team. They might like to join the team, and they come with considerable knowledge.
When one team of developers is paid, while other people are volunteering their time, the volunteers might feel exploited or ask why they should help. Each contributor, whether an individual volunteer or an organization, has to undergo the types of thinking described earlier in this chapter to decide why they are contributing.
Free code is not cost-free, even if entails no licensing costs. It is simply a different model for development.
Guided Exercises
-
How does open source code improve customer trust in the software?
-
Why is open core a popular freemium model for open source software?
-
What is self-hosted distribution?
-
What are typical types of help that developers give to outside contributors to their open source projects?
Explorational Exercises
-
You are considering basing a proprietary product on an open source project. What factors would you consider in order to make the decision?
-
You have built several products, for which you charge a subscription, on top of an open source project. What will you do if the open source license requires you to contribute all your code back to the project? Also, you added support for some new communication protocols to the open source project to support your proprietary needs. If you have a choice, will you ask the open source project to integrate this protocol support into their core code?
Summary
In this lesson, you learned the value of opening source code. You reviewed the common business models in use today, and the importance of understanding the impact of the code’s license. You read about issues to consider when incorporating open source code into your enterprise, and how open source benefits your customers. You also learned how costs of open source development differ from those of proprietary software.
Answers to Guided Exercises
-
How does open source code improve customer trust in the software?
Customers can check the quality and security of the code. They can also trust that they can continue using the code if the original developers stop supporting it.
-
Why is open core a popular freemium model for open source software?
It is hard to require payment for open source software, so companies add proprietary features that they can charge for in an open core model.
-
What is self-hosted distribution?
Self-hosted distribution means a version of software that can be run on a customer’s own equipment.
-
What are typical types of help that developers give to outside contributors to their open source projects?
Developers on a project typically educate and mentor outside contributors, and check that their contributions meet the team’s quality and coding standards.
Answers to Explorational Exercises
-
You are considering basing a proprietary product on an open source project. What factors would you consider in order to make the decision?
First, decide whether the open source software meets your needs. Check its quality, security flaws that have been publicly reported, and the health of the community around it. Check the license carefully to see whether it requires you to share your modifications to the code. Determine how much you want to participate in the open source project’s community and how you’ll define the roles that your developers will play in that community.
-
You have built several products, for which you charge a subscription, on top of an open source project. What will you do if the open source license requires you to contribute all your code back to the project? Also, you added support for some new communication protocols to the open source project to support your proprietary needs. If you have a choice, will you ask the open source project to integrate this protocol support into their core code?
If you do have to share your code, offer a subscription to a self-hosted distribution. Even if you don’t need to share your code, you probably want to ask the project to integrate your support for communication protocols so that you don’t have to re-implement that support each time you install a new release of the open source code.