Where community and commerce meet

Free software development projects and for-profit companies can often interact in ways which are rewarding for both. The interaction between the two is not always entirely smooth, however, and occasional frictions can emerge. Resolving these issues as they come up can yield insights about how the free software community operates, and how it interacts with the commercial world.

As an example, consider this note posted by Bruce Momjian to a couple of PostgreSQL mailing lists. Interesting things are happening with free database management systems, and various companies are beginning to take note. Bruce welcomes commercial attention, but worries about some problems which could result if things are not handled carefully.

The main issue would appear to be companies working on features for PostgreSQL without first discussing their proposed changes with the community. These companies risk finding that they have duplicated another company's work; merging overlapping patches then puts a stress on both companies - and on the community. Companies which keep their patches until a late stage may also find that the community is unwilling to merge the finished product for any of a number of reasons.

This kind of problem can usually be dealt with relatively easily if it is caught in an early stage. By the time a large amount of effort has been expended, changing the direction of a project can be a harder task. For this reason, many development communities would like to see proposed additions as early in the process as possible. This desire often clashes with a company's goals: the company knows what sort of patch it wants to produce, and corporate management is often afraid to release code which has not been polished, run through a quality assurance process, and cleared by the lawyers. Releasing early-stage code with missing features and known problems so that the community can redirect the development process is just not the pointy-haired way of doing things.

When a company owns a given free software project (think MySQL, OpenOffice.org, or JBoss), there is usually a certain level of predictability in its development process. The controlling company has its agenda, and will accept or reject patches based on whether the patches further that agenda. Many or most of the major developments are centrally planned from the outset. If another company wishes to encourage development in a certain direction, managers from both sides can get together and work a deal. Managers tend to like to work that way.

A more community-driven project can be harder for companies to engage with. Promises to merge a given feature are hard to obtain and even harder to enforce. The whole process can seem whimsical and hostile to corporate five-year plans. But this is also the process which, at its best, produces high-quality code which is maintainable over the long term. Companies can learn to work with - and appreciate - the community development process, but there is a learning process involved. It all tends to work out with successful projects, but each project seems to have to find its own way to work with the commercial world.

The other problem mentioned by Mr. Momjian is that companies are hiring PostgreSQL developers to work on closed-source extensions. This is OK in general: PostgreSQL carries a BSD license, and it is hard to argue with jobs for PostgreSQL hackers. But the project needs developers to survive; companies which hire those developers and prevent them from working on the core system risk killing their golden goose. Bruce asks that such companies at least allow their developers to spend some of their time working on the free PostgreSQL core.

The interface between corporations and free software development projects has its share of traps and potential problems, just like any other relationship. Given time and sufficient will, these problems can be worked out. It is worth the trouble: each side has a lot which it can offer to the other.

---

(Log in to post comments)