An opinion on SpringSource’s new maintenance policy 

Introduction

On September 17, 2008 SpringSource announced a new Maintenance Policy regarding its software offerings, particularly its primary product (the Spring Framework) both in its open source and Enterprise editions. The new policy reads as follows:

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.

What does the new policy mean?

So what does this new policy mean for developers and projects that rely on the Spring Framework? Well, it depends a lot on who you are and what your circumstances are.

For starters, it is important to note that this new policy does not mean that Spring Framework has suddenly ceased being an open source project. It is still open source software, published under the Apache License (version 2.0) and available for download by anybody (from the CVS repository). It will also remain possible to submit patches, build your own release, et cetera.

The changes brought about by the new policy, in practice, will only affect how prepackaged spring jars will be released by SpringSource. SpringSource will continue to release prepackaged jars of new major and minor versions (spring-project-x.0.0 and spring-project-x.y.0). In addition, SpringSource will provide prepackaged jars with bugfixes on those released versions for three months after the version is released. After that the new bugfix jars will only be available to people with an Enterprise license. Other people will have to check out bugfixes from the trunk and rebuild themselves, patch their existing libraries with patches from the trunk as needed or wait for the next major/minor release.

For most people the new situation will not make that much difference — most open source developers can simply rebuild or wait. The biggest pinch will probably be felt by commercial projects with restrictive corporate policies on upgrading libraries. Those projects will have to push their business customers to purchase Enterprise licenses if they need access to frequent bugfixes releases.

Is this fair?

The next major question is: is this new policy in any way fair? Is it not a gross violation of open source principles? Should open source software not be free?

Well, the first thing to remember here is the old adage about free software as formulated in the GNU’s Free Software Definition: the “free” in free software means free as in free speech, not free as in free beer. There is nothing in the open source philosophy, nor in practically any open source license that forbids charging money for software — as long as you make the source code freely available. Open source or free software is not a contradiction of any business model except the “trade secret” model. Making money off of software, related services (like prepackaging) or licensing models is absolutely allowed. If it wasn’t, open source would not have caught on. Can you imagine a Linux distribution like OpenSuSE evolving in a situation where you cannot charge for the software at all?

Another point that SpringSource raises (and it is a very valid one) is that they put a lot of effort into those bugfixes. The first three months of fixes always address stability issues (and those will remain available to the general public) but after that the problems noticed pretty much always move into the area of non-critical but still annoying issues. That’s not exclusive to Spring by the way, pretty much every project has a similar pattern with a different timeframe. Most projects (open source and commercial) address these issues by incorporating fixes into the new development version, with a patch of some sort for issues that are particularly bad. SpringSource has always done that as well, but has also “backported” bugfixes into intermediate bugfix releases while having a relatively wide spacing between major releases. That policy is taking more and more effort as more people use the framework (so SpringSource feels) and is also taking up a lot of resources that SpringSource wants to commit to other parts of their portfolio. So they have decided to stop the “backporting” for free and become a more “normal” OSS project with respect to bugfixes for the OSS community.

That aside, all open source licensing (like any other licensing) is a matter of intellectual property rights (specifically copyright). So even if the license on the Spring Framework had made it mandatorily free, SpringSource could at any time have chosen a different license and we’d be in the same position.

So, all in all, no, it is not unfair.

So why does it feel wrong?

And that’s just the problem here, isn’t it? Even though SpringSource is technically in the right at every turn, the new policy just feels wrong. Why? Probably because it feels like SpringSource is taking something away from the community. It feels like we had something for free and now we have to pay for it (even if we didn’t make frequent use of the free thingy when it was free and even though we can still get the free thingy with a little more effort). In other words, SpringSource has created itself a little public relations problem.

So is that bad? Possibly. Not in the sense that it will kill the Framework (Spring has a lot of traction and I have yet to see a framework that combines the three staples of Spring as well). But it will make people start looking at SpringSource in a different light and possibly look a little harder at alternatives to the SpringSource offerings. After all, SpringSource is no longer the Unlimited Fount of All That Is Good — SpringSource now has a nasty, commercial side that wants to make money and is not afraid to shortchange the community to do it (or at least, so it will now seem to quite a few people).

Where I think SpringSource went wrong with their new policy is in the area of presenting themselves as a trustworthy group of people. Let me explain: the open source community has a large problem with confidence when it comes to acceptance by traditionally commercial software developers. Commercial softwarehouses worked for decades in the classical model of secrecy, escrow, copyright and “what belongs to me is mine and keep your filthy paws off”. The idea that you gain more through openness and contribution, despite centuries worth of experience in science, is relatively new to software development outside the universities. The Internet, primary vehicle of OSS development, only started becoming popular in 1995, thirteen years ago. And OSS as a term is even younger. Most commercial entities are still getting to grips with the notion. A large part of such a change is trust and trust like that takes time to build. And when big players like SpringSource start doing things like this new licensing policy, it doesn’t help the trust along at all.

Let me give you another example of where a well-intentioned project went off the track due to mishandling the way people viewed it: the GNU General Public License. The GPL was a mainstay of the open source community for years in version 1.0 and 2.0. Pretty much every OSS and FOSS project adopted the GPL because it embodied the essence of OSS. Then came GPLv3 (around the time that OSS started getting general attention) and that… Well, “flopped” is probably too strong. But it was not an enormous success. So why is this? Is it because of digital rights management or because GPLv3 makes it mandatory to give away all your software for free and kill Bill Gates? I personally don’t think so. I personally think that GPLv3’s biggest problem is one Richard M. Stallman, who has a nasty habit of going around and claiming that everything that has ever remotely been near any open source software must now be open source (even if it plainly isn’t) and screaming everything that commercial software developers really don’t want to hear. Public presentation and public relations, in other words.

What to make of this… except a bonfire?

So, to recap: SpringSource is technically in the right, but I think they may have lightly shot themselves in the foot with this one. What kind of damage are they looking at? For starters, I think they may have made the battle for corporate acceptance a little more uphill than it was. Worse, I think they’ve lost themselves a lot of community respect — not by actually being bad, but by being ham-handed in their approach. At worst they may have opened the door for some community members to start looking elsewhere.

Ironically, of course, that presents an opportunity of sorts for SpringSource as well. Over the past year and a half Spring has become sort of a de facto standard for enterprise Java development. And being a standard can be dangerous, since it can lull you to sleep. If SpringSource has now accidentally created a chance for its rivals, that means SpringSource may soon have to compete on pure quality again. And what better way to earn (back) your OSS credentials than that?

When good guys start looking like bullies….
Tagged on:                 

3 thoughts on “When good guys start looking like bullies….

  • Pingback:Oh Spring Source - where are thou! « Huima

  • September 24, 2008 at 9:26 am
    Permalink

    Rod,

    Thanks for the compliment. And here’s hoping SpringSource never does lose that edge.

  • September 24, 2008 at 12:51 am
    Permalink

    Ben

    Interesting, thoughtful post. We’ve always aspired to “compete on pure quality,” and we’re very comfortable with a world in which we do so–while making an enormous contribution to open source.

    Rgds
    Rod

Comments are closed.