hi - although I didn't think about all implications please find some comments below.
As I'm new to Apache Camel I might not be in the position to provide all these suggestions and ideas. If I unintentionally step on someones toes please forgive me :-) Maruan Sahyoun Am 20.02.2013 um 14:26 schrieb Raul Kripalani <r...@evosent.com>: > 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? I'd lean towards open for anyone as this will provide the largest target audience. I'm not sure how the current number of components were created. Were they always initiated and developed by committers? Communities like jQuery, Wordpress, node.js and others show that it's possible to provide guidelines others can follow. Of course it's also means loosing some control. But it's to the benefit of concentrating the work on core. Why should the current committers be involved in every single component? A viral marketplace (or Component Repository for a different term) would help to grow the community even further. Lately there were some discussion about Scala. If core offers 'Scala Binding' people can contribute components written in Scala and maybe there are other languages to be added. Apache Camel should provide the foundation. But I think controlling everything is not what Apache Camel is about. > - What's the screening process when a new component is submitted? Or is > there any? There should be a screening process to ensure some standards. This could include checks for the availability of license terms, documentation ….. It could also mean that all components have to be under the Apache License. There could also be be a test suite the component needs to pass to ensure conformance to the API. What can't be ensured/enforced is that the component is fit for a specific purpose. That's something the component developers need to ensure as well as the 'users' picking the component. But that's no difference to todays situation. A rating system could help to provide feedback. > - What if a component is abandoned by its sponsor in the marketplace? It will stay there for others to pick up. If it's officially declared to be abandoned the information can be highlighted so potential users do know about it. If it's still doing it's job well there is nothing wrong with it. If it's really old it could be moved into an archive section. > - 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. That's a very important point. And honestly not all components will be of equal quality. Apache Camel could help by providing standards, samples and starters so a certain level is met. > - 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? There should be an ticket management per component. Doesn't have to be JIRA. To me that's a follow up question. E.g. if the components are hosted on GitHub a ticket system is included. > - 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. No reason to be aligned with all components. Alignment will be done with core and a set of main components where the committers are stakeholders. The sponsors for the individual components in the marketplace will be responsible to make sure that their component works with the latest releases. A alpha/beta cycle will give them enough time to do so. I think the -1 stems from the fact that handling the different version inside Apache Camel and being responsible for it s too much of an effort. I the component is developed outside what's wrong with the component being v1.1.0 where camel might be 2.11.0 > - Where would documentation be hosted? With the component > > The number of components increasing to a level beyond our capacity is an > undeniable sign that the Camel community is thriving. That's right and otherwise we wouldn't have that discussion. > We should be thinking > of expanding the Committer Team rather than outsourcing work to other > communities and other approaches ;) > IMHO at some point in time control and responsibility must be passed on. An the idea is not about outsourcing (which is already done today as not all components are written by the committers) it's about attracting people to extend and focusing on a solid foundation. > Thanks! > > *Raúl Kripalani* > Apache Camel Committer > Enterprise Architect, Program Manager, Open Source Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> > > On Wed, Feb 20, 2013 at 12:30 PM, Christian Schneider < > ch...@die-schneider.net> wrote: > >> I also think it would be a good idea to concentrate on core and a few >> important components. The sheer number of components got a little out of >> control recently. >> So for example we could keep the 10 or 20 most important components in >> camel and move the rest out to a marketplace. >> >> Christian >> >> Am 20.02.2013 11:37, schrieb Maruan Sahyoun: >> >> well IMHO this would also address the release lifecycle question. That >>> part of the discussion initiated the idea. If there are enough people >>> around to maintain the components that's great. On the other hand are there >>> also enough people around to move Camel 3.0 forward AND maintain all >>> components? Bottom line from my outsiders perspective following your >>> discussions was that there are too many things to be done within a certain >>> period of time. I might be wrong though. >>> >>> Maruan Sahyoun >>> >>> Am 20.02.2013 um 11:26 schrieb Raul Kripalani <r...@evosent.com>: >>> >>> Hi, >>>> >>>> I don't think a marketplace and surrendering responsibility of components >>>> helps solve the problem we are discussing. >>>> >>>> We don't have an ownership/responsibility/**authorship issue: it's a >>>> release >>>> lifecycle discussion. How do we deliver component fixes to the community >>>> quickly? Surrendering them doesn't seem to be the solution. Truth is that >>>> we do have enough capacity in the Camel project to maintain the >>>> components >>>> we host. As proof, most (sensible) component tickets are resolved within >>>> 1 >>>> week of their creation; some in just hours. >>>> >>>> BTW - we usually encourage users to donate their custom components to the >>>> Camel project, if they use ASL-compatible libraries. For the rest, >>>> there's >>>> already a marketplace at camel-extra [1] that hosts non-ASL compatible >>>> components. >>>> >>>> Regards, >>>> >>>> [1] >>>> http://code.google.com/a/**apache-extras.org/p/camel-**extra/<http://code.google.com/a/apache-extras.org/p/camel-extra/> >>>> >>>> *Raúl Kripalani* >>>> Apache Camel Committer >>>> Enterprise Architect, Program Manager, Open Source Integration specialist >>>> http://about.me/raulkripalani | http://www.linkedin.com/in/** >>>> raulkripalani <http://www.linkedin.com/in/raulkripalani> >>>> http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> >>>> >>>> On Wed, Feb 20, 2013 at 9:38 AM, Maruan Sahyoun <sahy...@fileaffairs.de >>>>> wrote: >>>> >>>> you nailed it. The idea of the marketplace is to give up responsibility. >>>>> Apache Camel is responsible for the foundation (software, >>>>> infrastructure, >>>>> procedures). The component developer has responsibility for the >>>>> component. >>>>> >>>>> Maruan Sahyoun >>>>> >>>>> Am 20.02.2013 um 10:19 schrieb Christian Schneider < >>>>> ch...@die-schneider.net>: >>>>> >>>>> The idea of a common process and rules but separate owners for the >>>>>> components sounds good. We would have to discuss / agree on the details >>>>>> of course. This would then of course also imply that the camel >>>>>> community >>>>>> would not officially support the marketplace components. So rather each >>>>>> component would be supported by an individual group. >>>>>> >>>>>> Christian >>>>>> >>>>>> On 20.02.2013 10:04, Maruan Sahyoun wrote: >>>>>> >>>>>>> a discussion/decision how to handle components is independent of a >>>>>>> >>>>>> stable and thin core. I mentioned it only to have the 'layers' >>>>> complete. >>>>> The points you are making are very valid and as has been proven by >>>>> others >>>>> they can be addressed. What I wanted to introduce is the idea of not >>>>> being >>>>> responsible for all components themselves. Providing the 'marketplace' >>>>> and >>>>> procedures associated with it on the other hand should be handled by the >>>>> project. This way Apache Camel will provide the foundation from a >>>>> coding as >>>>> well as infrastructure/terms and procedures perspective. >>>>> >>>>>> I think jQuery is a good example of how that could be done >>>>>>> >>>>>> http://plugins.jquery.com/ . Take a look at the submenus >>>>> >>>>>> • Naming Your Plugin >>>>>>> • Publishing Your Plugin >>>>>>> • Package Manifest >>>>>>> >>>>>>> Kind regards >>>>>>> >>>>>>> Maruan Sahyoun >>>>>>> >>>>>>> >>>>>>> -- >>>>>> Christian Schneider >>>>>> http://www.liquid-reality.de >>>>>> >>>>>> Open Source Architect >>>>>> http://www.talend.com >>>>>> >>>>>> >>>>> >>> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> Talend Application Integration Division http://www.talend.com >> >>
