Isn't this whole situation similar to the Apache Web Server project and their plugins? How do they do it?
On Feb 20, 2013, at 9:16 AM, Christian Schneider <ch...@die-schneider.net> wrote: > Am 20.02.2013 14:26, schrieb Raul Kripalani: >> I'm thinking about the organisation strategy here. Below is a list of a few >> practical issues off the top of my head. For the people supporting the the >> marketplace idea, could you elaborate on how we'd handle these? >> >> - Would marketplace components be sponsored/owned by committers only, or >> anyone is free to contribute? > Anyone should be able to contribute. Perhaps an ICLA should be necessay. >> - What's the screening process when a new component is submitted? Or is >> there any? > I would limit the screening to legal issues. So mainly licensing. >> - What if a component is abandoned by its sponsor in the marketplace? > Then it would not be released anymore. The PMC might be able to select a new > owner. >> - How do we supervise the quality of components? The quality of >> components since day 1 has been a big success factor of Camel so far. > The quality would be in the responsibility of the owner. >> - Will the committer team stand responsible if a component simply >> doesn't work as advertised? > No >> - How would issues and tickets be tracked? In the ASF JIRA? > To use jira makes sense. Perhaps in a new project. >> - How would we align, organise, coordinate Camel releases with N >> component sponsors? Until now, the voice of community has been -1 to >> independent component versioning. So even if we open a Camel Marketplace, >> component versions would need to stay aligned. > Basically not at all. The releases would not be coordinated centrally. If a > component becomes incompatible with a new version the owner would have to do > the changes and publish a new release. >> - Where would documentation be hosted? > I propose to keep the documentation in confluence. Perhaps in a separete > project. > >> The number of components increasing to a level beyond our capacity is an >> undeniable sign that the Camel community is thriving. We should be thinking >> of expanding the Committer Team rather than outsourcing work to other >> communities and other approaches ;) > A larger team is more difficult to coordinate. The marketplace aproach should > be able to scale better. > > Of course an important factor is that the API does not change too much over > time. So ideally components stay compatible with a big range of camel > releases. > This requires a lean and well designed API which we are currently lacking. > But perhaps we can provide this in the camel 3 release. > > Christian > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com >
