Suis-je Groovy? No! What Pivotal’s Decision Means for Open Source Software

Today there was great news in the JVM ecosystem.

Pivotal, the company who is committed to OSS has become a bit less committed:


The reaction in the community were largely summarised by the hashtag #jesuisgroovy:

The interesting part in Pivotal’s announcement is this one:

The decision to conclude its sponsorship of Groovy and Grails is part of Pivotal’s larger strategy to concentrate resources on accelerating both commercial and open source projects that support its growing traction in Platform-as-a-Service, Data, and Agile development. Pivotal has determined that the time is right to let further development of Groovy and Grails be led by other interested parties in the open source community who can best serve the goals of those projects.

The official announcement can be read here.

Groovy is not a viable business (for Pivotal)

In other words, Groovy is not a viable business for Pivotal. And it’s hard to disagree here. Groovy has never been created with any commercial interests. Like many Open Source projects, Groovy was created in order to make something “better”, mostly for the sake of it being better. Of course it was useful as it introduced a lot of nice features into the Java ecosystem at a time before all these new JVM languages popped up. And before all these new JVM languages finally had an effect on Java-the-language itself.

On the other hand, the Groovy website’s rather geeky look-and-feel has never made it seem as though virtually anyone had any commercial interests in the language or the platform for that matter. I’m not trying to be harsh here, Groovy is an awesome language, created with love. But maintaining an Open Source ecosystem is hard work. It costs a lot of money and effort. And in the case of Groovy, it is just very hard to disagree with the fact that there is probably little money to be made out of it.

How to make money out of Open Source

When we moved on from a purely Open Source jOOQ to a dual-licensed one, we were criticised a lot by people who realised that they might fall into the dual-licensing category who no longer gets to ride for free. This was of course a disappointing evolution for those people. We see it as one step forward for a product that doesn’t just want to implement l’art pour l’art. We believe that we’re adding value on a small scale to a select set of customers with real SQL problems, and we want to continue to do so. Thus, commercial interests are now the driving force behind our developments, and dual-licensing is the easiest way to achieve that on our own small scale.

Many of those who had criticised us claimed that we should create a support-based Open Source business model instead (like Pivotal!). In other words: Let “them” pay for support – whoever “they” are. But that is not a viable model in the long run.

We create fishing poles. We don’t want to compete with our customers, the fishermen.

In software, the vendor of some product shouldn’t commoditize the main driver for innovation: The product. They should sell the product and create an ecosystem and a market for consultants that will be much better at applying the product to some concrete customer’s business. It is a win-win-win situation for everyone:

  • Vendors get money from licenses
  • Consultants get money from their specialist knowledge
  • End-users get a better, cheaper solution with a lower cost of ownership

Although, the consultant is always the one whose work is commoditized in the long run as demand for the product increases, and more consultants pop up trying to make money from their consulting business.

Joel Spolsky has written an extremely interesting Strategy Letter on the idea of commoditizing a complementary product (support, in this case) to increase the demand for the primary product (license, in this case). In the case of a PaaS company like Pivotal, however, we can only guess that even the commoditization of a whole programming language and ecosystem is no longer sustainable enough to increase demand for their PaaS offerings.

If that is the truth, then other platforms like Spring are at the stake as well! If Groovy is not sustainable, why should Spring be?

Am I Groovy?

Suis-je Groovy? To get back to the original claim:

No, I’m not Groovy. Groovy and every other piece of Open Source software that does not in any direct way produce a commercial value for both the vendor and the consumer is doomed to fail in the long run. Open Source software has created a tremendous amount of value in our industry. Companies like ourselves wouldn’t be possible if we’d still pay millions for an operating system license. The question is not whether software is free as in beer or as in freedom. The question is whether anyone has any viable commercial interests in making a particular software element cheap or even free. If they don’t, well, the joke will be on you as the vendor might just stop doing it. Open Source or not.

7 thoughts on “Suis-je Groovy? No! What Pivotal’s Decision Means for Open Source Software

    1. Google has never claimed to have any commercial interests beyond releasing fun and geeky tools. One has to be crazy to build upon Google libraries, and I frankly don’t get AngularJS’s hype. We’ll all deeply regret AngularJS in 2-3 years. In the case of GWT, there is a vendor who can still provide support if you need: Vaadin, and I believe that Vaadin is a better vendor than Google, for GWT.

      Pivotal is different. They have always claimed to be an OSS company that supports OSS. When they drop two products – one of which rather popular – at the same time, this leaves a lot of open questions.

      1. Developers need to realize that no business can survive without profit. Unless you can drive enough revenue, the investments are not worth. A high quality product requires a lot of commitment and critical business domain demand more than mere quality. They need sustained support too. PostgreSQL and WordPress have managed to supply both open and commercial solutions.

        1. I don’t think that’s 100% true. A lot of innovation is driven by pleasure – as Groovy in the beginning. And that’s great. But eventually, business should be involved.

          WordPress (probably) makes a lot of money from hosted subscriptions, add-ons, skins, etc. PostgreSQL is one of those candidates of whom I’m not really convinced that they have a sustainable business behind them. I mean, who is EnterpriseDB anyway?

          1. But the core developers still have the pleasure of maintaining and upgrading groovy and Grails. If you have to trade your whole spare time for this, the pleasure might be gradually lost.

    2. I have used GWT and Grails. Here are my thoughts.

      GWT has the same issues that Echo Framework has. If i want to change anything in frontend i have to get a senior java developer to do it. Java developer don’t want to do frontend and business doesn’t want to pay that much money to change an icon. In theory it is great but in practice it has many issues.

      Grails has a bad image issue that is actually not true. Java (spring framework) developers think it is a lower quality framework. PHP developers think it is too difficult to learn. Over the years i have proven both of them wrong over and over again.

      1. Thanks for sharing your thoughts. This article was mainly about the business behind those projects. There have been many other articles discussing the pros and cons on a technical level…

Leave a Reply