Every (Open-Source) Software Project needs a Business Model

Most software developers have little interest in entrepreneurship, but an open-source software project will survive and thrive only by delivering value into a market (users) with business partners (contributors) and against competitors (other open and closed source software). If you want to run a successful open-source project, it helps if you consider the key questions that apply when defining a commercial business model. I'll expand on Chesbrough's and Rosenbloom's list of 6 themes to demonstrate why.

1. Value proposition - a description of the customer problem, the product that addresses the problem, and the value of the product from the customer's perspective.

To an extent it's true that if you build it, they will come - but users and potential contributors may not understand it when they get there.

Many open-source software projects state what their software does (or will do) in terms that are either too brief, too vague, too complex, too aspirational or too hard to find. The value proposition is the most important part of your project, so if you can't yet explain it clearly and simply, you probably need to think about it some more until it can be clearly understood by your target market and (ideally) to some extent by anyone. Even before you share your project with the world, it's worth writing down the delivered benefits for yourself; the efforts you invest will lead to a more useful and relevant software product if it has clearly defined goals that serve some (ideally large) market of users or customers.

The best approach to clarify and refine your project's value proposition is to talk to a few people in your industry who you trust and try to describe what you want to achieve. You may get useful or poor feedback, but you use different parts of your brain when you communicate, so one way or another you will certainly clarify your project's value.

If you get only negative feedback, consider it carefully but remember that engineers and analysts just love to nit pick and rarely think about supporting the good points in a proposal; it is essential to look for feedback from non-developers and (most important) to ensure you talk to at least one woman or the rare gifted male with the ability to see the big picture, separate the wood from the trees, and (most important) park their ego at will. If no one understands your proposal or likes some aspect of it, this is a sign you need to either look for more feedback or to consider an alternative project. Not every idea has to be good, let alone great, and some ideas are simply before their time; for example, once upon a time Windows was a disruptive innovation on DOS, and internet search was expensive for the hoster and almost useless for the user - so don't give up on a great idea.

In the end, don't be concerned if you decide that your original project idea is not worth pursuing; your time is too valuable to waste on developing software that for one reason or another won't be successful - and there's plenty of real problems to solve and great software to create.

In fact the best possible outcome of this investigation is that you find an existing solution that meets some or even most of your needs; in that case, it's better to add your critical 10-15% to it rather than building 50-90% all over again. Joining an existing software project means that you start with a foundation of users and contributors. It also means you can spend more time developing software and less into supporting and evangelising it. Finally, if you can't drive the project in the directions you need it to go, the open-source license may permit you to fork the code, though this is clearly a last resort because of the ill will it creates among contributors and users, not least because it dilutes the effort on the original and your forked project.

The worst possible outcome is that you overlook a strong competitor project. If you discover it later, the best response may be to adopt it, as a user and possibly as a contributor.

If you decide to proceed independently, do so knowing that you will face a harder battle to gain users and contributors than originally expected. Remarkably, quite a few open-source developers find marginal reasons to justify redeveloping software from scratch; these reasons usually have little to do with providing better capabilities (usually just different ones) or more usability (usually just different user experiences) than the existing applications.

2. Market segment - the group of customers to target, recognizing that different market segments have different needs. Sometimes the potential of an innovation is unlocked only when a different market segment is targeted.

In terms of product scope and development focus, open source tends to target developers, IT and end users, in that order. The choice of technology platform (e.g. web browsers, Java, .NET, Windows, UNIX) and implementation (e.g. Sun, JBoss, Apache, Microsoft, GNU) may define your market segment. Alternatively the standards (e.g. SOAP, HTTP) and formats (e.g. HTML, XML, OASIS OpenDocument). But technology and standards are the meat and drink of developers so you'll naturally think about those aspects. There's a lot more however to defining your project's market.

