Leading items

On the marketing of free software

Please indulge your editor as he reminisces for a moment. Once upon a time, the cool machines to get in the office were Unix-based workstations, and the offerings from Sun Microsystems in particular. The first thing that would happen to one of these systems once it came out of the box was interesting, however: much of the software on the system would be immediately replaced. The new systems would be loaded down with the GNU toolchain, the X Window System, and various other goodies from all over the net. This pattern was common enough that a small company called Cygnus Solutions made a living from supporting free tools on proprietary Unix systems.

The replacement software was often better, but that was not always the case. There were long periods of time where trying to build early X11 releases with early gcc releases was an exercise in serious pain. But your editor did it, and, judging from the traffic on the mailing lists, quite a few others did it as well.

Many of us might not, at that time, have been able to explain why we subjected ourselves to this experience, even though Richard Stallman had already been trying to do exactly that for a few years by then. But now it's obvious: we wanted our systems to run free software. Loading them down with free code turned them into something more obviously oriented toward our needs, something we could fix if need be (and need often was, back then), and something which, in a palpable way, was more alive.

Free software has obviously come a long way since then, and a far larger group of people is aware of its importance. But it is still a geek phenomenon. For much of the wider community, "free software" still means "you don't have to pay for it," and many people still wonder about what use they, personally, could ever have for the source code. As a result, many users may have learned that Firefox, for example, is a better web browser, but they do not know why. It's just another program they can download and run.

So it is a little sad to see reports that the effort to market Firefox may emphasize features and downplay the fact that it is free software. Evidently the people behind these marketing campaigns have decided that it's features that "sell" the software, so that is what has to be pushed on users. For Firefox 2.0, this strategy might just help to drive usage statistics up a little higher. But in the longer term it does not seem like a winning approach.

The folks at Mozilla Corp. clearly see themselves in a battle with Microsoft and its reinvigorated Internet Explorer product. Firefox was, indeed, able to out-feature Internet Explorer for a while, and that doubtless helped to increase its adoption. But the history of the computing field is full of examples of companies which tried to engage in feature-checkbox battles with Microsoft. One can say many things about that company and its products, but few would accuse Microsoft of being unwilling or unable to add features. It seems unlikely that Mozilla Corp. has the resources to compete with Microsoft on features, and it is not at all clear that the wider development community will be able to make up the difference.

Where Firefox has a competitive advantage, instead, is in the fact that it is free software. This fact should drive what kinds of features are added: those which make the web experience better for Firefox users, with less concern for the comfort of advertisers or publishers. It should bring a higher level of concern for security - an area which can be slighted if the real purpose is to compete on features. It should make the software alive, interesting, evolving with the net, and not subject to stagnation just because the owning company loses interest in it for a while.

It seems unlikely that World Domination will be achieved by trying to out-feature proprietary software companies. Free software is not better by virtue of having more checkboxes on the package. It is better because it is free. If that cannot be made into a selling point, then we may not get much farther than we have until now. There are precedents that suggest that freedom could be made into a selling point; consider, for example, the growing success of organic produce. Like organic food, free software is better for you - and it doesn't even cost more. When people understand why free software is better for them, many of them will insist on it. One can only hope that projects which are sufficiently well-heeled to have marketing efforts will market freedom as one of their most important "features."

Comments (40 posted)

Compiere's Community Relationship Management problem

Compiere does not get as much attention as a number of other free software projects, but maybe it should. It is a full "enterprise resource planning" and "customer relationship management" application, with support for a number of tasks, including marketing and sales, human resources, inventory control, and more. There is also a full business accounting package - an area which has traditionally been under-served by free software. Compiere has slowly grown over time, and ComPiere Inc, the company formed around the software, landed a $6 million chunk of venture capital last June. Larry Augustin has recently become a member of the company's board.

Compiere places a lot of emphasis on its open source nature:

Interestingly, much of that "vibrant, responsive, and knowledgeable" community appears to have decided to pack its bags and head elsewhere. The result is a new project called ADempiere, started last month. It would appear that - in the opinion of the developers behind ADempiere, at least - Compiere has worked on building its business at the expense of its community.

