The Challenge of Open Source
I have long been an advocate of Free / Libre Open Source Software (FLOSS)—some would say "zealot" is a better term. However, when trying to build a business around open source, as either an entrepreneur or as a consultant, I was not successful. Five years ago I joined Alfresco. My dream was to be part of growing a sustainable business around an open source project, and I have enjoyed the journey. This adventure has forced me to develop more nuance in my thinking about business models and open source communities.
I have had to struggle with three challenging questions:
- How do we develop a business model that meets our growth ambitions (as shared with our investors)?
- How do we help customers, partners, team members, and investors understand the benefits of open source?
- How do we attract and accept high quality contributions from our open source community.
My most useful insight was the realization that these three challenges are interconnected in important ways.
What Motivates Open Source Adoption
Simon Phipps recently wrote about "7 Questions to Ask Any Open Source Project". He cautions about communities that provide special benefits to a subset of members, because such benefits discourage collaboration. I agree with that advice, as reduced collaboration leads to reduced benefit from the open source solution. However, in our exchange on Twitter, I pointed out that many parts of the open source ecosystem are poorly served due to a lack of investment. There is a trade-off between a willingness to invest and an opportunity to reap benefits, which in turn impacts the willingness of others to participate in the community. This results in a spectrum of projects from those that are very decentralized in terms of investment, to those that are strongly controlled by a single corporate entity; and there are lots of examples in between.
Some FLOSS advocates only acknowledge the value of the most open communities, but I think any community that produces FLOSS code makes an important contribution. The less open projects only exist where a more open project either was never created or was unable to compete. Failure to compete is a signal provided by market participants that they don't recognize the value of a product. These markets require that participants be educated about the value of openness, which requires investment, which requires altruism or an expectation of a return on that investment. We need to design our communities to be robust in the face of limited altruism, and this may require a model that falls short of complete collaboration.
The key to participating effectively is to understand the communities in which you participate, and the motivations of the other participants. This allows you to contribute with realistic expectations. We all need to be selective about the communities we participate in, so we should focus on the communities that best align with our values and goals.
I personally am motivated by the ethical aspect of Free Software. Software that respects the freedom of the user has important benefits for our democracy and our culture. It fosters innovation and helps to reduce the divide between digital haves and have-nots. But ethical goodness is not sufficient to lead people to create open solutions on a grand scale. Developers have to eat, and the laborer is worthy of his (or her) hire. Every long term project needs a business model to sustain it. In the effort to produce as much open code as possible, it is useful to explore the various ways to incentivize that production.
In an ideally regulated competitive market, the solutions that provide the most economic value to all market participants will dominate. It has been exciting to see open source solutions gradually erode at proprietary business models over the last thirty years. Non-technical people increasingly recognize the benefits of open solutions, and even organizations with a short-term focus have an open source procurement preference. However, open source currently only dominates in specific areas: plumbing, platforms, and developer focused tools. It is standard practice to assemble a custom solution using open components, but open source applications targeted at non-developers are much rarer and generally not as competitive against proprietary rivals. This is especially true for specialty software that is only applicable to a small set of users.
My unfortunate experience is that the further you get from developers as your user base, the more likely it is that the users will not understand technology sufficient to value its openness. Most technology users are not able or willing to contribute back to the technologies they leverage. Open source freedoms provide tangible value, but most people are not educated about that value. The common perception is that increased control is only required in the event that the relationship with a technology vendor breaks down, and people are naturally optimistic when beginning a relationship. Much of the value of openness is only visible when there is a robust technology ecosystem leveraging it, and many of these benefits can be duplicated by a proprietary vendor. Impacts on our culture and democracy are external to the software purchasing decision.
For many applications, the market is not yet favoring open solutions, and this is due to the nature of collaborative development. Open source drives investment value from markets by commoditizing the intellectual property. This lack of return on investment value makes it difficult to fund risky research. Further, collaborative development often results in a lack of unifying vision and polish, which most users prioritize higher than openness.
For many applications, such as developer tools, open source development is proven to be a superior engineering model. These applications are quickly adopted on their merits beside openness. But where community participation is likely to be limited, the drive to openness is significantly slower due to the limitations on investment.
Advocates like Simon Phipps provide an important service in educating technology users about the value of openness. But in many cases you will be unable to find an open source software project which both fulfills your need and meets all of Simon Phipps' recommendations. Unless you have the resources to drive your own solution, you can derive a lot of benefit by engaging in the community you find so long as you have a clear understanding of the goals of the various participants.
Selecting a Model
One of the big challenges of launching an open source project is figuring out a funding model. Your funding model will impact the types of community contributions you will receive, which directly impacts the value people perceive in your product. If you try to harvest too much of the value, no one will participate with you. If you don't harvest enough, you will need to find another job. If your goal is to provide a comfortable lifestyle for your team, then you will have the most flexibility if you avoid outside investment. But the lack of outside investment will limit your ability to compete against entrenched proprietary players. Accepting additional investment will come with an expectation of a return, which drives the cycle towards proprietary models. Every product, community, and participant will draw these lines differently based on their goals and values.
Let us look at a few representative business models (with example organizations), and see how their characteristics impact collaboration, value to users, and return on investment. Many companies have projects that employ different business models, or combine aspects of different models into a single project. But these platonic types help illustrate the dynamic relationship.
Strictly Proprietary (Apple): By keeping all intellectual property proprietary, this business model has the highest potential pay-off for investors. But it also presents the biggest obstacles to collaboration which causes developers to miss out on the assistance of interested users. Due to the strict control, proprietary applications can narrowly focus on the needs of the target users and must provide real value to achieve long term market penetration. But if the application is such that many people want to collaborate on a solution, the corporation will struggle to invest more than the community around open competitors. Proprietary models appear to dominate niche markets where there is inherently less collaboration. A proprietary business may be a consumer of open source software, and even participate in upstream communities, but their customers do not receive the benefits of openness.
Open Meritocracy (Apache Foundation): By keeping all intellectual property open, and adopting a meritocratic governance model, many communities produce applications that provide significant value. These projects are most successful in domains that emphasize control or customization, and therefore assign a high value to openness. This model is often seen for use cases that appeal to largely technical communities because there is a higher percentage of participation. End user applications developed with this model often struggle with polishing tasks such as testing, documentation, consistent user interaction, and upgrades. This lack of polish allows proprietary rivals to capture the broad portion of the market that does not value openness. Though community participants might have businesses that depend on the open ecosystem, the ones that scale do so by controlling something outside of the open ecosystem that they can sell.
Open IP, Tiered Participation (Red Hat): Some communities release all of their intellectual property, but tightly control participation and governance in order to focus on unity of vision and dedication to polish. This reduces community contributions, but by controlling the project roadmap, they control the future of the application and limit their support burden. In order to have the necessary resources to provide this polish, they need a business model outside of the freely available product. Support is often cited as a viable business model, but it is easy for companies who don't pay the development expense to undercut the principle developers. Hosted services appear to be a more defensible business, but can often lead to atrophy in the stand-alone product (see the section on SaaS below). Red Hat might have the scale necessary to bring a model committed to open intellectual property into niche markets, but in general this approach requires a project to be broadly applicable so that the project sponsor can receive significant contributions (considering the disincentives) and derive profits even with the small margins forced by market free-loaders.
Open Core (Alfresco): Open core is a proven open source business model whereby a company provides proprietary services on top of an open application or platform. Customers are willing to pay because they can easily quantify the value of the proprietary add-ons that they get in return for payment. This is attractive to investors and entrepreneurs because it lowers business risk and provides higher returns over shorter periods. But it erodes much of the value of open source for the end user, and reduces community contributions. Companies must be very clear and deliberate about what will be proprietary and what will be open, or mismatched expectations will result in a disaffected community—or worse, an open source community in competition with the corporate sponsor of the project. Alfresco has generally followed this model, and I believe we are improving at striking the balance between providing value to our community and building a scalable business. In addition, this model has allowed us to innovate with open source products where there would be no open source solution if we did not have the resources to invest.
Source Eventually (LibreOffice): Many examples of end-user focused open source applications are the result of a proprietary company opening an application after having first tried to extract economic value from the intellectual property. By representing a significant initial investment, the application serves as a rallying point for a broad set of contributions. However, this approach will not accelerate the proprietary phase of the products development or affect procurement decisions if there is not a verifiable commitment by the controlling party to open the code at a specific point in the future. Vague promises will not change the behavior of rational community members.
Software-as-a-Service (WordPress): Though an attribute that can be combined with any of the previous models, SaaS deserves some special consideration. Many wonder what the value is of software freedom in a cloud world. Richard Stallman makes an important point about the impact SaaS has on freedom. Though many cloud companies love to benefit from open source tools, they frequently don't provide any of the benefits of openness to their customers. Even so, SaaS is not inherently equivalent to proprietary software in taking rights away from users. Being able to outsource technology to a trusted third party provides important benefits in quality and low cost. As an analogy, I prefer to outsource my physical security to local government and professionals, but I safeguard my ability to take back control should I need to. Some SaaS services allow users to receive the benefits of professional experts, while retaining control over their future by being able to export their data and self host it in the open source platform. I hope that legal frameworks strengthen user control over data in order to provide incentive for vendors to respect these options.
With the spread of social entrepreneurship and the advent of Public Benefit Corporations, I expect the future to bring even more innovation and diversity in business models around open source projects. The trend is for the most open solutions to win over very long periods of time. I'm excited to be at Alfresco where I can not only displace proprietary rivals by increasing the usage of our open source product, but also influence the models we select for our future products.
I appreciate your feedback on the ideas in this post. If a blog comment isn't adequate, please send me an email.
Photo credit: Jeff Attaway