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!
> 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.
Next, I decided I may as well give it away for free to bring more traffic into my site, and eventually decided to release it under the GPL.
At some point, after receiving many emails asking for help installing it (not everyone who knows how to make a web page knows how to set up a PHP script), it occurred to me that I could give people the option of hiring me to install it for them. A number of people have done so, and I've gotten some custom work from some of them too. I also get great ideas for improving the product when people ask to have it do things it can't do yet.
Has this experience convinced me to GPL anything else I've written? No. I do have a few other little things I'm giving away free, but I also have a number of products that I won't be releasing that way. Some I previously distributed as shareware, and found that very few people were willing to pay even a very small registration fee. So I switched to giving away a somewhat crippled demo version and requiring payment for the full version.
I guess the moral of this story is that if a enough users of a product will need someone to set it up for them, and if the price you can charge for setting it up is comparable to what you'd sell it for if you sold it, open sourcing the product can work well. But I don't think open source is the right model for everything--not unless you already have all the money you need and are just developing products for fun.
Convert RSS to HTML - integrate webfeeds into your website
IMHO, it is possible to make money with open source software. The secret is coming to the realization that you aren't going to make any money by packaging the software and selling it in boxes. OSS software is available for FREE, so why would a customer pay for it in box when he/she can get it for free elsewhere? Obvious point, I know.
... consulting. offer consulting services (for $$) to guide customers through custom module development, implementation, design, etc. Perhaps you could even offer high level technical support for $$ -- opportunity #4. Web design services for the Cow CMS -- opportunity #5.
So, how does one make money with OSS? Services. Granted, incorporating and building paid services around your open source software may not be simple in all cases, it can be applied very well to certain types of open source software.
For example, lets look at the CMS arena... lets say that I have a OSS CMS called "Cow". I make Cow available for FREE to anyone that wants it. BUT... Cow, being the sophisticated piece of software that it is, requires a web server with certain dependencies. Some people will be able to setup Cow and run it on their own web servers and some won't. There's the opportunity for service #1... specialized hosting for the Cow CMS. You can charge $$ for specialized hosting of Cow CMS based websites.
Since our fictional CMS (Cow) would be modular, you as the developer could make highly advanced and highly functional modules available to end users for $$. Perhaps they need a eCommerce module with some advanced capabilities. Perhaps they need a specialized payment gateway. There's opportunity #2.
Lets say that Cow CMS has grabbed the attention of a few big web sites. Now, you have some real commercial entities showing interest in the CMS. Opportunity #3
See, I think it is possible to make $$ with open source software by adding services of real value around the software.
A few random thoughts for the "services approach":
1. The software has to be good and have at least the majority of functionality of commercial competitors.
2. The software should be able to run on the windows platform.
3. The UI should be of commercial quality.
4. Not every type of OSS software will lend itself well to the "paid services" approach. CMSs are a good example, as would be any type of specialized vertical market software, such as Medical Practice Management systems.
5. You need to understand your market! Understanding your market means you'll understand which services would be of real value.
Skiers and Riders -- http://www.snowjournal.com
Charing for support is one of the popular ideas abouthow to make money from free software, but have you ever actually tried it?
Yes. That is how I am currently earning a living. My employer is a Linux integrator. Since mark-up on selling CSS is so ridiculously low, there is no point in generating profit for another business (the software manufacturer); you are better to work toward grabing a bigger chunk of the customer's money by selling service instead of license. In case you wonder, my employer is doing quite well : we are profitable, doubled the staff this year (we have lots of work) and I recently received a bonus.
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?
Yes, a big chunk of the support is getting-started (actually, installation/customization). Yes, I expect customer to pay for installtion and customization and, yes, they do. If they would buy some shrink-wraped software, they would have to pay beforehand anyway (and probably pay somebody for the installation/customization too if it is anything non-trivial). You sell them a solution, they buy it. Is there more to it ?
And if somebody writes to ask: "hey, quick question" Do you reply, sorry, but that'll be $5 first.
Yes. Actually, you sell them a support contract. Some are incident-based, other are time-based ("hour bank"). I think time-based is preferable for both party, as it let the customer ask many little question for cheap, protect the integrator from nightmarish problem that pay only for an incident (it happen) and eliminiate fight over what constitute a single incident vs. many smaller one.
What exactly is so unusual about this business model ?
:wq
The OpenScenGraph - its an open source scene graph, which takes an OO approach to doing real-time computer graphics.
>What market do you compete in?
The main markets are Visual Simulation, Virtual Reality, Games and Scientific Visualization.
> What is the name of your company?
OpenSceneGraph Professional Services, based in Scotland.
> Web site?
http:://www.openscenegraph.org
The is also http://www.andesegineering.com which is a partner company that also provide services ontop of the OpenSceneGraph and related projects. Andes Engineering has now been in business for over two years, based in California.
> I prefer Free Software, but the overwhelming majority of software companies (and by extension job oppurtunities) I see could not exist on service and support contracts alone.
I believe the sweet spot for open source is in the realm of OS's and middleware. Making money in these areas with commericial products is very difficult (unless you have a stranglehold monolopy) and doesn't provide as good a service to end users - who are often developers themselves. Developers using middleware & components of the OS have the most to gain from access to the source, and often have the skills to put effort back into the OS/middleware. So both the Open Source developer and user/developer have something to gain. The gains for the Open Source developer is that they can achieve much more with a smaller sized team, that in turn requires less of a revenue stream then need to bring in to make things viable.
I see the sweet spot for being closed source end user applications, especially specialist applications. In these areas the Open source project itself provide little more than lower cost and the being non proprietary, the source ain't much use to 99.9% of users. Also 99.9% of users have none of the skills to put back into he product. Here the Open Source user has much less to gain from being open sourced. Whereas the closed source developer has the opportunity for collecting greater revenues which in turn support developers, testers etc. to do the job of the developing the product.
Robert Osfield