To say one could see a train wreck coming from hundreds of miles away when the Linux kernel development process switched to using BitKeeper to manage development is to make an understatement of the largest kind. The idea that the best known Free Software kernel would be developed with the aid of a non-Free development tool just seemed peculiar at best and dangerous at worst. OfB's Timothy R. Butler asserts that the moral of this story is one that every business ought to pay attention to.
Now, there is nothing worse than someone coming out after something bad happens and yelling, “see, I told you so.” But, at the same time, the community ought to deeply consider what has happened here so that it can be avoided in the future. Like many observers, I suspected that BitMover would eventually end its support of the free version of BitMover, or, at the very least, change its licensing so that it would become less tolerable for users.
The problem is simple. If you tie your development to the whims of a proprietary product, you are at the mercy of the developer of that product. While BitMover appears to be trying to ease the transition away from its software now that it has discontinued the free (as in cost) version, it still leaves the kernel developers in a difficult jam, as they must find something new to replace it with after growing use to the way BitKeeper works. That is bad enough, but imagine what would happen had the company not even decided to help provide a semi-smooth transitioning process — certainly, they did not have to, and, in many cases, the development company may not have.
Does this mean that we ought to stay away from proprietary software completely? I am not suggesting that, although it is hard to argue that as being a bad idea, presuming you can find Free Software that does the job you need. Since Free and Open Source Software guarantees key freedoms, a problem like this cannot happen. Yet my main point is more specific: placing proprietary software at the center of your company's software development process is a fundamentally bad business strategy.
One needs to only look over to Microsoft to see another example of the rapidly rising problems of proprietary development tools in the form of Visual Basic. As observers of the industry will surely recall, there has been a vocal set of developers who are very unhappy about the discontinuation of Visual Basic 6, since its successor, Visual Basic.net, is a fundamentally different language. This is a quandary that can only occur on a proprietary platform. If VB6 was released as Free Software, these unhappy developers could continue to enhance Visual Basic 6 so that it would work with future changes to the OS, but, of course, that is not an option in the world of proprietary software.
But even insisting on a completely FOSS development platform is not necessary. What should be insisted on is one that uses completely Free/open standards. Part of what led BitMover to abandon the free-as-in-cost version of BitKeeper were the various attempts to create Free Software tools that could be used to work with it (the ethical and legal ramifications of these attempts are beyond the scope of this piece). Why did this bother BitMover so much? It is for a simple reason: it is in BitMover's interest to keep both the client and server under their control. On the other hand, had BitKeeper been based on open standards, it would have been hard to object to attempts to work with those standards, and the dangers of working with a proprietary product would have been alleviated since any decision to discontinue the product would not be the end of the line. Likewise, had Visual Basic 6 been a standards-based language, Microsoft's discontinuation of it would merely force people to adapt to someone else's implementation of the standard rather than a totally new RAD tool.
The moral of the story is that glitzy proprietary products may promise faster development results. I will not quibble with that claim either. However, one must decide how wise it is to be completely bound to another company that has the power to quit developing the product upon which your product, and in many cases, your livelihood depend. Wise developers will make open standards the bare minimum for an acceptable tool, and a completely Free Software solution the preferred scenario.