http://www.crm-daily.com/perl/story/21280.html

http://fscked.org/writings/OpenSource.html

At this point, the average commercial software advocate is becoming very concerned about where the money is going to come from. The Open Source Definition allows people to charge a "reasonable" distribution fee, usually to cover the cost of media and packaging. However, companies involved in the production of open source software have a myriad of revenue possibilities. Documentation and technical support are among the most obvious. Sendmail, Inc. (the makers of sendmail) and Artifex Software (the makers of ghostscript) release old versions of their software as open source. Before being bought by Redhat, Cygnus capitalized on first mover advantage by providing embedded systems companies with an initial port and continual support of the GNU development tools for their architectures. Troll Tech and TransVirtual both follow a strategy of releasing separate identical versions of their libraries under both a commercial and an open source license. Redhat operates under the idea of branding. Their market strategy is to be the name most people associate with Linux. Therefore they most often turn to Redhat to purchase a Linux distribution, and for certification.

But perhaps bigger than all this is the fact that most software written in the world isn't even sold! In many companies, software is just a means to an end. In some cases, it's developed at corporations internally to help them do a particular job. This is how perl got its start. In other cases, companies that aren't in the software business per-se may benefit indirectly from open source software running better. Companies like SGI, Compaq, and Intel are eager to pay programmers to improve open source operating systems on their respective architectures.

So you see, there are plenty of opportunities to pursue monetary gain while still preserving your karmic alignment.

[edit] Dual licensing

How to choose a free software license.:

Get rich: Maybe you hope to make money of the product, and want to use the free version for marketing and perhaps debugging. This is perfectly all right, lots of useful free software is developed like this, examples include Qt, Ghostscript, Cygwin, MySQL and ReiserFS. The developers of all five have both free and non-free versions available. Here, you want a "copyleft" license that prevents others from undercutting you in the non-free market. GPL is used by Cygwin, MySQL and ReiserFS, Qt uses a QPL/GPL dual license, and Ghostscript uses the "Aladdin GPL" which is just short of being OSI certified, but old versions are available under the GPL.

QPL can be combined with most free software licenses but GPL, and GPL can only be combined with GPL, LGPL, and licenses close to PD.

Suggestion: Use a GPL / QPL dual license.

http://producingoss.com/html-chunk/dual-licensing.html Dual Licensing Schemes

Some projects try to fund themselves by using a dual licensing scheme, in which proprietary derivative works may pay the copyright holder for the right to use the code, but the code still remains free for use by open source projects. This tends to work better with code libraries than with standalone applications, naturally. The exact terms differ from case to case. Often the license for the free side is the GNU GPL, since it already bars others from incorporating the covered code into their proprietary product without permission from the copyright holder, but sometimes it is a custom license that has the same effect. An example of the former is the MySQL license, described at http://www.mysql.com/company/legal/licensing/; an example of the latter is Sleepycat Software's licensing strategy, described at http://www.sleepycat.com/download/licensinginfo.shtml.

You might be wondering: how can the copyright holder offer proprietary licensing for a mandatory fee if the terms of the GNU GPL stipulate that the code must be available under less restrictive terms? The answer is that the GPL's terms are something the copyright holder imposes on everyone else; the owner is therefore free to decide not to apply those terms to itself. A good way to think of it is to imagine that the copyright owner has an infinite number of copies of the software stored in a bucket. Each time it takes one out of the bucket to send into the world, it can decide what license to put on it: GPL, proprietary, or something else. Its right to do this is not tied to the GPL or any other open source license; it is simply a power granted by copyright law.

The attractiveness of dual licensing is that, at its best, it provides a way for a free software project to get a reliable income stream. Unfortunately, it can also interfere with the normal dynamics of open source projects. The problem is that any volunteer who makes a code contribution is now contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable contributing to the free version, since that's the norm in open source projects, she may feel funny about contributing to someone else's semi-proprietary revenue stream. The awkwardness is exacerbated by the fact that in dual licensing, the copyright owner really needs to gather formal, signed copyright assignments from all contributors, in order to protect itself from a disgruntled contributor later claiming a percentage of royalties from the proprietary stream. The process of collecting these assignment papers means that contributors are starkly confronted with the fact that they are doing work that makes money for someone else.

Not all volunteers will be bothered by this; after all, their contributions go into the open source edition as well, and that may be where their main interest lies. Nevertheless, dual licensing is an instance of the copyright holder assigning itself a special right that others in the project do not have, and is thus bound to raise tensions at some point, at least with some volunteers.

What seems to happen in practice is that companies based on dual licensed software do not have truly egalitarian development communities. They get small-scale bug fixes and cleanup patches from external sources, but end up doing most of the hard work with internal resources. For example, Zack Urlocker, vice president of marketing at MySQL, told me that the company generally ends up hiring the most active volunteers anyway. Thus, although the product itself is open source, licensed under the GPL, its development is more or less controlled by the company, albeit with the (extremely unlikely) possibility that someone truly dissatisfied with the company's handling of the software could fork the project. To what degree this threat preëmptively shapes the company's policies I don't know, but at any rate, MySQL does not seem to be having acceptance problems either in the open source world or beyond.

[edit] McVoy says open-source can't make money

http://www.forbes.com/execpicks/2005/05/26/cz_dl_0526linux.html

(Quote)

"Open source as a business model, in isolation, is pretty much unsustainable," says McVoy, founder and chief executive of BitMover, a San Francisco-based company that makes a software-development tool for Linux called BitKeeper.

...

