incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Gmür <>
Subject Re: [DISCUSS] Mentor neutrality policy
Date Mon, 12 Oct 2015 13:52:01 GMT
That work under the assumption that all Jane has to deliver is a working
software. If the company is also interested in increasing its reputation by
allowing their marketing department to say thing like "We initiated the
Apache Foobar project", or "Apache OpenOffice natively supports our file
format" things become a bit more nuanced. Joining an existing community
might be more efficient code wise but less efficient marketing wise.

To bring a real example I was myself involved in: the incubation of Apache
Stanbol. Apache Stanbol comes out of a European Union funded research and
innovation project where multiple companies and research institutions where
involved. Graduating before the end of the funding period was clearly in
the interest of the project partners as this clearly was a success to
report at the final review meeting. On the other hand it might have been
better to wait till after the end of the funding period to decide on
graduation as this would have allowed to see which part of the code are
still maintained even without the funding. Without the financial/reputation
interest arising from the ongoing funded research the comparative
motivation of having the actually needed code in sustainable communities
would have been greater.


On Sun, Oct 11, 2015 at 10:29 PM, Ross Gardler <>

> I blogged on this topic some time ago - basically it is my opinion that if
> I am a good employee I would never try to contribute code to an Apache
> project that is not beneficial to the broader community. Such an action
> would be detrimental to her employers business. Consequently, there is no
> conflict between employer needs and community needs an ASF project.
> Here's a relevant excerpt:
> "Jane is paid to deliver results for her employer. If Jane finds that the
> best route to delivery is through community led open source she ought to
> fight for the survival of that community at all costs. It is in her
> interests to do so, both for her community reputation (employability beyond
> her current role) and for her employers satisfaction (employability in her
> current role). If Jane blows her community reputation she loses her ability
> to deliver for her employer as well as her ability to seek alternative
> employment relating to that community’s activities. A double whammy."
> Full blog at
> -----Original Message-----
> From: Reto Gmür []
> Sent: Sunday, October 11, 2015 9:53 AM
> To: general <>
> Subject: Re: [DISCUSS] Mentor neutrality policy
> On Sat, Oct 10, 2015 at 11:40 AM, Roman Shaposhnik <>
> wrote:
> > On Fri, Oct 9, 2015 at 6:07 PM, Daniel Gruno <>
> wrote:
> > > Hi Incubator folks,
> > >
> > > I would like to propose we adopt a mentor neutrality policy for
> > > incubating podlings:
> > >
> > > - A mentor must not be financially tied to the project or its
> > > incubation status.
> >
> > I'm very strongly -1 on this for two reasons. One fundamental and one
> > operational. Fundamentally, this goes against a core ASF principle
> > that we all collaborate here as individuals by checking our corporate
> > affiliation at the door.
> I think it's naive to think that just because the members are individual
> and corporate affiliations don't formally play a role there is no influence
> by the employer. When I'm paid by a company or government agency to work on
> an apache project I don't have an effective protection against the
> directives of my employer. Maybe if I refuse to follow an employer's
> instruction to write some code for an Apache project of which I'm committer
> I could not be fired without notice, maybe I could write the patch and say
> on the list that I wrote this patch for my employer but that as an
> individual PMC member I vote against it (did something like this ever
> happen?), whichever way I'm likely to act against my financial interest.
> In medical journals the author's are also writing in their own name, yet
> they must declare all competing interests. Following your logic such as
> declaration would be unnecessary if the journal says somewhere that authors
> leave their affiliation at the door.
> > IOW, we are explicitly granting our members and committers the trust
> > required to make sure they do the right thing while they themselves
> > (or their employees) can significantly benefit (financially and
> > otherwise) from the projects.
> >
> Even if we trust our commiters that they do not commit a hidden back door
> on behalf of the spy agency they work for, the conflict of interest can be
> much more subtle. The company has a deadline and a release of an apache
> project before that deadline would come in very handy, will you scrutinize
> the notice files at the risk of finding something that delays the release?
> If a main customer of my consulting firm is the main promoter of the XY
> file format, will I by neutral in choosing the best file format for the
> Apache Project I'm involved in? I probably really believe that XY is the
> way to go, but is should be an Apache rule that I declare that I have some
> financial ties to it.
> >
> > This is what makes ASF unique and anything that goes even slightly in
> > the direction of reducing this level of trust will have me up in arms
> > (regardless of whether it is related to Incubator or not).
> >
> > Operationally, this is extremely tricky to enforce. I speak here from
> > experience of somebody who has to be appreciative of the same set of
> > issues while consulting for companies and yet working for my current
> > employer. Even in a corporate world (where stakes are much higher from
> > legal perspective) this typically gets handled by trusting the
> > individual to do the right thing and disclose any potential conflict
> > of interest (financial or otherwise).
> >
> We would not have to ask people for their tax declaration, a self
> declaration of any potentially competing interest would do.
> Cheers,
> Reto

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message