A business model for sustainable R&D of open source projects.
Research & Develop Open Ventures or RDOV is a business model centered around the open source developer and ensuring economic viability for the project though balanced incentives.
By using an open source license then aggressively establishing an incubator for applications of their project, a developer can lead rather than monopolize the market. This mixture of free and open use of an idea with strategic leverage of the inventor’s position should allow for a more fair and efficient outcome than either the closed or open R&D models in practice today.
Invention In Markets
In a market, being an inventor alone is not enough to pay the bills. An inventor who tucks their idea away in a drawer until death will never see any benefit from it. To create value, the idea must be put to use and ultimately adapted to solve some consumer desire.
There are three generic methods an inventor can monetize, or participate in market use of, their idea.
|Revenue Model||Inventor Role||Description|
|Direct Use||Salesman, Operator||Sell copies of the invention or use the invention as capital to produce some other marketable good or service.|
|Indirect Services||Mentor, maintainer, support provider||Provide services related to the invention.|
|Royalties||IP owner||The inventor receives a government enforced monopoly on the invention, and taxes its use through royalties.|
Of these, the most common in today’s developed markets is certainly royalties or Intellectual Property. Often used in tandem with the others, the primary drive for use of this method is that once a legal monopoly has been granted, the idea can be shared and utilized as an open secret. In practice, this method requires bureaucratic navigation, legal negotiations, and long term billing/recovery operations. The monopoly may simply be unenforceable in some markets. Aside from these concerns, royalties are a desirable passive income stream.
The second most common method is Direct Use. Direct Use is when a party with access to the invention sells copies of it or uses it as a capital in the production of some final commercial good or service. Some inventions may be operated directly as a service, as demonstrated in the software as a service (SaaS) model.
Arguably the least efficient method is Indirect Services. This method allows the inventor to continue contributing to and working on their invention, but not in a dominant role. The income has to be actively earned and the nature of this work may be very different from the initial R&D. Strategies for Indirect Services involve providing maintenance, support, consulting, or collaborating on related, hopefully profitable projects.
Economics of Open Source
Open Source is a term used for a project which has explicitly forbidden legal monopoly, or in economics jargon, is in “the commons.” Yes, these are the same infamously subject to “the tragedy of the commons”. Unlike physical commons, however, intellectual ones are not a limited resource. This may make them more heroic and less tragic.
Open projects can be read, used, and expanded on by anyone. This obviously is the best deal for users, who get access to the invention for the lowest possible price. In the case of open source ideas, like software or media, the price is usually zero. On the other hand, this minimal price underscores a deep problem for the inventors and contributing developers of the project. How can they recoup the cost of their contributions? Why should they contribute at all?
It is hard for developers to profit selling copies of their open project. Because the details are by definition commonly available, any demand in the market is already being met with the cost of a download or more generally are forced down toward cost of reproduction.
Some Direct Use of open projects is done through foundations, such as The Linux Foundation, where stakeholders come together to fund investment in a commonly used capital good. This is only possible, however, when well organized and funded organizations realize their shared need and willingly collaborate over long periods of time. Needless to say, this is often difficult to arrange in practice.
Probably the most common Direct Use of open source projects is as a “pet.” This is when a single dominant party develops the open project as part of the ecosystem they promote. For example, Google open sourced the Android operating system so that retail products like phones as well as the software apps could be made more cheaply and easily. The Google corporation benefits in many ways from this open platform, and so is willing to contribute the required resources to develop and maintain it.
Indirect Services for an open project often use alternative skill sets. Support and operations are specialized disciplines of their own, which developers have no advantage in. Today, this is usually compensated for by a developer joining forces with complementary labor through the organizational paradigm of a corporation.
Alternately, the developer can seek a less involved form of corporate sponsorship or simply sit by as a corporation takes over the product or service market related to their invention. Again, the required economies of scale are significant, resulting in a high barrier to entry, and an anti-competitive environment.
To understand how to monetize open source projects, one must first understand their nature. Many open projects fit into the economic category of a capital good. That is to say it is primarily useful for producing other things. While there are some examples of projects that are consumer facing, open source is uniquely suited to use as capital in large operations where standardization reaps benefit in economies of scale. Consumers often want variety, which closed source does just fine at. Enterprises want consistency and reliability, which open source is superior at.
As a capital good, the open source project has to be put to use to release the value. Furthermore, the common nature of it inherently creates a race. The first to market with an implementation of the final product or service will reap the maximum benefit of the open capital used in production. If the developers of the capital did not participate in the creation of the final good, it is likely they will never receive an economic reward for their work.
This misalignment of incentives, skills and resources is what makes open source R&D a very unrewarding job. Today, only a few enterprise corporations have everything required to competitively monetize open source projects. These either do targeted R&D to enhance their main businesses, or feed off of community projects.
Consequently, open source developers are predominately employed and directed by large corporations with little creative freedom, or they are volunteers. Pure, open R&D firms are simply not seen as viable market competitors, especially if they’re not huge.
Scalable Open Source Business Strategies (RDOV Components)
The following are some strategies that have worked well for developers. These components of the RDOV incubator model can each stand alone. Each has some difficulties, however, which need to be overcome.
Support can span the range from ongoing development and maintenance to live chat, DevOps, architectural advising, and more. These are Indirect Services that open source developers provide to supplement their projects.
Sometimes the need or desire for this support is engineered into an open source project, sacrificing UX for monetization. This monetization optimization is not necessary with RDOV, but they are not mutually exclusive either.
While some support activities may come easily to developers, it is unlikely that an individual or small R&D team would have all of the skills and availability that support clients desire. Many open source projects have succeeded at this by incorporating and hiring specialized labor that will do much of the billable work.
Ideally, support work could be outsourced to a firm with 24/7 availability, who would read, comment on, and open new project issues based on their calls and complaints. If this outsourcing is accomplished, the developers may primarily receive the digested and technically formatted bug reports and feature requests that they expect.
Sometimes a wealthy party takes an interest in a project and provides it with some sort of sponsorship or patronage. This can take many forms, but can be generalized as financial support for a project. In some cases, this sponsorship comes with payment terms such as logo placement, public recognition, special functionality or support, or even as corporate stock or cash payments.
The diversity of options available for sponsorships makes them particularly difficult to land. With no limits on who could be approached or what terms could be, seeking sponsorship can be a daunting undertaking.
Chances of landing a sponsorship are improved significantly if the project developers describe the future potential in a way so as to interest a non or semi technical sponsor. In RDOV this is referred to as a Future Development Thesis. Of course, complete, popular projects also have an easier time attracting sponsorships.
Often the developers recognize the capital nature of their invention and become co-founders on derived ventures. These new ventures may be of commercial, open source, or even closed source in nature. Most likely, they will be interested in leveraging the unique capabilities of the open source project or its developers.
This is a very long-term, Indirect Services strategy, but if successful gives the developer a full career. Once a developer has produced a successful open source project, anyone can see and evaluate their capabilities. This open evaluation should lead to good-match partnerships.
One issue is that the up front work and subsequent build out time of the co-founded venture mean the developer doesn’t get paid for a long time. Often the co-founded venture is not guaranteed to be profitable, either, in which case the developer undertook one free and then one unprofitable venture in a row. This strategy should only be undertaken if supplemental income or a significant savings reserve is available to the developer.
Aligning Incentives with RDOV Incubators
If inventors and developers are to continue to provide innovative, high quality, open source projects, they need to be incentivized to undertake and continue that R&D work. As the primary creative minds, it would also be a logical deployment of resources to give them a great degree of freedom over direction. This can be accomplished by leveraging the R&D head start to form early partnerships in the race to market.
Upon releasing their invention with an open license, the developers should immediately establish an incubator for related or derived projects. The incubator is the platform by which parties interested in using or building on the invention could receive the very most expert assistance, with the inventor acting as mentor. This is known as the Research & Develop Open Ventures or RDOV model.
At first glance, this may sound like the Indirect Services of open source software business model that heavily favors enterprise corporations. In fact it is that same model, but tweaked to allow the developer to maintain their initial lead, leapfrog the barriers to entry, and outsource non-R&D services. Here is how an incubator operates.
1. Support Agreement
The mentor or incubator project developer sets terms of participation in Support Agreement. This lays out the assistance and access the mentor is willing to give, and what is requested in return. For example the mentor could contribute ongoing development, maintenance, ticket support, operations assistance or even a CTO-style package in return for time-based billing and/or revenue sharing. This Support Agreement can be used as a stand alone contract, or in the greater context of an incubator.
2. Future Development Thesis
Mentor writes Future Development Thesis (FDT) to illustrate what could and potentially will be built with the incubator project. This should be targeted at a specific category of sponsored project or applicant demographic, as each incubator exists to develop the thesis laid out in the FDT. There is a one to one relationship between FDTs and incubators.
3. Financial Proposal for Sponsors
Mentor proposes creation of an incubator which will sponsor projects based on the FDT. In the proposal, the mentor offers a financial plan for the incubator. The financial plan should include a sponsor who will provide grant funding for sponsored projects in return for a share of revenue from Support Agreement payments. If the mentor is not experienced at finance, the sponsor may propose a financial plan for the incubator.
4. Incubator Application
Once a sponsor has been found, and has funded the incubator, it can begin accepting applications. Applicants will submit their proposals for implementing the FDT, and the mentor and sponsors will decide to accept or reject the application.
5. Project Development
If accepted, the sponsored project will be given a grant, and will be entitled to the benefits of the Support Agreement. Initially this could entail some build out, with contractually defined contributions by the mentor. If the mentor invests time on a sponsored project, the Support Agreement may include provisions for time-based billing. In this way, grant money provides steady income for the mentor during the development phase.
6. Operations and Revenue Stream
As sponsored projects launch and begin their own commercial operations, they enter the main phase of the Support Agreement. They may have ongoing requests both regular and for new/expansive development efforts. The mentor will provide ongoing assistance with these efforts as the agreement specifies. For their part, the sponsored project makes Support Agreement payments to the incubator, where they will be further split between the mentor and sponsor.
Example (Founding Incubator)
How does the RDOV model align incentives?
The mentor has a career working creatively on their incubated project as well as specially chosen successors, while receiving both short and long-term income. By defining the terms up front, the mentor is easily able to budget and plan to outsource supplemental services such as front-line support or hosting. This leaves the core intellectual work to accomplish, which the mentor is an expert at.
Even if the sponsored projects lose out to a third party, that party may also want a standalone Support Agreement with the mentor. This will not be on as good of terms as for projects that go through the incubator, but these sorts of support agreements are how many successful software companies operate today. If no viable results come from any of the branches, the grant money will have paid for the mentors time working on sponsored projects.
The sponsor is able to invest in a specific thesis with the guarantee of expert, long term technical guidance on execution. Because the mentor’s incubator project and sponsored projects are open source, the sponsor has complete visibility into the value proposition and results. The mentor is also an expert technical investment advisor, filtering unqualified applicants and infeasible projects from the investment pool.
The sponsored project receives an open and well maintained platform to build or operate on, as well as the mentoring and support of the platform developers. This may greatly reduce time to launch, and will certainly reduce long term maintenance costs. Whether a sponsored project is another open venture or a corporation, there is no better assistance they could ask for than the mentor’s.
Consumers win because a viable and thriving open source R&D sector means more open source products. Open source products give consumers control, choice, and privacy. More R&D being open should accelerate even the closed R&D pace through free cross-pollination of ideas.
Open Ventures: A New Organizational Paradigm
Open Venture - A for-profit project or business that uses primarily open source technology to achieve its goals.
Using the RDOV model, open ventures can be chained to create vertically integrated, complex products and services, while maintaining a simple, developer controlled organization. These organizations are complimentary with, but potentially much looser than that provided by incorporation.
Support Agreements and Grants are much less strict, regulated, and complex than incorporation and securities. They are something that individuals or small teams can easily interface with. They are uniquely suited to the environment of open source development, where the contributors may have no geographic relationship, or formal organization and may be using pseudonyms.
Open ventures may start as individuals or small, informal R&D teams. These teams can arrange themselves on the fly, then do real, openly verifiable work and support, receiving payment in cryptocurrencies. From there, they can either expand to economies of scale using these contracts and structure, or simply disband.
The low barrier to entry and rapid project lifecycle should produce a wealth of open ventures. On the successful end of the spectrum, it is not clear where the limits of the legal structure is. It may be possible that an individual or small team of developers could operate a very large scale open venture, comparable with any corporation.
Future Development Thesis
The RDOV business model is based on industry best-practices but untested in specifics. Among other things, this means that contracts and basic details of RDOV arrangements have not been worked out. These need to be created, made available for public review, and then beta tested by entrepreneurs.
This whitepaper and other generic RDOV resources such as use cases and sample contracts will be hosted on the rdov.co domain as a public service by Deginner.
To provide a funding and organization framework for RDOV development, a franchise should be created which will facilitate best practices for Open Ventures. This will take the form of a web app named Our Dove. The franchise aspect of Our Dove will be to offer a user interface for managing RDOV contracts and relationships, and eventually supplementary outsourcing for front line support, hosting, DevOps and other services. This should allow greater specialization and focus for open ventures while giving the Our Dove corporation a long-term incentive for experimentation, development and marketing of the RDOV model itself.
Our Dove should be crowdfunded, to encourage community involvement from day one. As consensus contracts and best practices emerge, Our Dove will incorporate them into its UX. Through crowdfunding, Our Dove will be the first sponsored project, even before the Founding Incubator is created. Deginner will be the mentor, providing the application framework Deglet. Its sponsors will be the crowdfunding supporters. Its users will be generation after generation of RDOV-style ventures leveraging the tools and services Our Dove creates.
The contributors views and opinions are their own. Google, Android, The Linux Foundation, Deginner, Our Dove and all other proper nouns, copyright, trademark, and otherwise property of their respective owners. No relationship or association is intended or implied.