It seems either I have a hard time explaining myself, or you're all blind. I'll suppose the first one, so I'll try again.
Let's say someone comes to aries or felix saying: "i'd like to work on a RI for the xxx rfc". At this point, that's fine if the RFC is kinda frozen. Let's imagine it's not, and the api package is changed to play a bit with latest EEG phone calls. Only OSGi Alliance members can freely modify the API packages to reflect those changes. Worse, someone can make a change in the API to be latter approved by the OSGi Alliance. There's clearly a difference between apache committers who are OSGi members and those that are not. Some of them can make changes, others don't. It looks like a problem to me. Another concrete example is if someone comes to one ASF project saying: "I'd like to contribute this implementation of the RFC. Btw, the RFC document does not yet reflect the changes in the RI, but it will soon". Guillaume 2017-01-18 15:15 GMT+01:00 Carsten Ziegeler <cziege...@apache.org>: > Guillaume Nodet wrote > > > >> There is no difference? Really? Claiming the current approach is not > >> optimal from a community perspective is certainly not unreasonable, but > >> saying that the community doesn't benefit at all from having draft > >> implementations being worked on at Apache seems like a stretch. > > > > > > Can you outline the benefits then ? Honestly, I don't see the difference > > between such an implementation being developed at Apache and the same one > > being developed under the same license at github. At github, I can also > > fork, provide PR, raise issues, etc... > > > Why is github the alternative to Apache? If my work is not valued by the > Felix community I have no incentive to do it at github. It would rather > be company internal or maybe at the Eclipse foundation. > > > > > > Shaping future evolution is definitely a privilege of OSGi Alliance > members > > and again, I have no problem with that part. The problem is not whether > > OSGi members have more information or not, it's whether non OSGi members > > have enough information or not to implement a spec. When the > > implementation is used as a play ground for the spec design, that's > > definitely not true. > > > I've written some of the implementations of the current RFCs and believe me > the RFC document is all you need. And if not, there are the mentioned > channels > to ask for clarifications. > > > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/