First off, it's worth highlighting that every open-source project effectively has two markets: the product's users and the project's contributors. Ideally these two markets are large and congruent (so all users are potential contributors), but practically speaking a contributor has several qualities that a user doesn't have: the ability to contribute but also the will to do so, possibly motivated by generosity, a need to share, ego gratification or because they actually need the feature they are contributing. Of these, the last is most likely to benefit the project because it requires real effort to satisfy the need.

The more ambitious the project, the more important it is that it focus on meeting the needs of contributors (architecture and in-source documentation, source version control, simple IDE-neutral build system, etc). It will also be necessary to have a separate web page (or even a micro-site) for users versus contributors; the user page should focus on the pragmatic, the contributor page should guide and facilitate the possible.

In the same way as you need to consider the value your project will provide, it's worth thinking about what characteristics define the ideal customer for your project. A developer who believes their software will be useful to absolutely everybody is probably also haunted by daydreams of world domination, getting a call to join (or be acquired by) Google or receiving an Open Source Oscar from Milla Jovovich. Realistically, in the short term your software will be useful only by a small target group - developers who are prepared to accept a small set of features, simple packaging or imperfect quality. Success in most open-source projects means first to focus on meeting your own short-term needs and then to grow the software organically, in part responding to what other contributors offer in terms of skills and enhancements.

After a phase of early adoption and as your project attracts more users (and possibly customers who fund the project by donations or via commercial licensing, service and support contracts, or custom development) the desire for more features increases, but the expectation and even demand for quality also increases. Just because people aren't paying for your software doesn't mean they will accept major functional or non-functional bugs, or tolerate data loss or regressions across subsequent versions. If you can't sustain quality at your present pace, you need to slow down feature development to improve the code base and your development process. Otherwise the user volume your open-source strategy provides is simply giving you a chance to demonstrate widely that your software is buggy; your project may never recover from bad reviews.

3. Value chain structure - the firm's position and activities in the value chain and how the firm will capture part of the value that it creates in the chain.

Open-source projects deliver obvious value in terms of code, build and installation support, and user or developer documentation. External contributors are often a key part of the process of delivering value; this is often the main reason for making a project open-source.

A company that participates in or runs an open-source project may extract value from the project by extended product, solution or service offerings.

Many open-source projects start from one developer's need to solve a specific problem. If you are focussed on meeting your own current need, your effort can't be wasted; in this case, thinking about your market isn't necessary.

Some developers hope that they will attract contributors simply by publishing their code on an open-source host; practically however, sourceforge.net might as well be sourceforget unless you create a useful web-site and some documentation around the project.

Open-source contributors
A company may benefit directly from the open-source project if it uses it within its own offerings and if it attracts external contributors, however it's important to be realistic about the pyramid of contributors:

• informal testers are the broad foundation, then
• translaters,
• sporadic bug-fixers,
• platform-porters,
• niche implementers, and last and definitely least,
  
• broad-based developers

Aside: Understand the motivation
If the idea to open-source code comes from within your R&D organisation, consider whether this is simply an attempt by a developer to secure the ability to use the code in other companies. An open-source strategy should not be selected lightly and only after considering the above points.

Conversely, if a developer within a company wishes to open-source code that they develop on their own time, they should be allowed to do so at least on a probationary basis, so long as the scope of the project does not allow any of the company's IP to be leaked. At the very least the developer is honing their skills on their own time, their motivation may be improved; in the best case the company may be able to use the code in its own products.

4. Revenue generation and margins - how revenue is generated (sales, leasing, subscription, support, etc.), the cost structure, and target profit margins.

The simplest (but possibly the least effective) way to make money from open-source is to radically restrict the rights to use or redistribute the code in the hope that this encourages users to purchase your commercial-friendly license or service package. The GPL license for example prevents third parties from building a partially closed source application that includes your code (depending on the interpretation, it may even cover building install scripts that install non-GPL and GPL code; it certainly covers calls from non-GPL to GPL code). For customers who cannot live with these limitations, this is essentially commercial software with read-only access to the code. The terms of GPL (and to a lesser extent LGPL) are sufficiently ambiguous that in a distributable product, they are only really safe to use if it is entirely GNU-licensed.

