[ Software | Consulting | Ramblings ] Without background

Bazaar Source

A business model for making good software

Executive Summary

Bazaar Source is an attempt to codify a new way of promoting open source development of a product while giving the developer exclusive rights to sell the product. After all, if they developed the product, they have a right to distribute it however they want. Hopefully Bazaar Source can be used as a basis for increasing the Linux application space, which while growing, is not growing at a uniform rate. Interesting projects are sprouting up, but Linux versions of dull products are not.

Rationale

In Cathedral and the Bazaar, Eric Raymond described a new way of developing software. Traditional software has been developed in a top down or Cathedral style. Eric recognized a new way of developing software, the bazaar style. In this style, one person or group develops a piece of software. They then release the software to the community with the source code, and allow the community to review, modify and redistribute the software. This merges the user base into part of the developer base. This is the major reason behind the success of the Apache web server and the Linux operating system.

The term Open Source software originates from this idea. By making source code open it allows the user community to modify and improve the software they are using. In the sequel to Cathedral and the Bazaar Homesteading the Noosphere, Raymond describes the culture of the open source community. He assumes that in the open source community there is no material scarcity because the cost of duplicating software is nil. But there is scarcity, it is the scarcity of programmer talent and time.

However it is my belief that a complex software project is not possible unless the employer allows the developer to develop on company time or the developer is of independent means (the few cases where the developer chooses to live in their office and shower in the mens room are not considered). There are very few projects that excite enough interest to develop completely outside of the typical 8-12+ hour day a normal programmer works.

