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.
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.
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 years 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.
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.