Note: GPL seeks to impose it's license virality even across executable boundaries; for this reason, it's not even safe to execute a GNU program (even a commodity utility like sort or uniq) from a closed-source program!

From a broader business perspective, if the open-source project is to be the vehicle for establishing or extending a volume market for a company's services (consultancy, support, custom solutions, branded training/certification) or other products (an extended or enterprise edition), then it is critical to define:

• the boundaries of the free and the value-add of the fee-based offerings
• the customer's paths from free to fee
• the organisational investment in marketing, execution and distribution required to capitalise on the opportunity created by the core open-source offering
• how your company will respond to competitive threats from companies that simply incorporate your open-source software into a (marginally) later offering

Volume without a business model to capitalise on it won't keep a company running long.

The irony of open-source software within a business strategy is that all open-source software functionality is immediately a commodity and the more valuable the source (due to its clarity or documentation), the less valuable it is to the originating company because competitors can more readily build on it. Either the functionality of the open-source base should be significantly less than the extended fee-based product, or the source code should be impenetrable and thus hard for a third party to service or expand.

It is hard to withhold quality as a motivation for customer to pay because the volume users who try your open-source software are unlikely to believe that they can benefit from your fee-based offerings; at best you can offer support that guarantees that the customer can raise a certain number of issues annually that will be resolved promptly.

If you really want to leverage contributors, you will have to be prepared to both offer and share leadership with them. Some open-source project forums simply become a talking shop, but every successful project has a clear public vision, shares its knowledge, and offers specific guidance on what kinds of contribution they are looking for and how to provide them.

5. Position in value network - identification of competitors, complementors, and any network effects that can be utilized to deliver more value to the customer.

Let's start with network effects. Open-source is all about exploiting the internet as a platform for a web of contributors to collaborate. See 3 above for a list of likely types of contribution from informal tester to broad-based developer, noting that you typically get far more of the former than the latter.

Depending on the open-source license you choose, you open the potential for complementors. True complementers create non-competitive value-adds, which enhances the market for your product. But open-source enhances the risk that complementors become competitors who simply embed your offering within their own. If however you have a means to get value from your open-source product regardless of how it is used (e.g. service, support, training), then complementors are simply a way to achieve greater volume.

The next section addresses competitors.

6. Competitive strategy - how the company will attempt to develop a sustainable competitive advantage, for example by means of a cost, differentiation or niche strategy.

Competition may seem like something that only a commercial product needs to consider, but if there are existing solutions, then your project has to offer something more, better or different if its going to reach a lot of users.

If you decide to offer more, then it may still be effective to join or complement the best existing open-source project.

If your project will be successful because it's better or different, then be clear how the difference will benefit the users. If the differences are purely in terms of qualities of the code (in-source documentation, readability, ease of maintenance or extension), then you could still achieve those qualities incrementally by refactoring; any modern IDE will provide some very useful facilities for making reliable mechanical restructurings such as generating and applying get- and set-methods, renaming classes and members, or extracting methods and interfaces. An existing project will give you the benefits of having runnable code, existing functionality and a community of users and contributors that you don't have to start from scratch.

When considering the field and threat of competitors, look at companies with closed and open-source products, and consider both the obvious competitors and those that provide competitive value. For example, even though spreadsheets, office database applications and wikis all clearly provide less value than an enterprise database-based solution designed to support specific use cases and workflow, they all compete at some level because they enable data to be manipulated, stored and shared. They compete most of all because they are already paid for and installed in most companies, and people naturally want to leverage their existing skills even if it is costs more in time than buying and learning a new purpose-built application.

Conclusion
Open-source isn't easy; it's far easier in many ways (or at least, it requires a narrower range of skills) to develop something yourself or within a team in a single company. But the potential benefits of the open-source approach are clear. It's good to code and great to share - your open-source project will be more successful if you start it with the forethought of an entrepreneur.

Update: there's a fair bit of discussion going on around this post - check the comments for links.