Thursday, March 02, 2006

The fights are public

One of the differences of open source software is that is frequently ignored or missed is that disagreements, like the code are public.

In a typical company many of the same disagreements occur between principals but it's never seen. The open nature of free software means that every almost always airs their laundry in public.

Let's face it engineers often have strong opinions of certain things. Typically they will express their opinions straightforwardly. This can sometimes lead to conflict.

For example Richard Stallman is a man with a strong set of opinions. While I don't always agree with his approach (I agree with many of his ideas) he is certainly a figure who often finds himself in one spat or another with a another member of the free software movement. For example his current disagreement with Linus Torvalds over licensing the kernal under GPL3 is just another in series of what is relatively small disagreements in the free software movement.

Since these spats occur over publically available mailing lists, they are much more visible than the debates that occur at Sun Microsystems, Microsoft or Oracle. These debates occur at these companies - we just never see them.

As result the free software movement seems more contentious and argumentative. While this seems like a straight forward result of the free software community, peopleoften assume that these same debates don't occur at closed source software companies.

Many of debates occur at closed source companies (direction, engineering approachs, code styles, source management all are debated pretty vociferiously) including one that is noticabily absent from the free software community.

One debate that you will not see is the tension between marketing and engineering. As many free software users are also users of their product - they often have a better understanding of their product. Additionally developers are also often the sales staff. Most free software projects are still small enough that they are intimately connected to their users in ways that developers at private source companies are not.

Microsoft for example has developed procedures for project managers and other customer relation people to be actively soliciting feedback from users. This process developed because it was no longer feasible for developers to do this. Scale has it's problems.

However one point of contact with customers is often the sales/marketing rep. One problem that often arises is the promised feature. Rep A promises Customer B that Feature X is definately going to be in Release C. This leads to marketing making demands on engineering that they may not be able to make. This then often leads Creeping Featuritis which then leads to Security Holeis.

This of course can happen any time you deploy a sales force that doesn't have a sound technical knowledge. Since most free software projects haven't gotten to this size and most will never get to this size so it's not a problem you face in the free software community too often.

Of course the relatively small size of developer teams and their relative closeness to the customer means that you can often work with directly with an engineer on a project.

Chock one up for free software. When I started this post, I noticed a great piece on
project management principles
, that not only talks about project management but also some of the strange foibles of corporate software development.