As much as there is a romantic notion regarding a distributed group of purely volunteer resources working together in their free time to produce an enterprise-level software product, it does not represent reality. To effectively manage all of the aspects of a professional software product, dedicated management is an absolute requirement. This does not just entail the standard project management principles for software development, but also the legal and marketing aspects of managing a high-profile technology asset. Since the project inception, I had been able to commit 100% of my time to the project only because there was a sufficient stream of project revenue to support my needs. And throughout the life of the project, a number of team members had been financially compensated for various deliverables so that we could meet obligations and scheduled deadlines. The financial resources came from a variety of sources, including third-party sponsorship, advertising, and custom consulting opportunities. Unfortunately, the revenue streams were not sizable or stable in terms of securing multiple resources for long-term engagements. Essentially, we were trying to operate a product company without any direct product revenue. And with the constant growth of the project, the demands were increasing rather than decreasing, putting even more pressure on the minimal set of project resources.
Back in July 2005, I concluded that without a dedicated sales effort, the dotnetnuke.com web site was never going to reach its full potential as a revenue-generating asset. (We had published ad rates on the site months earlier and had not received many serious inquiries.) I decided it was time to more actively cultivate our advertising and sponsorship revenue streams and that it was going to require spending some money to make money. Armed with a huge number of industry contacts collected at Tech Ed, I hired a full-time resource to actively manage the advertising and sponsorship program. Due to major content improvements made in the previous four months, the dotnetnuke.com web site became a targeted channel for the Microsoft development community. By simplifying the advertising rate sheet and employing traditional sales techniques, we were successfully able to grow this revenue stream in a relatively short time frame.
In the fall of 2005, while driving home from a business trip, I spent some dedicated time immersing myself in the revenue model dilemma. Over the years, I did a lot of research on business models for open source projects, and the big question was, "How do you sustain an open source organization while still adhering to its open source ideals?" There were obviously a number of companies that had demonstrated their ability to succeed in this area by employing a variety of financial options; however, I was keenly aware that each model had its own set of disadvantages.
One of the other recurring themes I kept thinking about is "who we serve." In a traditional business model, you serve your customers — but this generally assumes that some money is changing hands. For DotNetNuke, I would like to think that our open source community is who we serve — but because they are essentially using the product for free, it becomes challenging when other stakeholders step forward with financial support. Examining each of the more popular open source revenue models based on this theme proved to be a useful exercise.
The Pure Volunteer option has no revenue model. As a result, it has no resource cost — but at the same time it has no accountability, responsibility, or dedicated management. It could be argued that although it is supposed to serve the open source community, it really does not because there are no motivating factors driving the development and support.
The Dual License model has become popular in recent years because it allows for an open source version as well as a commercial version of the same product. The commercial version provides traditional licensing revenue that helps sustain dedicated management and developer resources, resulting in improved accountability. Unfortunately, it tends to lead to a number of conflict-of-interest scenarios within the ecosystem that can be quite damaging. For one thing, the open source version of the product is often stripped of its more valuable features in favor of promoting sales of the commercial version. The open source license is often tarnished to protect the intellectual property rights of the company in the commercial version. Extensibility options are throttled as the company attempts to control the financial ecosystem around the product. And the company typically shows favoritism through support and marketing channels to its paying commercial customers over the organic open source community. In the worst-case scenario, the company can be accused of taking the most valuable intellectual property from the community and using it for their own financial gain.
The Sponsorship model involves utilizing a revenue stream from one or more third-party funding sources. Although this revenue model results in funding for dedicated management, it often compromises the project ideals as the sponsor attempts to exert their influence over the project roadmap and marketing goals. It also results in a revenue stream that is variable, creating challenges in terms of cashflow requirements. In addition, the project needs to be extremely diligent regarding the ownership of the intellectual property so as not to put itself in a situation where the third party could sue the project for copyright infringement or affect the open source project licensing.
The Professional Services model is based on a concept where the platform maintainer does a significant amount of custom consulting for a third-party client. The revenue from the custom consulting is used to fund the dedicated management for the open source product. Unfortunately, this model tends to consume a high level of resources to qualify leads, formulate contracts, manage accounts, obtain signoff, and keep the pipeline full of revenue opportunities. The revenue stream is variable, affecting cash flow, and key project resources are often required to focus on specific client requirements rather than supporting and improving the open source product.
The Charitable Donations model is popular in the traditional open source world because it involves voluntary community financial support of the project. The problem is that it does not generate a consistent, sustainable revenue stream, which means it is unable to secure dedicated management resources. In addition, there is a tendency for community members to assume that other members are making financial donations, when in reality the project is receiving no financial contributions from anyone.
The Vertical Application model leverages the open source product to create a highly specialized, commercial, vertical market application. The vertical market application typically generates revenue through as application service provider (ASP) revenue model, which contributes funding back to the open source project. The challenge is that it requires focused management and marketing in the vertical market, complete with domain challenges, competition, legal considerations, and political constraints. The open source application also tends to cater the product roadmap to the needs of the vertical market application, resulting in a less robust application framework.
Because each of the common revenue models seem to have their own set of issues, it made me brainstorm what I would consider to be an optimal open source revenue model. The main criterion is that the project should serve the open source community ("by the people, for the people"). It should be objective and open, avoiding conflict of interest and adhering to open source ideals. Finally, the revenue stream must be consistent and sustainable, capable of sustaining multiple dedicated resources.
An interesting economics philosophy that Scott Willhite turned me on to was the concept of the "abundance mentality." In terms of business value, an "abundance mentality" refers to an attitude of growth. Essentially, it means that the overall size of the ecosystem becomes larger as the number of opportunities within the ecosystem increases. By working together with various stakeholders in the ecosystem, all members of the collective group benefit through a greater abundance of revenue-generating opportunities. The opposite of the "abundance mentality" is the "scarcity mentality," where participants consider the size of the ecosystem to be constant and the goal is to capture as much of the market share as possible (choking out the smaller competitors in the process). DotNetNuke's extensible architecture and open source philosophy constantly pushes the envelope in terms of creating new business opportunities within the community. It was another principle that needed to be adhered to in our quest for a suitable revenue model.
With all of these ideas swirling in my head, I concluded that a Membership concept would be an effective revenue model for advancing our goals. It would mean that the open source project was funded by the community. It would also mean that the project was accountable and responsible to the community. Through the creation of new benefits, we would be able to provide more opportunities for community members to participate in the project ecosystem. From a public perspective, it would provide a defined method for any supporter, big or small, to contribute to the project. And we would not need to compromise any of our open source ideals. Membership would be available by subscription that would create on ongoing, consistent revenue stream.
The DotNetNuke Benefactor Program (see Figure 1-14) was officially launched in December 2005. Nik Kalyani came up with the marketing term "benefactor" because it clearly communicated the financial support goal of the program. The program had four levels of participation to cater to the needs of various stakeholders in the community, from individual developers to enterprise business organizations. The initial set of benefits was targeted to each program level and the administrative aspects of the program were automated as much as possible to provide a seamless user experience. The overall response to the program was positive and paved the way for future revenue opportunities.