In the most important way, Compiere's community credentials are unimpeachable: it has released a large amount of useful code under a free license. Once one looks beyond that, however, there are some things to wonder about. It is a rare free software project whose installation instructions begin with "install Oracle." There is an active forum area, but the project does not appear to have a functioning mailing list. The Compiere web site talks about "products," but has no area for developers. Compiere may be a free software project, but it is clearly on the cathedral side of the spectrum.

It would appear that, over time, the communications between ComPiere, Inc. and the wider community have fallen off. Developers report frustration in trying to find out what the company is up to, and great difficulties in getting patches accepted - or even discussed. Much of the disconnect, perhaps, is a result of the company reorganizing its operations to absorb the incoming venture capital; the company also recently relocated, which never helps. But a reading of the discussion leading up to the fork suggests that the problems have been growing for some time. To the wider community, Compiere looks increasingly like a proprietary software company which is still trying to claim to be an open source company.

The community is also concerned that ComPiere Inc. may take the system proprietary. In the short term, at least, there does not appear to be a whole lot of evidence that this could happen - though the company does reserve the right to create proprietary offerings:

The same message states that ComPiere, Inc. has no intention of taking Compiere proprietary or trying to cripple it in any way. Even so, some members of the community wonder what will happen once the venture capitalists start insisting on results.

For now, in any case, the damage appears to be done; ADempiere has taken off, and seems to be gaining a fair amount of attention. The developers are busily taking on projects - ports to MySQL and PostgreSQL, for example - that Compiere has never been interested in pursuing. The first development release is available. This fork appears to have enough energy behind it to get off the ground, though only time will tell if it can sustain itself in the long term.

In the free software community, ignoring developers will often lead to a fork like this one. It is one of the freedoms we depend on most heavily; nobody can bring development of a program to a halt as long as there are interested developers willing to do the work. Often, projects forked in this manner come back together once the original organization figures out that it needed its community after all; the gcc/egcs fork is, perhaps, one of the best examples. Perhaps ComPiere, Inc. might want to consider putting some of its venture funding into wooing this community back soon, before things drift too far apart.

Comments (7 posted)

The Apache source header policy

Any free software project which distributes code developed by others has a couple of responsibilities to take care of. It must, of course, be sure that it has the right to distribute that code; the project must also see to the licensing of the finished product. Sometimes it seems that there are as many approaches to this problem as there are projects. Some common policies are:

• Just sort of toss in everything that comes and hope for the best. This can be the preferred approach of small projects in early stages, where there are no corporate lawyers involved.

• Require developers to certify their right to contribute the code, and verify that the code's license is compatible with the project as a whole. Individual parts of the work retain their copyright ownership and licensing. The Linux kernel works this way.

• Require that developers sign copyrights over to the group owning the project, and distribute the work under unified ownership and licensing. The Free Software Foundation, among others, operates in this mode.

The Apache Software Foundation (ASF) has taken a slightly different approach, with some new rules which take effect at the beginning of November. The result is worth a look as yet another example of how this issue can be managed.

Those who contribute to Apache projects are asked to sign an individual contributor license agreement with the project. Under this agreement, contributors retain ownership of their work, and can do anything they want with it. They do, however, hand some rights over to the Foundation:

Note that there is no requirement that the ASF apply any particular sort of license to the contributed work - though the agreement does promise that:

Using this permission, the ASF distributes everything under the Apache License, regardless of what license the contributor might have originally used. The new source header policy is intended to reflect this state of affairs. So, as of November 1, code shipped by the ASF must contain the following header:

No other headers are allowed. Instead, any other information - including any copyright statements - must be moved to a separate file called NOTICE.

The interesting thing here is that people using code from Apache are doing so under a license received directly from the ASF, even though the ASF does not generally own that code. The ASF is making use of a compilation copyright which covers the mixture of contributions into a single project to impose a license on the whole work. Few projects use a collective work copyright in this way.

This arrangement gives the ASF complete control over the licensing of the projects housed under its umbrella. Should there be a version 3.0 of the Apache License in the future, there will be no trouble in moving the code to that license even in the absence of copyright assignments. Since it is the ASF's license which governs the distributed work, the Foundation has all the standing it needs should there be a reason to defend the license in court. The end result should be reasonably pleasing for everybody involved, as long as the original contributors have no objections to the Apache License - a condition one would expect to hold given that the code has been contributed in the first place.

Comments (9 posted)

Page editor: Jonathan Corbet
Next page: Security>>