I think Kalle's comments don't reflect a licensing issue, but rather one of maintenance and longevity: Shiro developers (or any open source development team for that matter) will maintain things that 1) has high perceived value for the community or 2) the developers use very frequently themselves in their own real-world projects.
The idea is that while it's nice to see that a new support module is being written (I think it's great!), there may not be enough evidence that the module will be regularly maintained and kept up to date, which would inevitably cause more headaches and maintenance time for the team, which would in turn would reflect negatively on the project's perceived health. So, one approach is to start up the support module on an external hosting site (e.g. similar to 'wicketstuff') and see how much traction it gets. If it gains and maintains momentum, then the community would clearly benefit from it being in the core project. Kind of like a mini incubator of sorts. I think though, Alan, you might be saying that such a 'proving ground' could be the Shiro project itself - perhaps a different part of our SVN repo. The only issue I can see with that is one of committer rights. Wicket stuff and external hosting providers offer a much lower barrier to 'committer entry' than a normal ASF project, so it might be worth seeing how it fares there before taking it on as part of the core. I tend to prefer the lowest barrier to committership possible, as I feel it helps the community more than the risk of any 'questionable' code it might introduce. I really believe most people that write code for an open source project and would like it to see adopted are good citizens in general and do their best to write good quality code and help the project. Les On Mon, Nov 29, 2010 at 12:37 PM, Alan D. Cabrera <[email protected]> wrote: > > On Nov 25, 2010, at 9:54 AM, Kalle Korhonen wrote: > >> On Thu, Nov 25, 2010 at 9:27 AM, Les Hazlewood <[email protected]> wrote: >>> But part of my delay is equally related to me thinking about how we >>> manage our 'support' modules. With struts2 and wicket and maybe >>> others, it seems like we should discuss how we handle this stuff in >>> general and what (if any) our policy should be. >> >> I doubt we can make a clear-cut decision. It depends on the value of >> the particular support module to Shiro core (you could argue that >> maintaining Spring support has more value than struts2, wicket, etc.) >> and committers' interest in maintaining the support module. It's >> extremely difficult to convince committers to maintain support modules >> for web frameworks they don't use themselves (been there, done that). >> The safe bet is to put the new support modules on github or elsewhere. >> They can always be migrated later to become part of Shiro. > > Unless there is some kind of licensing issue there is no reason, from the ASF > standpoint, to put new support modules on github or elsewhere. > > > Regards, > Alan