Therefore, it is not usually feasible to manage very large projects this way. Most very large open source projects are funded by a corporation to serve their ends (Re: Perl or Apache funded by O'Rielly, Linux funded by Transmeta, Redhat, VA.). In the 3rd paper in the CatB series, The Magic Cauldron, Raymond describes several reasons a corporation might release software as open source.

Cost-Sharing.
A piece of software is so simple that is makes sense to share the costs of development and maintianance with other companies, even competitors.
Risk Sharing
A piece of software was needed, but it provides little competitive advantage. By opening the code up to the community, others can benefit, and the company benefits from other's changes.
Market Positioner
Release some code as open source to promote other closed source products.
Widget Frosting
If the companies primary business is a scarce resource (like a HW vendor), open source the software to sell more units.
Service industry
If the companies primary revenue is from content or service then releasing the software will improve the service.

For each one of the above, the software is secondary to the companies primary revenue stream. For a software development firm, especially one that specializes in Commercial off the Shelf (COTS) applications, open source licensing can be a problem.

COTS applications are funded from revenue generated by selling copies of the software. Service and accessorizing cannot support the expense of highly trained and skillful craftsman developing software.

Free redistribution poses a problem for generating revenue. A user is more likely to down load the software off the Net than buy a CD, especially if the software package is small. To quote a slashdot user:

"Anyone with half a brain knows you can make money with Open Source. The problem is, you don't make that money by developing open source software. You make it by selling open source software other people wrote....the open-source developers are either an expense or unpaid volunteers."

Looking at the ownership principles laid out in ESR HtN, we see that projects are rarely forked because of social pressures in the community. Only if the owner is negligent or abandons the project will a new owner assume control. The only other way was for the owner to transfer ownership to the new owner.

There exists a solution, and it lies somewhere between open and closed source. To explain it we first need to look at the advantages of the open source's bazaar development model.

Advantages of Bazaar development

ESR described the bazaar model as "a great babbling bazaar of differing agendas and approaches out of which a coherent and stable system could...emerge..."

What are the biggest advantages of the bazaar model:

Peer Review
Ability to customize to suit needs.
Almost limitless talent available.
Debugging is parallelizable (Linus's Law)

Disadvantages:

Every good work of software starts by scratching a developer's personal itch.
Must begin with code.

The Bazaar Source model

If technical merit is more important that freedom, which is a more pragmatic view then the Free Software purists, then we can propose a new development model. Lets call it Bazaar Source.

Bazaar Source exists somewhere between Open and Closed Source, but it isn't as restrictive as Sun's Community Source License. In the Bazaar Source model the user purchases the software as COTS, but along with a license to use the software, the user purchases a license to use the source code. The user is free to modify the code as he/she sees fit. The user is permitted to redistribute the modifications, and only the modifications (usually in the form of a patch), as he/she sees fit. However the sole right to redistribute the base software rests with the person or company that developed it.

This model benefits the developer by permitting them compensation for their work, while at the same time benefitting the consumer by allowing them access to the source code.

It is also possible a symbiotic relationship can develop between the users and the developer. If a user finds and fixes a bug or adds a new feature, the user can give the patch back to the developer. The user benefits by improving the overall package, and the developer benefits by having a large number of eyes looking for bugs or adding features. This will lower the developer's cost to maintain the software thereby lowering the per copy costs to the consumer. It would be good ettiquite for the developer to compensate a user who submits a patch in some form.

Comparison of Bazaar Source and Other licensing models.

Open Source Definition

By visiting the Open Source Definition we can do a point by point comparison between Open and Bazaar Source.

Free Redistribution.
A COTS software package cannot coincide with free redistribution for reasons previously states.
Source Code.
The core of the bazaar development is access to the source code. Bazaar Source software must provide a license to use the source code.
Derived Works.
A Bazaar Source license should allow the author of a modification to redistribute the _source_ of the _modification_ under any license the author chooses, even if the modification cannot be merged back into the main code base. It does not however give the author of the modification the right to re-distribute the original or modified software as a whole.
Integrity of The Author's Source Code.
Because the bazaar source license prohibits redistribution of a modification as a whole, the only way to redistribute a modification is via a patch file.
No Discrimination Against Persons or Groups.
No Discrimination Against Fields of Endeavor.
Discriminating against any customers is bad business practice and should not be an issue in selling bazaar software.
Distribution of License.
Because Bazaar software is sold by the developer to the user, point 7 does not apply.
License Must Not Be Specific to a Product.
The bazaar source license allows any use of the source code of software as the user sees fit, with the exception of redistribution. It is perfectly reasonable to purchase a bazaar source product, to use some code from that product in another program. However by doing so you limit the ability to redistribute the new software.
License Must Not Contaminate Other Software.
A bazaar source license places no restrictions on the other software that may be distributed on the same medium.

A Comparison to the Sun Community Source License.

Bazaar Source is less restrictive then the SCSL:

modifications can be released under any license. The developer has no right to include any published modification in it's release.
modifications can be released to anyone.
Should be project die or be discontinued, the source code will fall under an Open Source License

The SCSL also is more centrally controlled by Sun. With Bazaar Source, development is not centrally controlled and anyone can organize development projects.

Prerequisite for Bazaar Source to work

For bazaar source software to be accepted by the general user community it must:

be software that the community doesn't have the itch to develop.
In CatB ESR explained that most projects were developed to scratch an itch the developers had. There are some projects that are just not interesting. Sales forecasting tools and business accounting programs are much less interesting than network monitoring tools or graphic user environments.
be reasonably priced
If a software package is priced at $100-$300 for say a contact management tool or an office suite, there will be a demand for a lower cost alternative. Most likely an open source version will take come along and price it out of the market. I would propose charging one fifth of what the typical closed source COTS product would cost.
be released often
Releasing often allows community modifications to be incorporated back into the product rapidly. Each of these minor releases should be made available at no cost to the purchasers of the software.
be a fast, reliable product.
Along the lines of reasonably priced, if a package is buggy or slow there will be demand of a fully open source alternative.

And the developer must:

Allow contributions, and give credit where due.
The gift culture of the hacker community is based on reputation and recognition of contributions. As such to take someone else's work without giving credit is the worst sin a developer can do. Anyone who does this would alienate the community so much that they might as well never release their code to begin with.
Provide compensation to contributors
Beyond recognition for their contributions, since the developer is making money off the product it is only fair to compensate them for their contribution.
Contribute back to the community at large.
End user applications are one area where free redistribution can pose a problem, however experience has shown infrastructural software, (webservers, GUI development libraries) can be made open source while still able to generate revenue for the company. Therefore if a company is engaged in bazaar source software sales, it is reasonable to expect them to release infrastructural software under an open source license.
Provide a open source compliant "death clause"
If a project is killed, or the company goes under, there must be a way for the community to get ownership of the software. Otherwise the project would die with the developer. The licensing provision also gives more value to the software in that the user knows the software will continue on after the developer as gone.
Provide the extras: Support and Documentation.
Contrary to the FSF's ideals, there is more free software than there is free documentation. Software development is an art. Technical writing is a profession. There is much more "fun" in producing software then in producing documentation. Hence when the developer sells the software they must include the documentation to provide value. They should also provide the infrastructure to handle support for corporate customers.
Make provisions for customers who make internal modifications to keep those modifications across versions.
When a customer modifies the code for their own internal use, they need some mechanism to maintain those changes across multiple versions.
Mutual Trust
The developer must be trusted by the community to do the "right thing(tm)". Otherwise they would not participate in the community development efforts.

Where to go from here

Bazaar source allows companies to distribute their source code as part of their product while maintaining their ability to charge for their product. It allows open source like contributions to occur, and provides direction in dealing with the community that assists in development. If this idea is generally accepted by a reasonable portion of the Linux (and BSD/BeOS/Windows) user population, this licensing scheme can be used to found successful software companies that can publish their source for the community to use.

Questions or comments should be sent to: Chris Farris chrisf at room17.com