Marc Palmer

From http://www.mcclatchydc.com/cartoons/gallery/80178-a80399-t3.html

As mentioned earlier today, I’m going to be talking at JAX London 2010 about how you CAN use Grails.

I would like to hear however, the reasons why some of you may not have been able to use Grails at your place of work. I’m sure there are many amusing and probably frustrating stories.

OK, I’m looking for soundbites for the talk. Come on, feed me!

They’ve firmed up the timetable now and it seems I’m on the last day where the Groovy & Grails track is happening – at the same time that there’s a Java EE 6 talk. So I’m hoping that all the smart people will be over at my talk

Full details of the JAX London 2010 program are here http://jaxlondon.com/

…and here’s the overview of what my talk (which is not written yet, but is roughly fleshed out) will be about:

Grails is the hot property in rapid web application development frameworks on the Java platform, attracting around 90,000 downloads per month. It uses the Groovy language but is nonetheless primarily a Java-based stack. This makes it a perfect fit for Java development teams. Most programmers I talk to want to be working with Grails more in their day job because it is actually great fun and incredibly productive. However organisations are often resistant to change and may not be as excited as they should be about the opportunities Grails offers their business. This talk will give you some insights into the power of Grails and ways to ease your organisation into a more productive and enjoyable era of development – for the good of all concerned!

The talk is listed as “basics” , which I suppose is fair but I expected to present some reasonably advanced concepts for non-Grails users in terms of ways to use Grails and plugins.

I’m crapping myself to be honest, no idea how big the conf rooms will be etc. Gulp. It should be fun though. Knowing how high or low to pitch it at a general-purpose Java conf is tricky though. I see the Rails crowd have a “twitter in about an hour”. I’m hoping to pitch something a bit more “get grails working within your existing enterprise systems” which I think may be a bit more relevant to the crowd.

Comments on this appreciated, especially from JAX veterans – I’ve never been myself.

Right at the end of the Groovy & Grails Exchange (AKA #ggx) final park bench session I came up with a question that has been brewing in my mind for a long time. Thing is, it is quite a big and difficult question, so I thought it would be better to shut the hell up and deal with it later after I’d clarified things in my mind a bit, i.e. now.

Here it is in a nutshell: Unless I’ve missed something, there’s no commercial market for Grails plugins. And this could be a problem because what percentage of all free open source dev projects out there survive in the long run with a vibrant user base? It must be pretty low by my estimation.

As a developer of many Grails plugins I am most definitely not having a whine about how I can’t make money out of my plugins (at least directly). I will always be able to get enough work one way or another – this is about the health of the plugins themselves which suffers because it is not currently possible to make money from them. Unfortunately this is really related to the general contentious issues surrounding the whole free (no cost) software movement. Paying for support works for large applications/frameworks, but for the smaller stuff it doesn’t work as a model in my opinion.

Anyway, its great that we have over 300 grails plugins now. Some of them are already stagnating though – including some of mine. Keeping plugins current and of good quality is fundamental as we know from experience (not just with Grails) that old plugins – which may still be relevant – stop working with newer builds of the “mother” framework. This leaves users in the cold over time, and can cause the attractiveness of a framework (eg Grails) to decay over time.

Conversely the number of stable releases of Grails that are in use by users only increases over time, which means all plugin developers have an increasing burden of support and testing for every plugin release.

When a big part of the value of a framework comes from the reusable components you can pull into your apps, if you end up with a high percentage of these components becoming mothballed over time, your ecosystem starts to look like a graveyard rather than the productive paradise it was when you started.

Let’s look at a possible plugin lifecycle – it happens to be very similar to my situation which will be no surprise, but I’m sure I’m not alone:

1. Inception: Either a lone developer has a great idea and a lot of spare time, or their employer has a great need that is reusable and they agree to open source it.
2. Dash to meet needs: Implementation steams ahead, the plugin is released
3. Documentation: high quality documentation is written for the first release (if you’re lucky)
4. Honing: in response to other users’ feedback, bugs are fixed, new features added
5. Steady state: the plugin works. No new major features are needed by the core developer/company
6. Stagnation begins: Minor bugs and feature requests begin to build up in JIRA. Some users submit patches or contrib minor fixes
7. Infrequent maintenance: Original devs return when they have precious spare time, usually to fix the issues that affect them most, but maybe with a couple of user-related fixes.
8. Stagnation sets in: Documentation drifts out of sync with point releases, builds stop working with newer versions of Grails. Developer doesn’t relish re-testing all their plugins with all stable releases of Grails in circulation (Grails 1.0.3/4, 1.1.1, 1.1.2, 1.2… and beyond) and so hides head in sand. This holds back Grails users who rely on such plugins who then do not upgrade to newer Grails versions.

It might look something like this:

It doesn’t look that bad does it? Try multiplying it by 10 plugins.

So what can be done about this? I don’t have the answer.

Would an iPhone App Store like mechanism for premium plugins work? There’s certainly people out there who would pay for plugins – but whether there are enough to pay a non-punitive price and make plugin development a viable career for people so they don’t let the rot set in because they can devote their real paid time to development?

Would a “Plugin development co-op” work, where people pay a low-ish monthly subscription fee to use and receive priority support for all participating plugin developers’ plugins? I rather like this idea, but again it remains to be seen if this could generate enough revenue to make it possible for enough developers to dedicate non-spare time to the development.

It just bothers me – why must plugin development be a “spare time” thing? These are very serious and important components in peoples applications. Will big enterprises really be happy to move to using Grails to dev apps that use a bunch of free plugins by individuals who write them on the train or when their wives have gone to sleep? Something that has Apache behind it may be an easy sell, but “some guy in a shed in the UK somewhere” doesn’t have the same ring to it does it.

I think if this problem is solved well, it may well open up the enterprise market that much quicker. Surely we can’t expect SpringSource to “buy” every enterprise-vital plugin that pops up, to give it credibility?

There is also another issue – that of licensing. Serious businesses need to know about the licenses that plugins are released under. This is not yet clearly identified, we could do more work there. I started tagging my plugins on grails.org with license tags such as “license-apache2″. However you can’t currently browse plugins by tag as far as I can tell on grails.org

Your thoughts appreciated.

Or #ggx as it was tagged on Twitter. Surely conferences will start calling themselves stuff like #ggx2010  instead of “real” names to help their memes spread more thoroughly. Anyway, I degress.

I had a good time at the conference, very nice to meet up with real people who use grails and plugins. I was particularly interest in the keynotes and the talks by Burt (@burtbeckwith) on scalability and Venkat (@venkat_s) on DSLs. I was impressed by Sebastian’s (@sebi2706) iWebkit plugin talk too – it looks so easy to get an iPhone web UI with it. Although, I can see issues with user agent detection and using bean-fields plugin with it, that I would need to tackle first.

Anyway, there was a question that I didn’t ask at the parkbench panel at the end, which will be subject of another post…