I agree that if someone works on a spec at OSGi alliance and on the impl
code at Apache then he will have an advantage over someone
who can only work on the code at Apache. This is a situation is not good.
The question though is what can we really do to improve this. I think it
is not possible to do spec work without doing the impl at the same time.
It would be like creating the full design of a system without writing
code. The design would be bad as the feedback cycle of actual usage
would be missing.
Forcing reference implementation out of Apache would be a bad choice in
my opinion. We as the Apache community gain a lot of indirect influence
on the specs by being able to review and comment the code changes early.
I think this outweighs the advantage some people have by being spec
designers and implementers at the same time.
I think the main problem really arises when the spec designer works on
the code, changes it in a way that is not reflected in the spec and when
asked about it replies : These changes will be reflected in the spec at
a later point. The problem with this is that it can end any discussion
as "the spec is always right".
So I think what we can do is apply certain rules for specs being
implemented at Aries or Felix. So one thing I can imagine is that
changes not reflected by the current publicly available spec have to be
done in a branch until they are reflected in the spec. We could also
require that the most current version of the spec and accompanying api
(source and binary) must be available. This rules would make sure that
the mater always reflects the current spec and that at least on master
people working on the impl are equal.
Of course the big question is if such rules would work in practice or if
they would just make working in the Apache project more difficult for
the spec designers. I would hate if in the end the specs would just be
implemented somewhere else without our community.
Christian
On 20.01.2017 10:58, Guillaume Nodet wrote:
The main difference here is that there are a lot of OSGi members who
believe in Apache, and therefore contribute as committers. Are we really
saying that those committers should be disallowed because they are OSGi
members and therefore have “more power”?
Not disallowed, but yes, they should not do something within the ASF that
other committers who are not OSGi members can't do.
So to be clear: if any committer want to work on an implementation of an
RFC or spec from the OSGi Alliance, that's fine, whether they are OSGi
members or not.
If an OSGi member want to work on spec design within the ASF bounds, I
think that's not fine. In particular, if someone propose to develop some
code to implement an RFC when the API from the developped and later
introduced back into the RFC document, I think that's definitely spec work,
and should not be done within the RFC.
To be crystal clear, I have a problem with Ray willing to bring code for
implementing rfc-193 in Aries, when the code that he wants to bring
contains lots of things that are not reflected in the RFC document and the
opposite. Ray and David explained that the RFC document will be updated in
the coming weeks to reflect those changes. This is definitely spec work,
and that's fine, but I don't think it should happen at Apache. Again, it's
a timing problem wrt to changes in the document and changes in the code :
if the code is changes first by the spec lead, and later validated on
during OSGi meetings and later integrated into the spec document and made
public, I definitely see that as spec work, not as building an
implementation, and imho this is unfair to other committers because it does
not follow the ASF rules. It's certainly open source, but not the Apache
way.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
