Slashdot Mirror
Commercializing Open Source Software
CowboyRobot writes "Michael Karels, system architect for BSD 4.3 and 4.4, has an article on ACM Queue about the challenges in trying to make money from open source software. From the article: 'As users of the software, open source contributors have certain common interests in making the software stable and usable.' but 'When additions require modifications to the base system, there may be resistance to incorporating the changes.'"
> Does anybody have the text of the article?
Commercializing Open Source Software
ACM Queue vol. 1, no. 5 - July/August 2003
by Michael J. Karels
Introduction
The use of open source software has become increasingly popular in production environments, as well as in research and software development. One obvious attraction is the low cost of acquisition. Commercial software has a higher initial cost, though it usually has advantages such as support and training. A number of business models designed by users and vendors combine open source and commercial software; they use open source as much as possible, adding commercial software as needed. They may use open source software as a central component of a product or service, but use other components to add value, which can then induce customers to pay for the offering (obviously, it is hard to compete with free software on price).
After a brief overview of the salient differences between open source and commercial software, this article will describe several basic business models in today's marketplace to highlight ways that value is added to open source software and services. For the most part, I will discuss only complete software systems sufficient for some useful purpose, such as network servers, which include an operating system and its associated components, any applications needed for the system's purpose, and necessary local configuration information. Many of the same principles apply to components such as applications and other software packages.
Open Source Development
The development process for open source software is often quite different from that of traditional commercial software. In some cases a single author or a small group may develop and distribute a program or system. Successful software often attracts additional developers, however, and larger projects generally require larger teams. These teams tend to be distributed, with participants in different locations and with different affiliations. Some members may contribute their own time; others may be paid to work on the project. Some projects develop infrastructure such as a consortium to coordinate the project; others work with a looser organization. In either case, projects are likely to be organized with less central control than in traditional software development. Some projects may have a strong central figure such as the initial author of the software, but many other projects have "outgrown" central control.
This less-centralized structure affects the development process for open source projects in several ways:
* Community support is often available via mailing lists associated with a project. Response ranges from rapid to nonexistent.
* Projects may have many volunteer contributors. Their abilities and availability can vary significantly.
* In terms of quality, Darwinism applies. Some software features may be added while the project is still incomplete or experimental. These features may eventually be removed or replaced, or they may be improved over time. The addition of features and other modifications is driven by the interests and wishes of the contributors (including companies that pay staff to extend open source software). As users of the software, these contributors have certain common interests in making the software stable and usable. They may have substantially different uses for the software, however, as well as different ideas about how the software should be engineered and extended. The direction taken by the software developers may be driven by those who have the most time to devote to development or by those with the greatest tolerance for the discussions on mailing lists for the project. When different groups design and implement the various subsystems, their architectures might not have similar or compatible styles.
* The open source process is inherently social and political. Group leaders spend as much time on organizational matters and conflict resolution as on technical issues
CAPS LOCK IS LIKE CRUISE CONTROL FOR COOL!
Perhaps we shouldn't be trying to commercialise OSS. Perhaps we should be trying to commercialise the businesses and products/services which rely on OSS.
For example if I set up a cybercafe and write some software to deal with scheduling and billing, I'm not looking to make money from it. Instead I'm looking to make money from the business that relies on it. Providing a service is what is going to make me the money, and by opening the source of my billing software I may find a wealth of people willing to help me improve it and to use it themselves in other commercial products which pay their bills (and not mine). I get free upgrades and enhancements and they get the basis of a product that runs their business.
It's just an idea, and I'm no economist, but I have a feeling that this sort of set-up could work in many situations.
The key is educating companies in to believing that it's their (civic?) duty to contribute back to the OSS products they use. For example, if every business that uses Linux and has more than 1000 employees were to donate the time of one employee to improving Linux (working full time in the OSS community), we'd see pretty rapid improvement. People are begining to catch on (IBM, Red Hat...), but more of the same would be nice, IMVHO.
1 - develop a application ( you know how to do it, no ?
:)
:)
2 - try to "sell it" to as manny organizations as you can (for free).
3 - Make a contract with those organizations (for maintenance, bugfix, feature add)
4 - make it available to the world as open source.
What the organizations get:
1 - A "free" software. Maybe not the best there is, but sometimes they need months to decide on what to use (because it costs a lot of monney), but they need something now. There comes your program. And believe it or not, most times, your program will be the "final one".
2 - Direct contact with the developper
3 - A rapid deployment.
4 - Low risk (if you don't charge much for your software
What you get:
1 - costumers !!!
2 - flat fee revenue (aka you know what you're going to get in the end of the month)
3 - going open source enlarges your app "possible customers" universe.
4 - You can still get lot more customers with onsite or remote support for instalation, bugfixing, feacture adds.
What the world gets:
1 - Open Source Software
2 - open source software development backup up with real money.
I adopted this in the last 3 years, and its working great
The fact is, most support is of the getting-started variety. Do you expect those people to pay for support *before* they have their software working? Or do you help them get set up for free, after which they have little need for support?
And if somebody writes to ask: "hey, quick question" Do you reply, sorry, but that'll be $5 first.
Here's what I do: Bitty Browser & Andromeda
> But because of things like the GPL, they've effectivly shot themselves in the foot.
If you dare to read the article, you'll find an amazing way of making money off GPL (look for 'Dual Licensing').
GPL requires the derived work sources to be published under the same license, which is unacceptable to many businesses. However, one can always bargain with author for separate license for their specific project.
Anecdotal evidence: I was involved in a proprietary project where we needed a very specific functionality. The opensource library doing just what we needed was there, but licensed under the terms of GPL. The contact with author revealed that he is perfectly willing to relicense it for us for a nice amount of $35000. And it really was an OK price because reimplementing the necessary functionality from scratch would cost the company considerably more, and we wouldn't fit into the timeframe anyway.
Lisp is the Tengwar of programming languages.
I have been successfully running my own Free Software Business for the past 2 1/2 years. Every quater I hit or exceed my targets, and comfortably in profit - might not be rich but certainly have perfectly viable long term business.
My company provides consultancy, support and training ontop of the open source project I lead. The key to success is that the project competes well in terms of functionality and robustness with equivilant commericial products, and that you provide the services that the market requires ontop of that product.
FSB's really are little different than conventional companies, if you provide and product or service that the market want at a price that is reasonable for the customer, yet profitable to provide, then you're in business. It really is very simple. Robert Osfield.