[Proposal] Grails Plugin Collective.
Locked
1234
1234
[Proposal] Grails Plugin Collective.
 
|
Hi all,
I am proposing the creation of what I am calling the “Grails Plugin Collective”. You can read the proposal @ http://ldaley.com/post/672832641/grails-plugin-collective I am also pasting the same content below in Markdown format. ---------------------- # Proposal: Grails Plugin Collective The following is a proposal for, and a request for comment on, the idea of a semi-structured combination of social and technological systems and norms to initiate, develop and maintain Grails plugins. ## The Problem Being Addressed Typically, a plugin is born through inspiration or necessity. It's not uncommon that the original author at some point stops maintaining or developing a frequently-used or promising plugin. There are many reasons for this and they are in no way unique to the Grails ecosystem. People contribute and move on as is their want and well intentioned developers can quickly lose interest in developing a plugin due to roadblocks and lack of knowledge, experience and feedback.As a Software Developer using Grails professionally, the availability of a high quality plugin makes a significant product difference; and conversely an unsuccessful attempt to use a plugin due to bugs or lack of documentation costs real time. Often when finding an issue and fixing it, getting that fix back into the community takes considerable effort in coordinating with the plugin developer/maintainer who may or may not be around. As a plugin developer, during busy times it can be hard to keep up with bug reports, feature requests and Grails upgrades. It's also concerning that knowledge and understanding of the plugins I have authored rest largely with myself, creating a single point of failure. It would be much better if there were other people who could (and did) maintain and improve things in my (or any other author's) absence. ## The Proposed Solution To remedy this situation, I propose that a self-organised, distributed, democratic, collective be formed… to foster, develop and maintain Grails plugins. I am calling this idea the "Grails Plugin Collective" for the time being. The social structure is what would be the most interesting and, ultimately, enabling. It would allow members to work across plugins, scratching their own itches, and getting those fixes/features into release with minimal effort without risking quality. It would also enable steering and guiding the direction of plugins while allowing members to freely propose ideas and alternatives. Due to Grails' “convention over configuration” nature, this becomes critically important. Hopefully, the collective wisdom of a group of individuals results in a highly consistent, conventional approach to how plugins work. ### Goals and Aims * Create a community of volunteer skilled developers * Support the recognition of official membership (primarily for CVs) * Establish a set of useful, well used and high quality Grails plugins * Encourage outside contributions, both one-off and in working towards membership * Ensure adequate levels of documentation in a consistent format for all collectivised plugins * Ensure proper quality control mechanisms such as code coverage and developer documentation ### Relationship with VMWare and certification I propose that the collective should be an entity outside of VMWare. This does not exclude VMWare employees from participating in the collective by any means, or from having some kind of special role. It purely means that the entity is not bound to VMWare in any way other than through the licensing arrangement of any software owned by VMWare. I also propose that if a plugin certification scheme is ever established, it be done completely separately to the collective. I imagine that many of the collectivised plugins would aim for certification if at all possible, but in this respect they would be no different to other community plugins. ### Procedures and Principles The collective should aim to operate with the least amount of bureaucracy and procedure that is required. The core idea is that as a democratic structure, all proposals are put to a vote. Members will have a relatively short time frame (proposed: 48 hours) to vote. A certain proportion of the votes cast must be affirmative for the proposal to succeed. It's likely that there would also be some sort of veto mechanism for things that are extremely time critical. I image the following kinds of things would be voted on: * API/Design questions & changes * Releases * Quality and process standards * Developer membership * Acceptance of new plugins ### Initial Membership Being that what is being proposed is a self-organising, democratic social structure, I am hesitant to be to prescriptive about how such a thing might work in terms of my vision. I am interested in getting other people's ideas. An initial membership also needs to be put together. This will be somewhat of a challenge for a democratic outfit. To get the ball rolling, I suggest that the VMWare Grails team propose an initial membership of roughly 10 people (likely including themselves). From there, the collective can self organise and induct new members over time. So what are your thoughts? Is such an initiative worthwhile? Could it work? Could it succeed in raising and maintaining the quality of selected Grails plugins? Are there other such initiatives that we could learn from? What kind of social practices could be put in place to support rapid development while maintaining consistency and quality? Feel free to leave your opinion either here or on the grails-user mailing list. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: [Proposal] Grails Plugin Collective.
|
I think this is vital. There is a problem with "abandonware" plugins
and conversely Grails adopters being confused by multiple plugins that appear to offer very similar functionality. If we have a canonical set of plugins that are collectively supported there will be less chance of useful plugins getting left behind by Grails updates or left in a half-finished state. My concerns would mostly be around code-coverage and TDD. I try to drive all my plugin development using a mixture of unit tests (where possible - it's not always appropriate for library integration type plugins) and test projects with end-to-end tests that preferably can be run against multiple versions of Grails to ensure that the plugin really does support the Grails versions its descriptor says it does. I think it would be extremely useful to have a Hudson instance for collectivised plugin builds and we may even want to think about a template job for test apps with multiple Grails versions. I might have some useful input here as Energized Work host a Hudson instance where my plugins are CI'd in this way. In principal I'm more than happy to have any of my plugins collectivised if they're considered mainstream enough. While I'd like to stay involved I'm finding myself on a constant round of updating each plugin in turn and it would be great to have some help. Cheers, Rob --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
In reply to this post by ld@ldaley.com
HI,
I am involved in a number of plugin projects (Grails, Maven, Eclipse) and they all seem to suffer from the issues you mentioned. I am a little unclear on how your proposal differs from the support system already in place. Currently plugins are in an open repository where members of the plugin community can work on any plugin they wish. Normally this does not occur as there is risk of damaging an already working plugin. Many plugins are run though automatic testing and there is JIRA and mailing list support to communicate, vote, etc on plugins. I am not sure how you solution addresses the issue that plugins cease to be supported or kept up with current releases. I work on my plugins because I use them extensively in my consulting work and I have some older plugins I wrote that I no longer support due to changes in my customers needs. I have tried to find people to take over my older plugins and that has been pretty successful in keeping them up to date and relevant by people who are actually using them. There are a number of plugins in the Grails system that had entries created months ago and never saw the light of day. It would be useful to have a system where yearly or quarterly the author or one of the supporters must indicate in the documentation that the plugin is still supported or at least someone is still watching the mailing lists for questions and issues. I think the key is to identify the issues and determine why the current system is not filling the void and then either fix the existing system or create a new one. I just hesitate to create a new system that overlaps the existing system by 80-90% and have to deal with conversions, etc unless there is a clear issue that cannot be addressed by improving the current system. I fully support improving the current system as I do think it is weak in some areas but in other areas it is very strong and aligns well with the other plugin projects in the Open Source Community. Just my two cents Scott Ryan On Jun 7, 2010, at 5:34 AM, Luke Daley wrote: > Hi all, > > I am proposing the creation of what I am calling the “Grails Plugin > Collective”. > > You can read the proposal @ http://ldaley.com/post/672832641/grails-plugin-collective > > I am also pasting the same content below in Markdown format. > > ---------------------- > > # Proposal: Grails Plugin Collective > > The following is a proposal for, and a request for comment on, the > idea of a semi-structured combination of social and technological > systems and norms to initiate, develop and maintain Grails plugins. > > ## The Problem Being Addressed > > Typically, a plugin is born through inspiration or necessity. It's > not uncommon that the original author at some point stops > maintaining or developing a frequently-used or promising plugin. > There are many reasons for this and they are in no way unique to the > Grails ecosystem. People contribute and move on as is their want and > well intentioned developers can quickly lose interest in developing > a plugin due to roadblocks and lack of knowledge, experience and > feedback.As a Software Developer using Grails professionally, the > availability of a high quality plugin makes a significant product > difference; and conversely an unsuccessful attempt to use a plugin > due to bugs or lack of documentation costs real time. Often when > finding an issue and fixing it, getting that fix back into the > community takes considerable effort in coordinating with the plugin > developer/maintainer who may or may not be around. > > As a plugin developer, during busy times it can be hard to keep up > with bug reports, feature requests and Grails upgrades. It's also > concerning that knowledge and understanding of the plugins I have > authored rest largely with myself, creating a single point of > failure. It would be much better if there were other people who > could (and did) maintain and improve things in my (or any other > author's) absence. > > ## The Proposed Solution > > To remedy this situation, I propose that a self-organised, > distributed, democratic, collective be formed… to foster, develop > and maintain Grails plugins. I am calling this idea the "Grails > Plugin Collective" for the time being. > > The social structure is what would be the most interesting and, > ultimately, enabling. It would allow members to work across plugins, > scratching their own itches, and getting those fixes/features into > release with minimal effort without risking quality. It would also > enable steering and guiding the direction of plugins while allowing > members to freely propose ideas and alternatives. Due to Grails' > “convention over configuration” nature, this becomes critically > important. Hopefully, the collective wisdom of a group of > individuals results in a highly consistent, conventional approach to > how plugins work. > > ### Goals and Aims > > * Create a community of volunteer skilled developers > * Support the recognition of official membership (primarily for CVs) > * Establish a set of useful, well used and high quality Grails plugins > * Encourage outside contributions, both one-off and in working > towards membership > * Ensure adequate levels of documentation in a consistent format for > all collectivised plugins > * Ensure proper quality control mechanisms such as code coverage and > developer documentation > > ### Relationship with VMWare and certification > > I propose that the collective should be an entity outside of VMWare. > This does not exclude VMWare employees from participating in the > collective by any means, or from having some kind of special role. > It purely means that the entity is not bound to VMWare in any way > other than through the licensing arrangement of any software owned > by VMWare. > > I also propose that if a plugin certification scheme is ever > established, it be done completely separately to the collective. I > imagine that many of the collectivised plugins would aim for > certification if at all possible, but in this respect they would be > no different to other community plugins. > > ### Procedures and Principles > > The collective should aim to operate with the least amount of > bureaucracy and procedure that is required. The core idea is that as > a democratic structure, all proposals are put to a vote. Members > will have a relatively short time frame (proposed: 48 hours) to > vote. A certain proportion of the votes cast must be affirmative for > the proposal to succeed. It's likely that there would also be some > sort of veto mechanism for things that are extremely time critical. > > I image the following kinds of things would be voted on: > > * API/Design questions & changes > * Releases > * Quality and process standards > * Developer membership > * Acceptance of new plugins > > ### Initial Membership > > Being that what is being proposed is a self-organising, democratic > social structure, I am hesitant to be to prescriptive about how such > a thing might work in terms of my vision. I am interested in getting > other people's ideas. > > An initial membership also needs to be put together. This will be > somewhat of a challenge for a democratic outfit. To get the ball > rolling, I suggest that the VMWare Grails team propose an initial > membership of roughly 10 people (likely including themselves). From > there, the collective can self organise and induct new members over > time. > > So what are your thoughts? Is such an initiative worthwhile? Could > it work? Could it succeed in raising and maintaining the quality of > selected Grails plugins? Are there other such initiatives that we > could learn from? What kind of social practices could be put in > place to support rapid development while maintaining consistency and > quality? > > Feel free to leave your opinion either here or on the grails-user > mailing list. > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
Nice output Luke, I hope for something like this too. But I agree with Marc on financial feedback, difficult thing to elude.
On Mon, Jun 7, 2010 at 4:06 PM, Scott Ryan <[hidden email]> wrote: HI, -- Stéphane MALDINI doc4web consultant [hidden email] -- http://fr.linkedin.com/in/smaldini |
Re: [Proposal] Grails Plugin Collective.
|
In reply to this post by scryan
at least these plugins should be marked so that the user knows about the plugin status. If you look at the headers of most plugins in the portal 90% use something similar to "Grails Version: 1.0.0 > *" which i bad, because the user just assumes that everything is compatible with the newest versions. I think it would be a good first step to replace this with something more detailed. What about a list of all major grails versions (automatically updated with every grails release) where the plugin author just adds a OK if his plugin is compatible with the new version. Move the plugin to a "Plugin graveyard" if the last X (2 or 3??) major grails versions are not marked "OK" by the author. This way the plugins are still available but a user knows that there will be no development in the futur. |
|
|
I agree but also there is the case where a version will not work with
previous versions. It is sometimes useful to know what version of grails a particular version of a plugin works with. I have a plugin that is current for two releases of grails and another being developed for 1.3.1 but they are not downwardly compatible. So in that case it would look like 1.2.2 only or 1.1 - 1.2.x That way people know what version to use. In Maven I can indicate the version and the build system will take care of that issue and direct the installer to select the correct version. I think it works for Grails when upgrading but not the other way around. If I try to install a plugin on an earlier version of grails it will warn me but there is no way to indicate a ceiling. Scott Ryan On Jun 7, 2010, at 9:04 AM, Sebastian Hohns wrote: > > > Scott Ryan-3 wrote: >> >> There are a number of plugins in the Grails system that had >> entries created months ago and never saw the light of day. It would >> be useful to have a system where yearly or quarterly the author or >> one >> of the supporters must indicate in the documentation that the plugin >> is still supported or at least someone is still watching the mailing >> lists for questions and issues. >> > > at least these plugins should be marked so that the user knows about > the > plugin status. If you look at the headers of most plugins in the > portal 90% > use something similar to "Grails Version: 1.0.0 > *" which i bad, > because > the user just assumes that everything is compatible with the newest > versions. I think it would be a good first step to replace this with > something more detailed. What about a list of all major grails > versions > (automatically updated with every grails release) where the plugin > author > just adds a OK if his plugin is compatible with the new version. > Move the > plugin to a "Plugin graveyard" if the last X (2 or 3??) major grails > versions are not marked "OK" by the author. This way the plugins are > still > available but a user knows that there will be no development in the > futur. > > > -- > View this message in context: http://grails.1312388.n4.nabble.com/Proposal-Grails-Plugin-Collective-tp2245814p2246088.html > Sent from the Grails - user mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
> I agree but also there is the case where a version will not work with
> previous versions. It is sometimes useful to know what version of grails a > particular version of a plugin works with. I have a plugin that is current > for two releases of grails and another being developed for 1.3.1 but they > are not downwardly compatible. So in that case it would look like 1.2.2 > only or 1.1 - 1.2.x That way people know what version to use. In Maven I > can indicate the version and the build system will take care of that issue > and direct the installer to select the correct version. I think it works > for Grails when upgrading but not the other way around. If I try to install > a plugin on an earlier version of grails it will warn me but there is no way > to indicate a ceiling. Does def grailsVersion = "* > 1.1" not work for you? On a related note, I don't know whether Grails will automatically download and install the latest version of a plugin that's compatible with that version of Grails. It may simply download and install the latest version regardless. If that's the case, we could do with improving it. Peter --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: [Proposal] Grails Plugin Collective.
|
|
On Monday, June 7, 2010, Peter Ledbrook <[hidden email]> wrote:
> > On a related note, I don't know whether Grails will automatically > download and install the latest version of a plugin that's compatible > with that version of Grails. It may simply download and install the > latest version regardless. If that's the case, we could do with > improving it. > > Peter > AFAIK that is still the way it works. Trouble is if that was changed now it wouldn't affect the older versions of Grails anyway. Plus if plugins get neglected then the upper bound won't get filled in when an incompatible Grails version appears. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: [Proposal] Grails Plugin Collective.
|
In reply to this post by pledbrook
I think there are two parts of the conversation here:
1. First is more about infrastructure provided for creation, discovery, and maintaining of plugins. I definitely think that can be improved - there are many ways the portal can be improved, there can be automatic CI servers setup that, for example, test compatibility of existing plugins and plugin combinations when a new version of Grails is about to be released, etc. We also need a way to deprecate plugins so users know up front that it's not being maintained for new versions. That's the "easy" stuff - in that it just takes work and a little bit of money (i.e. for servers). I would hope that SpringSource would help out in this area since they have a vested interest in building up an active plugin ecossytem - it lets them leverage their own work better. 2. The second is more difficult and what Luke was trying to allude to - to provide a system to encourage contribution. I am not sure the collective idea, while interesting, will solve it - in fact, the danger there is that existence of collective might increase the perceived barrier to entry. I do think we as community should be better at collaborating - best example in recent past was the authors of various CMS plugins coming together. As some other pointed out, without financial incentive, it's difficult to be focused on maintenance of plugins you don't have direct need for. I think the Grails plugin system is awesome architecturally and there are many great plugins out there. I also have realistic expectations from plugins - I view them as something to get me started. If it works and satisfied all my needs - great. If it doesn't but satisfies most - that's still code I didn't have to write, and I've inlined many plugins and patched them up for my needs. I think that's an essential skill for any Grails developer. Thanks, Jean On Mon, Jun 7, 2010 at 9:36 AM, Peter Ledbrook <[hidden email]> wrote:
|
|
|
> I think the Grails plugin system is awesome architecturally and there are
> many great plugins out there. I also have realistic expectations from > plugins - I view them as something to get me started. If it works and > satisfied all my needs - great. If it doesn't but satisfies most - that's > still code I didn't have to write, and I've inlined many plugins and patched > them up for my needs. I think that's an essential skill for any Grails > developer. One aim of the collective is to improve the likelihood of patches being applied and new versions released. The hope is that even if the original author doesn't have time to do it, another member of the collective may do. It's unlikely that all members will be on holiday or deluged with work at the same time. Well, I hope it's unlikely :) Peter --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: [Proposal] Grails Plugin Collective.
|
On 7 Jun 2010, at 17:04, Peter Ledbrook wrote: >> I think the Grails plugin system is awesome architecturally and there are >> many great plugins out there. I also have realistic expectations from >> plugins - I view them as something to get me started. If it works and >> satisfied all my needs - great. If it doesn't but satisfies most - that's >> still code I didn't have to write, and I've inlined many plugins and patched >> them up for my needs. I think that's an essential skill for any Grails >> developer. > > One aim of the collective is to improve the likelihood of patches > being applied and new versions released. The hope is that even if the > original author doesn't have time to do it, another member of the > collective may do. It's unlikely that all members will be on holiday > or deluged with work at the same time. Well, I hope it's unlikely :) TBH this sounds like overkill. All your asking for here is surely to have more than one developer committing to every plugin. This however, may be tricky to achieve. It isn't happening naturally, and I don't think the collective will necessarily help. The people in the collective may end up too busy maintaining little fixes on lots of plugins, impacting their own plugin dev. Seriously guys - commercialize the market. Payback is the best motivator here IMO. Very few plugins have developed advanced features beyond their original feature set / authors immediate needs. This is because they cannot be productized currently. Marc ~ ~ ~ Marc Palmer Blog > http://www.anyware.co.uk Twitter > http://twitter.com/wangjammer5 Grails Rocks > http://www.grailsrocks.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
In reply to this post by pledbrook
Yes that does work for me but how do i do something like 1.1 and
greater but less than 1.3. Would it be 1.1 < XXX < 1.3. When I try to run the plugin install and the latest version does not work with my version it warns me and then I need to manually install the correct version once I do the work to determine what version will work for my version. This may be unique to my plugins since they are so dependent on the architecture of Grails which has changed between releases rendering the plugin inoperable. Scott Ryan On Jun 7, 2010, at 9:36 AM, Peter Ledbrook wrote: >> I agree but also there is the case where a version will not work with >> previous versions. It is sometimes useful to know what version of >> grails a >> particular version of a plugin works with. I have a plugin that is >> current >> for two releases of grails and another being developed for 1.3.1 >> but they >> are not downwardly compatible. So in that case it would look like >> 1.2.2 >> only or 1.1 - 1.2.x That way people know what version to use. In >> Maven I >> can indicate the version and the build system will take care of >> that issue >> and direct the installer to select the correct version. I think it >> works >> for Grails when upgrading but not the other way around. If I try >> to install >> a plugin on an earlier version of grails it will warn me but there >> is no way >> to indicate a ceiling. > > Does > > def grailsVersion = "* > 1.1" > > not work for you? > > On a related note, I don't know whether Grails will automatically > download and install the latest version of a plugin that's compatible > with that version of Grails. It may simply download and install the > latest version regardless. If that's the case, we could do with > improving it. > > Peter > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: [Proposal] Grails Plugin Collective.
|
|
In reply to this post by Marc Palmer Local
On Mon, Jun 7, 2010 at 5:14 PM, Marc Palmer <[hidden email]> wrote:
> > TBH this sounds like overkill. > > All your asking for here is surely to have more than one developer committing to every plugin. > > This however, may be tricky to achieve. It isn't happening naturally, and I don't think the collective will necessarily help. > > The people in the collective may end up too busy maintaining little fixes on lots of plugins, impacting their own plugin dev. > It's not just that. When I started working on the Selenium RC plugin I tried to get in touch with the developer of the existing (and seemingly long abandoned) Selenium plugin to see if he would be happy for me to fold my work into that so that there was no confusion about what plugin to install. I never got any response so we now have 2 Selenium plugins, one of which is (for the time being at least) up to date and one of which has the more obvious name but is fairly incomplete & doesn't work at all with newer versions of Grails. If that plugin had been something the collective was responsible for maintaining then I could have just jumped in & done what I liked to it. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: [Proposal] Grails Plugin Collective.
|
|
On 7 Jun 2010, at 17:26, Robert Fletcher wrote: > On Mon, Jun 7, 2010 at 5:14 PM, Marc Palmer <[hidden email]> wrote: >> >> TBH this sounds like overkill. >> >> All your asking for here is surely to have more than one developer committing to every plugin. >> >> This however, may be tricky to achieve. It isn't happening naturally, and I don't think the collective will necessarily help. >> >> The people in the collective may end up too busy maintaining little fixes on lots of plugins, impacting their own plugin dev. >> > > It's not just that. When I started working on the Selenium RC plugin I > tried to get in touch with the developer of the existing (and > seemingly long abandoned) Selenium plugin to see if he would be happy > for me to fold my work into that so that there was no confusion about > what plugin to install. I never got any response so we now have 2 > Selenium plugins, one of which is (for the time being at least) up to > date and one of which has the more obvious name but is fairly > incomplete & doesn't work at all with newer versions of Grails. If > that plugin had been something the collective was responsible for > maintaining then I could have just jumped in & done what I liked to > it. Yes for sure. But that is usually a niche case. I know the author of Searchable is AWOL. People from the Grails team have stepped in to maintain it periodically because it is a fundamental plugin (but also likely to fall out of favour what with Solr around). However this is the open source way. Someone else picks it up eventually if its worth picking up. In the meantime a bunch of people are inconvenienced because they need the fixes but can't put in the time themselves to provide them. Often they'd much rather pay a small sum to forget about the problem and have something that has a "guaranteed" lifetime and maintenance to it. Pay peanuts, get monkeys (like us <g>) Marc ~ ~ ~ Marc Palmer Blog > http://www.anyware.co.uk Twitter > http://twitter.com/wangjammer5 Grails Rocks > http://www.grailsrocks.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
Re: [Proposal] Grails Plugin Collective.
|
|
In reply to this post by Robert Fletcher-2
Robert makes a good point about maintaining other people's plugins. Naturally, we all want to be good citizens and not step on other people's toes. Perhaps one way to start addressing that is that when a plugin author releases the plugin, he should specify some policy for updates. Some examples:
We as a community should have some conventions about plugins. There are also licensing issues for code itself, though majority of plugins seem to be released under apache.
As for Marc's suggestion to commercialize the plugin market - I think that would be terrific in terms of encouraging better contributions, but I am not sure if it would work in practice. There are definitely some plugins that would be worth the money (nimble, springcache, export come to mind), but many of them are a single feature, that while valuable, would not justify paying in my mind. To throw out an example is JQuery-UI plugin. It's great, but before it came about, I was just including the JS in my code myself. The plugin simplifies things for me, but not enough that I'd pay more than, say, $10, or most likely just continue including the JS. So the question is how do you price the plugins in a way that both encourages use and provides sufficient income for the maintainer? I do not see that happening. Or rather, I see maintainers making some money off their plugins, but I don't think that would be enough for them to justify the time in the long term. I've been following the StackOverflow podcasts - their big belief is that if the rewards are extrinsic and nonmonetary (i.e. some arbitrary points and recognition), you are willing to spend half an hour of your time on answering a question. If you start putting money into the equation, people start to naturally equate that against your other money making opportunities, and will conclude that answering questions is not a productive use of your time. I am afraid that by introducing money into the situation you could accidentally introduce this dynamic. > However this is the open source way. Someone else picks it up eventually if its worth picking up. In the meantime a bunch of people are inconvenienced because they need the fixes but can't put in the time themselves to provide them. Often they'd much rather pay a small sum to forget about the problem and have something that has a "guaranteed" lifetime and maintenance to it. Is this not an avenue available to people now (i.e. contact the author and hire them for a certain fix)? Perhaps part of the convention I suggested above could be:
BTW, while I hope that we'll come up with some solutions sooner rather than later, perhaps this would be a good topic for Spring2GX in October, where we could have a panel discussion about the health of plugin ecosystem and what else could be done. I am happy to propose it - anybody else interested in participating on the panel? Thanks, Jean On Mon, Jun 7, 2010 at 10:26 AM, Robert Fletcher <[hidden email]> wrote:
|
Re: [Proposal] Grails Plugin Collective.
|
In reply to this post by Marc Palmer Local
Do we think it would be possible to create a "marketplace" for work on
plugins? On Mon, Jun 7, 2010 at 12:40 PM, Marc Palmer <[hidden email]> wrote: > > On 7 Jun 2010, at 17:26, Robert Fletcher wrote: > >> On Mon, Jun 7, 2010 at 5:14 PM, Marc Palmer <[hidden email]> wrote: >>> >>> TBH this sounds like overkill. >>> >>> All your asking for here is surely to have more than one developer committing to every plugin. >>> >>> This however, may be tricky to achieve. It isn't happening naturally, and I don't think the collective will necessarily help. >>> >>> The people in the collective may end up too busy maintaining little fixes on lots of plugins, impacting their own plugin dev. >>> >> >> It's not just that. When I started working on the Selenium RC plugin I >> tried to get in touch with the developer of the existing (and >> seemingly long abandoned) Selenium plugin to see if he would be happy >> for me to fold my work into that so that there was no confusion about >> what plugin to install. I never got any response so we now have 2 >> Selenium plugins, one of which is (for the time being at least) up to >> date and one of which has the more obvious name but is fairly >> incomplete & doesn't work at all with newer versions of Grails. If >> that plugin had been something the collective was responsible for >> maintaining then I could have just jumped in & done what I liked to >> it. > > Yes for sure. But that is usually a niche case. I know the author of Searchable is AWOL. People from the Grails team have stepped in to maintain it periodically because it is a fundamental plugin (but also likely to fall out of favour what with Solr around). > > However this is the open source way. Someone else picks it up eventually if its worth picking up. In the meantime a bunch of people are inconvenienced because they need the fixes but can't put in the time themselves to provide them. > > Often they'd much rather pay a small sum to forget about the problem and have something that has a "guaranteed" lifetime and maintenance to it. > > Pay peanuts, get monkeys (like us <g>) > > Marc > ~ ~ ~ > Marc Palmer > Blog > http://www.anyware.co.uk > Twitter > http://twitter.com/wangjammer5 > Grails Rocks > http://www.grailsrocks.com > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
i for one think that if you create a marketplace for plugins it will
severely damage not only the work on plugins but also the overall framework usage itself. One of the primary values of this framework is the value in sharing technology solutions in an open source manner. I think if you move it in to a marketplace all the issues like pricing , support etc which most developers are not set up to handle will cause the plugins to drop considerably. i contribute to the community to gain feedback and good ideas for my consulting gigs. If I had to deal with pricing models etc it would actually keep me from participating rather than participating as I do today. Market places have been attempted by many large companies in the past and have been a horrible failure except for things like Apple etc but they have a different audience and support structure. I was around when BEA tried their marketplace and others like IBM etc and they did not fair well. Scott Ryan On Jun 7, 2010, at 10:55 AM, Daniel Honig wrote: > Do we think it would be possible to create a "marketplace" for work on > plugins? > > On Mon, Jun 7, 2010 at 12:40 PM, Marc Palmer <[hidden email]> > wrote: >> >> On 7 Jun 2010, at 17:26, Robert Fletcher wrote: >> >>> On Mon, Jun 7, 2010 at 5:14 PM, Marc Palmer <[hidden email]> >>> wrote: >>>> >>>> TBH this sounds like overkill. >>>> >>>> All your asking for here is surely to have more than one >>>> developer committing to every plugin. >>>> >>>> This however, may be tricky to achieve. It isn't happening >>>> naturally, and I don't think the collective will necessarily help. >>>> >>>> The people in the collective may end up too busy maintaining >>>> little fixes on lots of plugins, impacting their own plugin dev. >>>> >>> >>> It's not just that. When I started working on the Selenium RC >>> plugin I >>> tried to get in touch with the developer of the existing (and >>> seemingly long abandoned) Selenium plugin to see if he would be >>> happy >>> for me to fold my work into that so that there was no confusion >>> about >>> what plugin to install. I never got any response so we now have 2 >>> Selenium plugins, one of which is (for the time being at least) up >>> to >>> date and one of which has the more obvious name but is fairly >>> incomplete & doesn't work at all with newer versions of Grails. If >>> that plugin had been something the collective was responsible for >>> maintaining then I could have just jumped in & done what I liked to >>> it. >> >> Yes for sure. But that is usually a niche case. I know the author >> of Searchable is AWOL. People from the Grails team have stepped in >> to maintain it periodically because it is a fundamental plugin (but >> also likely to fall out of favour what with Solr around). >> >> However this is the open source way. Someone else picks it up >> eventually if its worth picking up. In the meantime a bunch of >> people are inconvenienced because they need the fixes but can't put >> in the time themselves to provide them. >> >> Often they'd much rather pay a small sum to forget about the >> problem and have something that has a "guaranteed" lifetime and >> maintenance to it. >> >> Pay peanuts, get monkeys (like us <g>) >> >> Marc >> ~ ~ ~ >> Marc Palmer >> Blog > http://www.anyware.co.uk >> Twitter > http://twitter.com/wangjammer5 >> Grails Rocks > http://www.grailsrocks.com >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
In reply to this post by Jean Barmash 1
i agree this would be a great topic to discuss at the Conference but I think the topic should focus on identifying the issues with the current structure and how to improve it rather than creating a whole new structure and losing the things that are good with the current structure. This is not a unique problem and comes up a lot in the Maven and Eclipse communities as well. Bottom line is that if someone does not have time to maintain a plugin or they move on to a different project with a different technology they won't have as much time to dedicate to maintaining the plugin. This is just the nature of developers who are not paid full time to work on Open Source projects but that does no discount their contributions.
Scott Ryan On Jun 7, 2010, at 10:53 AM, Jean Barmash wrote: Robert makes a good point about maintaining other people's plugins. Naturally, we all want to be good citizens and not step on other people's toes. Perhaps one way to start addressing that is that when a plugin author releases the plugin, he should specify some policy for updates. Some examples: |
|
In reply to this post by scryan
What about making it easier for users to donate (e.g. via a Paypal donate button using the authors email address) to plugin authors via the portal?
I guess the only risk then becomes conflict over who 'owns' the plugin and therefore benefits from money donated?
It might be a good half-way house between the current situation and a full-blown marketplace. cheers Lee
On 8 June 2010 05:10, Scott Ryan <[hidden email]> wrote: i for one think that if you create a marketplace for plugins it will severely damage not only the work on plugins but also the overall framework usage itself. One of the primary values of this framework is the value in sharing technology solutions in an open source manner. I think if you move it in to a marketplace all the issues like pricing , support etc which most developers are not set up to handle will cause the plugins to drop considerably. i contribute to the community to gain feedback and good ideas for my consulting gigs. If I had to deal with pricing models etc it would actually keep me from participating rather than participating as I do today. Market places have been attempted by many large companies in the past and have been a horrible failure except for things like Apple etc but they have a different audience and support structure. I was around when BEA tried their marketplace and others like IBM etc and they did not fair well. |
|
|
Is money even a motivator. I maintain one of the more complex plugins and money is not a motivator at all. In fact if money was involved I would not make the plugin available because of all the impacts that getting money for this work has. Would any of the issues raised so far really be changed with money entering the equation. Unless it was a full time salary most people would still do it in their free time when they are not generating full time revenue. Since a plugin is such a minor part of the overall framework and plugin work takes 2-3 hours per bug is it reasonable to expect revenue to equate to any reasonable hourly rate?
The other issue is me paying for a plugin and then reusing it in a project for a client. There are all sorts of implications there. Is money really required to have a viable plugin architecture. Most of the Apache and Eclipse projects don't have money involved and seem to function just fine. Scott Ryan On Jun 7, 2010, at 3:08 PM, Lee Butts wrote: What about making it easier for users to donate (e.g. via a Paypal donate button using the authors email address) to plugin authors via the portal? |
«
Return to Grails - user
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |