Business vs. FOSS: Six Pressure Points

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

The question of whether business can co-exist with free and open source software (FOSS) was settled long ago. It can, and not only successful companies like Red Hat but also the willingness of venture capitalists to fund FOSS business models proves the case.

However, the very term “FOSS business” reminds us that it is not the norm. Instead, FOSS business remains a hybrid or an alliance of interests whose values and interests can conflict as often as they overlap. To function effectively in FOSS business, you need to be aware of these potential areas of conflict so that you can avoid or minimize them in both hiring and interactions with the FOSS community.

Based on my experience and observations, here are six areas where business and FOSS sometimes rub each other the wrong way:

1) Hierarchy vs. Meritocracy
2) Profits vs. Excellence or Freedom
3) Gatekeepers vs. Openness
4) Scheduled vs. Open-Ended Releases
5) Proprietary vs. Free Licenses
6) Strategy vs. Way of Life
Conclusion
RELATED NEWS AND ANALYSIS

1) Hierarchy vs. Meritocracy

Business in general and high-tech in particular, has a much flatter structure today than it had a couple of decades ago. All the same, between titles and the power to make decisions, few people in an office environment have any doubt where they stand in relation to other people in the same company.

But in FOSS projects, the ideal is a meritocracy, in which people are judged by the work they have done, particularly recently. Nor is the practice much different from the theory. While most projects have a titular head, the style of leadership tends to be hands-on, with those in authority first among equals. Look at the Linux kernel mailing list, and you will see that even a celebrity like Linus Torvalds is argued and questioned, even in his areas of expertise.

These different operating styles mean that both business executives and FOSS need to modify their expectations to work together. Executives cannot expect automatic respect, while those from FOSS backgrounds need to recognize that, in a business context, their normal interaction may come across to some people as rude and insulting.

2) Profits vs. Excellence or Freedom

Being successful in business means turning a profit, yearly and quarter after quarter. By contrast, FOSS is about software quality (if you are from the open source camp) or software freedom (if you are from the free software side).

Like having an environmental plan or a strategy for charity, supporting excellence or freedom may be desirable parts of any business plan. However, focusing on excellence can mean that you miss a shipping schedule, and focusing on freedom may sometimes seem irrelevant compared to meeting a deadline. The business-oriented need to remember that emphasizing profitability at the expense of everything else may reinforce the mistrust of commerce that runs through the FOSS community, while those with a FOSS perspective should be aware that their values can undermine the whole point of a company if insisted upon to the exclusion of business goals.

3) Gatekeepers vs. Openness

Both internally and externally, the passing of information in companies tends to be controlled by gatekeepers. Usually executives and marketers, gatekeepers control what information is passed along, and who receives it.

This model is the exact opposite of the tradition of openness in FOSS projects. In the Debian project, for instance, not only the source code but policy debate and even decisions tend to be discussed publicly — an idea that is likely to strike the average MBA as contrary to common sense.

Of course, the social web has introduced more openness into many businesses, while in practice FOSS projects like Debian have always had private politicking behind the public discussions. However, these facts don’t mean that debates over the ideals won’t arise in FOSS-based businesses. Managers are apt to be surprised how often company information is discussed when developers deal with the community, while developers may feel that uptight managers are preventing them from interacting with the community properly. Guidelines may help defuse such clashes, but too strict or obvious a policy may also be poor public relations for a company trying to be a good citizen of the community.

4) Scheduled vs. Open-Ended Releases

Companies need to schedule their products in order to plan and to release them at the proper time. That is why community distributions associated with a company, such as Red Hat’s Fedora or Novell’s openSUSE have moved to regular release schedules; the commercial distributions based on the community ones need to know when the code base is ready.

Similarly, to ensure that the latest code is shipped, Mark Shuttleworth of Canonical and Ubuntu has been trying (so far, without much success) to interest major projects in coordinating their releases. Both these tendencies are examples of applying business norms to FOSS production.

But the values of FOSS’s volunteer-based past still linger, even in these days when many major contributors to projects are employed by corporations. Not having to worry about marketing, sales, and shipping, many FOSS projects have a more relaxed attitude towards schedules. Project members would rather have the software good than have it Friday.

In some cases I’ve seen, it was next to impossible to create any sense of urgency about deadlines in people from the community. That may not be a bad thing if it reduces the number of shipped bugs, but the need for compromise on both sides is obvious.

5) Proprietary vs. Free Licenses

Protecting so-called intellectual property is deeply ingrained in the average business school graduate. From this perspective, the idea of giving it away, even in exchange for sharing other organizations’ work or receiving contributions from non-employees, can be hard to accept. At the very least, the urge to minimize what you give away can be almost irresistible.

On the FOSS side, the value of sharing technical information is usually a given. The belief is that, as with academic freedom, the exchange of ideas benefits everyone.

The point is not which view is right, so much as the fact a clash exists. Fortunately, well-recognized strategies exist to create a compromise. The most common is the use of the GNU Lesser General Public License, which makes dual licensing easy. A company can release a free software version of a product under the LGPL, and use a more restrictive license for a proprietary version of the same product, as Sun Microsystems does with OpenOffice.org and StarOffice. Purists on each side may complain about the extra work involved in such strategies, but what matters is that they are well-established.

6) Strategy vs. Way of Life

Probably the most sensitive difference between business and FOSS values is the reason for using FOSS in the first place.

To someone steeped in business values, using FOSS is a strategy. It allows a company to ramp up quickly and start making money, and can be a way of creating ties with many large technology companies, such as Hewlett-Packard and IBM. However, if FOSS stops being useful for any reason, then it should be discarded like last year’s advertising campaign. In fact, discarding FOSS policies can be difficult, especially if you have used the wrong license, but what matters is that, for many in business, support for FOSS is provisional.

Nothing could be more different from the typical community perspective. For most people in the community, FOSS is not simply a useful strategy, but a community where they have found respect and even fame. Working in FOSS gives them a sense of direction, a chance to put ideals into practice, and to identify with something larger than themselves. It is definitely not something to abandon lightly, and some wouldn’t abandon it at all.

Whether these differences can be reconciled seems doubtful — or, at least, I have never seen a way. All that can really be said is that these differences, more than any others, reinforce my contention that FOSS and business have an alliance. And in alliances, despite some common goals, the parties involved have different motivations. Business executives need to bear in mind that the use of FOSS means more to those involved than it does to them, while FOSS supporters should never forget that business use of FOSS is always provisional.

Conclusion

Business and FOSS are not always so opposed as I’ve suggested here. In at least one area, their interests overlap almost perfectly — the creation of new products. Expanding businesses are always looking for something new to sell, while FOSS is the great proof of Eric von Hippel’s — and Eric Raymond’s — contention that innovation usually comes from individuals trying to fulfill their personal needs.

Nor should anyone forget that, despite the legal fiction, businesses are not people. Rather, they consist of people, and these people’s goals and interests do not always coincide exactly with what conventional wisdom suggests is best for the company. Ego, ideals, enthusiasm, and curiosity may all encourage other choices. It is usually a few individuals who introduce FOSS into a company or who plan a FOSS-based company, and personal relationships can do much to bridge the potential divides suggested here — or to widen them. In the end, it can be as simple — and as complicated — as that.