Links-CommericalOpenSourceSoftware

Feb 19 2009: added MoinMoin bounties.
Note from Nov 25 2008: Apparently, making a living from Open Source is a big subject whose time has arrived, if the number of hits on this page is any indication. This section will grow and may split in the coming months.

• Nov 29 2008: Added Got Customers ?, etc.
  
• Nov 25 2008: Added Thoughts on crowdfunding for open source development
• Nov 22 2008: Jogn Andrews comments.

The development of Open Source applications for commercial enterprises is becoming a hot topic. Perhaps very soon, the day will arrive when companies will see open source as a protection rather than a challenge to the control and outright ownership of their business-critical applications.

It is important to note that my definition of the term "open source" includes open licensing as well, in the sense of Free and Open Source Software as maintained by the FOSS organization. The right to use, modify and redistribute software is essential to the definition of open source / open licensing, despite recent efforts to weaken the definition and limit redistribution rights.

While redistribution is important for maintaining a balance between the interests of developers and users of open source/licensed software, it may be even more important for maintaining equity between developers in a collaborative environment, where the effort put into building a product is being donated with the understanding that it will not be commercialized for the benefit of a few people rather than the community as a whole.

Perhaps the single best compilation of information and advice availible on the web is Karl Fogel's on-line book Producing Open Source Software, a guide to running successful Free Software projects. He makes some great obeservations. One key observation:

Your developers should strive to appear in the project's public forums as individual participants, rather than as a monolithic corporate presence. This is not because there is some negative connotation inherent in monolithic corporate presences (well, perhaps there is, but that's not what this book is about). Rather, it's because individuals are the only sort of entity open source projects are structurally equipped to deal with. An individual contributor can have discussions, submit patches, acquire credibility, vote, and so forth. A company cannot.

The implications of this are two edged. An open source project has community values and a humanistic presense, is capable of creative excellence, etc. On the other hand, a corproation is capable of making a decision without extensive discussion/votes/etc., and allocating resources according to overall business priorities quickly and effectively, rather than the priorities of many individuals. There are also positive connotations inherent in a ( more or less ) monolithic and hierarchical corporate presence, most of all to paying commerical customers.

Switching to the GPL/Commercial License

An interesting article about the profits and perils of switching from a dual LGPL/commercial license model to a dual GPL/commercial license model. Good public relations is not a "nice to have" in the commercial GPL world - community acceptance is essential to the success of commercialized GPL products. Frequently, "commercialization" boils down to preferential distribution of new software for a fee, which runs directly against the principle of open distribution at the core of GPL.

The transition can be very difficult. This particularly true because the standard marketing blather does not go down well with many people. There is a Open Source vision that few corporate-oriented marketers seem to understand. Too often, the vision is to "get them down a dark alleyway and mug'em". Resentment can be especially strong for people who feel they are being demoted from the role of active participants to passive customers ( the analogy of shearing sheep is not uncommon ).

Transition to commercial software can also be difficult for other reasons.

Got Customers ?

Sometimes the software developers don't really understand what it means to have customers. They assume that their new customer base will be the same as the original Open Source community except the developer will make some money out of it for a change. WRONG ! Customers are very different from a community of GPL downloaders/hackers. Customers demand the features and support that a GPL community is grateful to have at all ( although I've seen individuals be very demanding and "act out" in open source forums ). Patience and people skills are all-important.

Got Donations ?

Unfortunately, the gratitude of GPL community members does not often result in action, or not often enough, least of all in money donations. Frequently, one gets the impression that pleas for donations are half-hearted or certainly not strong enough. Developers may be feel awkward about making pleas of this sort - it goes against their grain to beg for anything. They may feel ( and I would agree with them ) that they have earned their reward and have a right to expect something in return.

The problem is that the world doesn't work that way: inertia rules unless there is a crisis of sort. So make a crisis. "We're at the end of our rope but you can make a difference by acting now !" Make the donation button blink bright red.

Got a Plan ?

Some of the difficulties arise form getting into business without a business plan. This is a big subject, well beyond the scope of Open Source. It's important to have a sense of the future and objectives and be able to convey the plan for the future to potential customers. They aren't just buying into code base, they are buying into you and the future of your product and the process driving it.

[ More to follow in coming weeks ]

Thoughts on Crowdfunding for Open Source Development

Feb 19 2009: added MoinMoin bounties.

One possibility for generating income for Open Source developers might be something like crowd-funding. Instead of giving away product enhancements based on feature requests picked up in forums or wherever, people interested in a feature could contribute to a fund to implement that feature.

A some point, a software developer would decide it was worth the effort to win the ... what, maybe $100-$200 offered to implement the new feature, subject to review and acceptance based on pre-determined criteria ( a spec ) - almost like an auction. The code would then be rolled into the next version for release to the public. Of course, the contributors names would be immortalized for making their ( tax-deductible ? ) donation.

As I understand it, the new features would need to be available to everyone by the terms of the GPL license.

There are significant details to be worked out. Perhaps the developer would propose the new feature and then people would contribute based on that proposal. I think that an acceptance step and expressions of satisfaction by the contributors would be critical to the continued success of the process, sort of like vendor evaluations on eBay.

To some extent, crowdfunding is already being done by developers of independent software products ( they are producing their own specific product ), but it doesn't not seem to be done within the context of an existing project as a normal part of the development process.

A fairly plausible example of how this type of funding might work like is provided by MoinMoin bounties ... or that is to say, a single bounty dated April 2006 . It's interesting to see the the list of steps to be taken after the bounty is ( hypothetically ) accepted.

From the site:

At some time, one or multiple people will like to take a bounty .

• They will discuss with moin development core team how to proceed best for starting implementation.
  • If the task is implemented as a plugin, this is mainly to talk about how it is done best.
  • For the case the task needs changes to core code, it is mainly to discuss if this is needed and wanted.
• The contacts person of the contracting group (mostly a subgroup of the core team) will contact the funders and invite them for paying some initial rate (50%). He/She will clarify outstandings issues at this point.
• The feature will be implemented and after it is done, the final rate will be demanded (50%).
• The resulting code should be based on current code and must be publicly released under the GPL after funds are transferred.
• If not all funders want/can pay the initial rate, the whole bounty will be rolled back including the transfer of money if necessary.

There don't seem to have been any takers so far. It may be that most bounties are being converted into requests to the development team for feature enhancements. The ratio of feature requests to bounties is about 250 to 1. Not encouraging perhaps, but it shows an awareness of alternative methods for cooperative funding.

Tags:   Open   Source   Initiative