"We believe if we open sourced our product, we would be out of business in six months," McVoy says. "The bottom line is you have to build a financially sound company with a well-trained staff. And those staffers like their salaries. If everything is free, how can I make enough money to keep building that product for you and supporting you?"

...

Open source products typically are distributed free, since it's pretty much impossible to charge money for something that anyone can copy.

So how do you make money with open source code? Some companies, like Red Hat (nasdaq: RHAT - news - people ), distribute Linux for free and then make money selling service contracts to users.

"One problem with the services model is that it is based on the idea that you are giving customers crap--because if you give them software that works, what is the point of service?" McVoy says. "The other problem is that the services model doesn't generate enough revenue to support the creation of the next generation of innovative products. Red Hat has been around for a long time--for a decade now. Yet try to name one significant thing--one innovative product--that has come out of Red Hat."

...

Torvalds disagrees with McVoy about the sustainability of open source.

"Open source actually builds on a base that works even without any commercial interest [which] is almost always secondary," he says. "The so-called 'big boys' come along only after the project has proven itself to be better than what those same big boys tried to do on their own. So don't fall into the trap of thinking that open source is dependent on the commercial interests. That's nice gravy, but it is gravy."

But McVoy says open source advocates fail to recognize that building new software requires lots of trial and error, which means investing lots of money. Software companies won't make those investments unless they can earn a return by selling programs rather than giving them away.

...

"It costs a huge amount of money to develop a single innovative software product. You have to have a business model that will let you recoup those costs. These arguments are exceedingly unpopular. Everyone wants everything to be free." ...

...

McVoy argues that the open source phenomenon may appear to be sustainable but actually is being propped up by hardware makers who view open source code as a loss leader--something that will entice customers to buy their boxes.

"Nobody wants to admit that most of the money funding open source development, maybe 80% to 90%, is coming from companies that are not open source companies themselves. What happens when these sponsors go away and there is not enough money floating around? Where is innovation going to come from? Is the government going to fund it? This stuff is expensive."

...

McVoy says he believes the software industry will reach some kind of balance between open source and traditional software companies. Open source companies will make commodity knockoffs and eke out tiny profits, while traditional "closed source" companies will develop innovative products and earn fatter profits. (/Quote)

[edit] DHH

InfoWorld: Paul Krill (2007-05-21). Rails creator doubts Silverlight can win converts (http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/07/05/21/hansson-qa_1.html). Retrieved on 2007-05-11 11:18.

InfoWorld: Ruby on Rails is an open-source Web framework, as in you don't sell it. Are you making money from the project just the same through consulting? How do you monetize it?

Hansson: In a lot of ways I don't need to monetize it, I have a job. I work at 37signals, and we make money selling products. But we still in a large sense make money off it primarily through saving money. So we get to collaborate with a lot of other people around the world that then they'll pick up part of the work we would otherwise have to do. So that's the great thing about open source. You get to collaborate, and you get to share contributions and swap. So there's a lot of bartering going on that saves us a ton of development time. But there are also direct influences [in that] we get now a talent pool who know exactly the kind of technology we're working on, so it's much easier for us to hire new people. We've gotten a great amount of press out of it.

[edit] Services you can sell

Best Practical Solutions, LLC: Services (http://bestpractical.com/services/). Retrieved on 2007-05-11 11:18.

Best Practical is the acknowledged leader in providing services to companies who use Jifty, SVK, RT and RT-based products, or who want to use these technologies. As the creators of all of these tools we are (as you might imagine) in a unique position to know best how to customize, install, and support our software.

SVK Product Support

We can keep your developers working smoothly, helping to resolve SVK-related issues and offer practical, professional advice to help with all your version control needs.

RT Product Support

We can keep your RT running smoothly, reacting to incidents with speed and skill.

Custom Development

Need something new out of RT, SVK or Jifty? We can add new features to any of our products, or integrate them with third-party applications.

RT Installation

Want to start using RT? We're there to help get you going.

RT Training

Learn how to get the most out of your RT.

RT Hosting

Get up and running with today. No download, no install.

[edit] [Case study] MySQL=

http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/. Retrieved on 2007-05-11 11:18.

[edit] I’d recommend Enterprise if I could

If the MySQL Enterprise Server were a good thing, I’d recommend it to my consulting clients. I’d suggest we start using it at my employer, too. I believe in supporting people and companies whose work benefits me. Here’s the thing, though: I think it would be detrimental, even dangerous.

Why on earth would I think that?

Because nobody’s testing the Enterprise source code before it’s released.

It’s getting bug fixes that haven’t been stress-tested in the real world. Some of them are even being rolled back, many months later, because they were broken.

[edit] Reasons I’d buy MySQL Enterprise

The reasons I’d buy a MySQL Enterprise subscription would be as follows, in order of importance:

  1. A stable, tested version of the server with well-known, documented limitations and bugs.
  2. Technical support.
  3. The knowledge base, etc, etc.

[edit] But… that’s what Enterprise is, right?

...

These bug fixes address minor problems, but seem to have the potential to cause major damage if there’s a problem with the fix itself. None of these should be included in a hot-fix release. In fact, after looking through the whole list, I don’t see anything I would want to go to my production servers before six months of community testing. There’s simply too much at stake. The upside of including these changes is so small, and the potential downside so large, that it doesn’t make sense to include them.

...

[edit] How would I change the current release policy?

I think this is easiest to explain with diagrams. Here’s the current release policy, as I understand it (I know this is over-simplified, but I’m trying to simplify this enough to show how I’d change it):

[Neat diagrams!]

[1]

...

[2]

Aliases: How do open-source projects make money?