In 2006 I wrote a draft API Change Policy for ITK. The Background section, repeated here, discusses many of the issues raised here. I argued that the time and money our customers invest in our open-source software is not insignificant. We don’t know the extent of our customer base. It’s ironic, that Paraview, a customer of VTK, is being affected by API changes in VTK. My document was not accepted, and many argued that customers should accept progress or stick with a version of the code that does not break the API.
One of the major criticisms of open-source software is that new revisions are not compatible with old revisions. Breaking compatibility impedes the acceptance and utility of open-source software. On the other hand, strict backward compatibility policies can impede innovation in software. The tension between these two viewpoints is not easily resolved.
As projects mature and the customer base grows, backward compatibility becomes more important. Commercial hardware and software products call this customer base, the installed base. Commercial products usually have a known customer base consisting of those who have purchased or licensed the software. Also, commercial systems seldom expose internal AP I’s. Open source projects rarely know the identities of their customers.
And, since the source is open, customers have access to all public and protected classes, methods and data in the code. For open-source software, it is almost impossible to determine how the customer base is using the software.
When a project hits a certain point in its life cycle, the unpleasant issue of
backward compatibility begins to rear its ugly head. All of a sudden the changes introduced in a new release of the software have a dark side to them; they hold hidden possibilities that will break something one of your users depends on.
This is true in both open and closed source projects, but in the open-source
world it seems that the community has spent less time worrying about it than in the closed source world. “Preserving Backward Compatibility,” Garrett Rooney.
The Dark Side of Extreme Programming: The nightly test/build was so effective in empowering programmers to make changes, that API changes occurred too frequently without the necessary buy-in from the user community.
From “Inside Insight,” Bill Lorensen
Some argue that open-source software should be used at your own risk. But even using open-source software requires an investment in time, energy, and funds. Also, the reputation of the development community is at risk.
…consider your user base. If you have only a dozen highly technical users,
jumping through hoops to maintain backward compatibility may be more trouble than it’s worth.
On the other hand, if you have hundreds or thousands of nontechnical users who cannot deal with manual upgrade steps, you need to spend a lot of time worrying about those kinds of issues. Otherwise, the first time you break compatibility, you’ll quickly burn through all the goodwill you built up with your users by providing them with a useful program. It’s remarkable how easily people forget the good things from a program as soon as they encounter the first real problem.
From “Preserving Backward Compatibility,” Garrett Rooney.
These investments are made by customers that include developers, users, and sponsors.
Here is the original proposal.
APIChangePolicy.pdf (44.7 KB)
