SpringSource, the newest LH partner, is the force behind the Spring framework. They’ve recently announced that they’re only making the first three months of bug fixes available for each new release. After that, they’re charging for bug fixes. This, of course, caused immediate outrage. But what does this mean?
The Spring framework is open source. It’s developed in the open, with an openly available source code repository. Does SpringSource plan on hiding bug fixes after the first three months. No, they’ll be visible and available through the public repository. Does SpringSource plan on making it difficult to build your own packages after three months? No, the build process is simple and well documented. Then, what, exactly are they limiting? That’s not clear, at least from their announcement. What they seem to be saying is this:
- You buy an Enterprise Maintenance contract for version 3.0
- SpringSource releases publicly available bug fixes complete with binaries for three months after 3.0 comes out
- In the meantime SpringSource is developing version 3.1
- After three months SpringSource stops releasing minor bug fixes for 3.0 as binaries
- The bug fixes are still visible on the 3.1 development branch
- Here’s where it’s not clear, it seems that the bug fixes will no longer be visible on the 3.0 branch, in other words, they won’t be publicly backported from 3.1 to 3.0
This enterprise contract provides the purchaser with backported bug fixes to their chosen version for up to three years.
The usual “bug fix” path for open source projects is to recommend that the reporter move to the latest version. This is often unacceptable for commercial users, who have certified specific versions and wish to only make planned upgrades. For those customers an enterprise maintenance contract lets them do that. This will also be a useful path for software product companies who wish to incorporate specific versions of Spring into their products. SpringSource is charging for the service open source developers least want to provide and that bleeding-edge open source development projects least care about.