Do we need a commercial market for Grails Plugins?
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:
- 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.
- Dash to meet needs: Implementation steams ahead, the plugin is released
- Documentation: high quality documentation is written for the first release (if you’re lucky)
- Honing: in response to other users’ feedback, bugs are fixed, new features added
- Steady state: the plugin works. No new major features are needed by the core developer/company
- Stagnation begins: Minor bugs and feature requests begin to build up in JIRA. Some users submit patches or contrib minor fixes
- 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.
- 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.
19 Comments
Tomas
December 11, 2009This is a very interesting idea, but I think it would also discourage people from using the premium plugins unless they are very good. You then end up with three ‘premium’ spring security plugins on top of the regular one.
What about crowdsourcing the financing of Grails features, bug fixes and plugin development?
So for example, if I wanted to see Solr integration for Grails or seeing the PermGen space issue fixed in Grails interactive, I would go to a site and add a bounty of £10 for this. If 50 people wanted this, there would immediately be an incentive of £500 for building this plugin.
Marc Palmer
December 11, 2009Yes great, but what about the next 5 years of maintenance for that plugin?
Tomas
December 11, 2009I would imagine bounties can be continued on new features / functionality in individual plugins would continue, so the list would look like
Add swf support for Weecem Plugin ( £40 )
Add image manipulation support for App Engine Plugin ( £30 )
Göran Ehrsson
December 11, 2009I’ll be happy to pay for my high priority plugins (quartz, shiro, searchable, etc.), but I would be put off if there was a limited trial period, say 30 days. I usually need months of development/testing and maybe a few weeks in production before I really know that “this is a good plugin that I want to support”.
Like I did with JFreeChart. I used in in a couple of projects during a period of 2-3 months. Then I payed for the developer guide to support the development of the library.
That’s “donationware”, right? But I guess most people do not bother to donate anything, which is sad IMO.
Gabe Beged-Dov
December 11, 2009Hi Marc,
Thanks for sharing your thoughts (and cool diagram
on this topic. I agree that the health and vibrancy of the Grails plugin eco-system is a critical aspect of the overall success of the platform and providing a way to compensate people for work related to the care and feeding of a plugin can and should play a part in the overall eco-system.
In addition, I think there is also an opportunity to lower the barrier to entry and friction associated with participation in the eco-system for both the developers and users of a plugin (or group of related plugins). I was looking to foster discussion of this on the thread at http://old.nabble.com/best-practices-for-grails-plugin-dev-ts26667325.html. Given that convention over configuration is a central tenet of Grails I was surprised by the general reaction of “do whatever feels good” rather than striving to have some reasonable defaults for plugin dev and maintenance.
Maven has many issues but it does do a reasonable job of providing out of the box support for community around plugins. Take that basic model and add a tip jar and I believe you would be taking a big step forward on the plugin front.
Best regards,
Gabe
Gustavo
December 11, 2009I believe that a “pay-per-feature/issue” system might solve this problem, if done in the right way.
Imagine the getafreelancer service, it’s something like that, but many developers might bid on a feature/issue and many clients would be willing to pay a small amount for that feature/issue.
Lots of people are willing to pay 1 dollar, as long as they pay *only* 1 dollar, and be sure that everyone else that is paying for that feature/issue, is also paying 1 dollar.
Make a site where anyone can register a issue/feature. Then developer(s) says how much that would cost. Then possible payers join saying “im willing to pay for it”. Based on the price that the developer said, and the amount of interested payers, settle an agreement on the amount that each interested has to pay, and everyone pays the same amount. (minus 5~10% cut for the site).
Probable headaches would have to handle payment/reimburse, then is some kind of rating/satisfaction on developers and payers, well, theres a lot to be done. But as I said, if this is nicely done, transparent for every part, it might be a great solution for this problem.
I believe that this would accomplish:
1. grails plugin system would be vivid, state of art programs, and not a graveyard
2. plugins developers/maintainers would profit, and feel good without guilty or waste of time, etc etc…
3. make this site not grails exclusive, open for all of the open source communities that has this same problem, and the company behind this will earn a lot of money
It’s just an idea, might be a good one, or might lousy one…
So, what do you think?
Marc Palmer
December 11, 2009In theory this sounds good but in reality… even plugins that don’t need new features still need compatibility testing on an ongoing basis with new releases, and bug fixes. Your $1 isn’t going to get you much of that guaranteed.
It’s interesting to think about costs. How much do plugins save businesses? Quartz plugin – probably a few days to integrate that into grails yourself , even if you had no bugs to deal with. Say $3000 there. Searchable plugin – probably another $5000 or more at least in development time done in-house.
What I’m getting at is that the scale is all wrong. People want to pay pennies, but developer
time is very valuable. The total number of users of a plugin may – at best – number in the low thousands (certainly at this stage). It’s not like the App Store bonanza.
Pay per feature doesn’t solve the longevity problem. Not everything needs new features, but everything does need continued testing against new versions of Grails and, in many cases support.
SiteMesh library is a good example. As far as I know it had little if any activity on it for several years because it just worked and that was that. However if you had a Grails plugin like that you still have to keep up to date with latest Grails builds to make sure that a new major release doesn’t kill your well-loved old plugin. If you don’t do this, Grails can come out and break it for all your users, who will then not either upgrade to a newer better version of grails, or they will ditch your plugin.
Sébastien Blanc
December 11, 2009Excellent post Marc, I was secretly also thinking how in the future I could apply a business model to my plugin. I like the idea of Tomas about crowdsourcing/funding, it’s really worth looking concretely how we could set this up (partnership/sponsorship …).
But Göran Ehrsson’s comment where he says “Like I did with JFreeChart. I used in in a couple of projects during a period of 2-3 months. Then I payed for the developer guide to support the development of the library.”
Well That’s interesting , write a book about your plugin/plugins , you will get some money for that , increase your commitment about maintaining/enhancing the plugin and give you certainly other opportunities that I can’t figure right now.
Maybe not writing alone, but with a co-author , covering for example a set of plugins (“Grails plugins in action”
)
Marc Palmer
December 11, 2009Its a nice idea, but I don’t know of anybody that has made enough money to cover all the time recovered to write a tech book in the first place… generally book revenue is very low compared to the effort, unless you write a popular classic!
The fundamental problem is, I think, that every plugin has a maintenance overhead – usually reasonably small – “forever”. As you can’t add new features every few months for years and years, except for rare cases, your plugin revenue will diminish quite quickly over time if any payment is “per-feature” based. Therefore to make money developing plugins you’d continually have to develop new popular plugins to make up the revenue shortfall in your older ones.
Then you have a LOT of compatibility testing to do “forever”.
Tomas
December 12, 2009I think it also depends on how attached you are to your plugins and whether the original author should be the only person making changes and maintaining a plugin. I think maybe if maintaining your plugins is becoming a chore, you might consider offloading them to someone who might still think it is exciting.
I would love to take over a plugin like searchable, Flex or spring security for a year just to really learn the internals of such systems and keep up to date with them. I’m sure I’m not the only one.
The reward of maintaining the plugin can be something other than monetary. Maybe we can use conferences like GGX, GR8 and Spring One as places where knowledge dumps happen. Something like this will ensure plugin longivity and would also prevent people from contributing plugins. Programs like Google Summer of Code might give a monetary incentive for this.
Of course, I would love to see companies like Adobe step up and sponsor development of plugins that promote their product.
Robert Fischer
December 13, 2009How’d you like to take over Autobase, Tomas? Drop me an e-mail.
Wanderson Santos
December 12, 2009Very insightful!
I can see that problem isn’t with new plugins, but maintain the most used ones…
So I believe SpringSource could embrace and maintain ($) those already most popular plugins, like Quartz, Searchable, and so on. These plugins, like Gabe mentioned, really are “a critical aspect of the overall success of platform” and consequently SpringSource.
This action will not only estimulate new plugins, but ‘great and useful plugins’ for the ecosystem.
Rob Fletcher
December 12, 2009This is really difficult. I really don’t want to be paying to *try out* plugins on my own toy projects. Tip jars are probably never going to adequately repay developers. I find limited time licences a nuisance as the demands of real life can easily mean you run out of time before seeing whether a product does what you need. Could a free for non-commercial use licence work? I’m not sure. At work we use almost exclusively open source software because a) the good stuff tends to be better and b) we don’t have bean-counters to deal with before we can use something.
One thing I really think would be a good idea is to have small teams of developers working on plugins rather than them being solo hobby projects. That way roadmaps can be managed better, developers can come and go but the plugin project can continue. It appears to me that very few if any plugins are developed like that.
Marc Palmer
December 14, 2009Rob – I don’t for a second think people should have to pay to try out plugins. I don’t even necessarily think everybody should pay for plugins – eg small individual developers shouldn’t have to pay.
I don’t think there’s any way to force the use of teams on plugins – some do have a team, but mostly its lead dev + contribs. Without someone with consistent responsibility over time for testing and release planning, IMO plugins will not thrive.
doyle
December 14, 2009It sounds good in theory.
Issues with the above:
1. Crowd sourcing is very political
2. Need a grails license model/plugin
2a. Spring source / vm ware should create a repo and get a cut 10% to 15%
2b. all plugins should pass some type of automated testing and/or be scanned for malicious code.
3. Like the app store i don’t think that support should be guaranteed. If you write an app that is really really good then you can price it higher because you won’t make any money on the support. Mr. Bloch said “API’s are like sex one mistake and you’ll be supporting it for life.”
Overall it seems like a good idea. The PHP guys do it we should to.
Benoit
December 15, 2009I don’t think the problem is yet to make developing plugin a money making activity, I just don’t think the framework as yet reach this critical size. At the moment we are all investing in the technology, for fun but also with hope that I will pay off at some point, when grails is really going to be a force in the JVM world. Until then, I’m not expecting to live from it, but I need my investment to pay off and people to get convinced, so I need a good framework and good plugins. And that, usually, don’t come cheap …
So, that’s a really interresting and important: how to keep people motivated when they know the financial reward is not for now ? then I had a vision: beer. Is it not what it’s been invented for ? how about motivating the best grails/plugin developer by offering beer or round of beer if they solve your issues? That would motivate a few. And then, with the beer, comes a better notion of reward, a better feel of community. I would personally (mark my worlds) pay a few beer to people getting me out of trouble or fixing a few issues which hurt me. I’m sure i’m not the only one.
exdevfr
December 15, 2009I see no hope in that. It’s already so hard for the typical customer to understand that maintenance of their app is not free. No new feature=no money.
So the maintenance of a plugin… For me it can only be a byproduct of a customer project. In my experience : focus is either on making money or innovating/sharing/enjoying … not both.
Jeremy Flowers
January 9, 2010I think that plug-ins should be free to use in a development environment in order to promote feedback and creation of a more useful plug-in and sometimes consolidation of plug-ins.
But as soon as they get used in a production environment, then a license fee becomes payable.
That way there is an incentive to maintain your code.
fabien7474
February 22, 2010Very interesting article and comments!
I definitely agree with Wanderson Santos about having SpringSource/VMWare maintaining the most popular plugin since they are “a critical aspect of the overall success of platform”. Concerning rewarding the author plugin, I don’t have a clue about the solution but I can say that if I use intensively a plugin and I am happy with that, I am willing to contribute for the plugin (either by money or by my development time).