The Server Side broke the news a few days ago that SpringSource is changing their maintenance policy for the Spring Framework source code. In essence, they’ll no longer make public patch releases of the Spring framework modules more than three months after a major release.
Customers who are using SpringSource Enterprise, available under a subscription, will receive maintenance releases for three years from the general availability of a major new version. These customers receive ongoing, rapid patches as well as regular maintenance releases to address bugs, security vulnerabilities and usability issues, making SpringSource Enterprise the best option for production systems.
After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. Subsequent maintenance releases will be available to SpringSource Enterprise customers. Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software.
Charles has written a good analysis of this change of attitude:
The language changes, often around the time the outside investors show up. The people who are downloading and using your software are no longer your community, they’re the ones who are taking your code without giving anything back. They’re the free-loaders.
The attitude of commercial software firms is always going to be at odds with what is best for an open source community to flourish around software. A software company tracks every piece of work done on open source software against their bottom line. “Should we implement this bug fix? It depends — how much will people pay for it?” It’s really hard to come up with a business model which also allows people to use the software freely at the same time as turning a profit, so instead the freedom of the software suffers.
So what’s the solution? How can a company sponsor open source without appearing to restrict work on the open source project to promote their commercial offerings?
One of the best ways is to set up an organisation which is separate to the company and responsible for the open source project. This organisation can be sponsored for a fixed amount by the company (or perhaps set up as a foundation), and is managed independently of the company.
In this model, the open source organisation has complete autonomy and owns the copyright for the code. Its goals are to enhance and promote the use of its code throughout the world. Many of the most successful open source organisations are set up as foundations in this way: Apache, Mozilla, Eclipse.
This avoids nasty situations like we have here. SpringSource, the company, could never decide that Spring, the open source project, should not publish patch releases to help the profitability of the company. Rather, SpringSource is just the company you go to for Spring expertise, because they have a great reputation and have most of the Spring committers on staff.
I read this on the Java server side portal the other day, it was interesting to see the community reaction to it.
In saying so, the new maintenance policy isnt too bad for big companies. We have a couple of apps running in Spring, and the problem we have is that we cant upgrade Spring as frequently as we would like to (due to process/business priorities etc…), so I would presume at some stage, our version of Symfony will become outdated, and we will need to seek support from SpringSource.
Agree with your model suggestion as well, we currently just embarked on using the ‘Opensource’ PHP Symfony framework (which is developed by SensioLabs), and are wondering if they will have to do the same thing as SpringSource did, once their user base and support demands get quite large….
Interesting discussion…
Comments on this article have been closed.