From the peanut gallery:
IMO, big corporations have enough money to get their names out there and
influence projects if they want to. So, it might be the best use of time to
find ways to limit the impact on the projects instead of trying to prevent them
from using their names. The ASF tends to like transparency, so hiding
corporate affiliation seems wrong.
The part-time volunteer is always going to have an uphill battle against
influencing a project against a bunch of full-time paid committers whether you
know their employers or not. The full timers will be able to influence the
project.
Isn't the real key to independence from corporations things like:
1) your committer rights move from job to job with you.
2) a commit should not be rejected based on business priorities, only technical.
Are there more?
Branding could dictate some policy to prevent a NASCAR uniform look to the
project's landing page, but since corporations are effectively contributing
significant money to the ASF by paying folks to commit code, why shouldn't they
deserve recognition? Could projects have their own Thanks page?
Lots of NOTICE files give attribution to the pre-Apache project owner. Why not
let other companies add their logo to NOTICE if it is important to them?
Maybe allow these two things and see if that makes the corporations happy.
Thanks,
-Alex
On 4/18/19, 4:06 PM, "Mark Thomas" <ma...@apache.org> wrote:
This is a tricky one.
If everything is working as it should, corporate affiliation is irrelevant.
However, employment is a factor in a number of different ways a project
can start to head in the wrong direction. For example, employees of a
company always giving priority to reviewing and committing the work of
colleagues to the disadvantage - and discouragement - of other
contributors/committers.
This sort of thing can be very hard to spot from the mailing list unless
you are closely following a project over an extended period of time.
Something that those providing oversight - the directors - do not have
the bandwidth to do for all 200+ projects. Even if an issue is raised by
someone familiar with the project it remains hard to spot for any
external person trying to review the situation.
It would be a lot easier to pick up on behaviours like the one I
described above if corporate affiliation was readily available. However,
making that information readily available has many downsides which have
been articulated by others in this thread already.
If feels a bit catch-22. If all is well, we don't need it. Having it
makes it easier to spot when things go wrong but also increases the
chances of things going wrong.
I don't have a solution to this. Possible options include:
a) adding current employer(s) to the private information we hold for
each committer so it is available to look up if there are concerns
b) asking for current employer(s) as part of investigating a concern
raised with the way a project was operating
c) leaving things as they are on the basis that the risk of harm exceeds
the benefit (I think it does for a and b)
Mark
On 18/04/2019 15:40, Jim Jagielski wrote:
> Yes. Corporate affiliation is really immaterial, and should be. Another
reason for this is that one's job may, and often does, change. Who you are, and
what you do, and how you provide "value" to a project, should not and does not.
To associate one's merit with one's employment means that every time one
changes jobs, it would/could have a major disastrous side-affect on one's place
in the project. For example, if the only reason why Zap Foobarski has merit was
because she was employed by Oracle, for example, and she was no longer employed
there, then it places an undue and unfair disadvantage on her and unfair
advantages on others. It is all about personal self-involved, self-motivated
interest. If that is supported or enhanced by one's employer, that is great.
But it is not a determining factor.
>
>> On Apr 17, 2019, at 9:49 PM, Phil Steitz <phil.ste...@gmail.com
<mailto:phil.ste...@gmail.com>> wrote:
>>
>>
>>
>> On 4/17/19 6:05 PM, Sam Ruby wrote:
>>> On Wed, Apr 17, 2019 at 6:04 PM Joan Touzet <jo...@apache.org
<mailto:jo...@apache.org>> wrote:
>>>> I'm generally in agreement with Rich, Jim, Shane, Sam and the other
>>>> "grey beards" who have responded on this thread already. We recognize
>>>> the individual, not the company, and the individual gets the merit.
>>> Meta comment: looking at the "grey beard" comments (including my own),
>>> I'm not impressed with how we collectively communicated (though Rich
>>> comes closest).
>>>
>>> This was a perfect opportunity to practice
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxkcd.com%2F1053%2F&data=02%7C01%7Caharui%40adobe.com%7C67dc17e1250d4ed7487608d6c4528130%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636912255968112678&sdata=0DMGMfO645aEwOLqgCk0e5E68mTbFCV5C3LOIPlKIB0%3D&reserved=0
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxkcd.com%2F1053%2F&data=02%7C01%7Caharui%40adobe.com%7C67dc17e1250d4ed7487608d6c4528130%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636912255968112678&sdata=0DMGMfO645aEwOLqgCk0e5E68mTbFCV5C3LOIPlKIB0%3D&reserved=0>.
>>> Instead many of the responses (again, including my own, and all
>>> presumably entirely unintentionally) could be taken along the lines of
>>> "you should have known" instead of "you're one of today's lucky
>>> 10,000".
>>>
>>> I'll try to do better with my response to this email. It won't
>>> contain WOO HOO levels of excitement, but hopefully a few people will
>>> feel like one of today's lucky 10,000.
>>>
>>> One of the things that makes the ASF different than other foundations:
>>> if many other foundations, a corporation can literally buy a seat on
>>> the board, and therefore get a say in the technical direction of
>>> foundation projects. I'm proud to say that that is not remotely a
>>> possibility here at the ASF. Corporations don't get a say in how we
>>> operate. Heck, board members (and Presidents) don't get to set
>>> technical direction.
>>>
>>>> That said, there are always rumours and scuttlebutt floating around of
>>>> this sort: "If company Q wasn't supporting Project X, Project X would
>>>> have died by now." Or: "Company J went out of business, so Project F is
>>>> basically abandoned." While industry insiders and project members
>>>> themselves are largely aware of these special situations, others
outside
>>>> of the community may not be.
>>> When I talk to people about incubation, what I typically say is that
>>> the goal of incubation is to ensure that the project survives should
>>> any company lose interest. Often times I am talking to people who
>>> work for my employer (IBM) who come in saying that of course it
>>> couldn't happen to the project we are talking about because it is
>>> /strategic/. I then point out any number of previously /strategic/
>>> projects that IBM once championed and later abandoned.
>>>
>>>> Gris, this is the flip-side of what you are proposing: making this
>>>> implicit knowledge more explicit. The danger in writing it down is that
>>>> it will change people's opinions of . By making these (sometimes
>>>> intentionally) nebulous relationships more concrete by putting them on
>>>> project home pages, you will necessarily impact how the project is
>>>> perceived, likely reducing its autonomy. Do we want to do this? I think
>>>> perhaps not.
>>> I will challenge this, using the flip side of the argument. Making a
>>> project homepage look like a NASCAR driver will, in the long run,
>>> embarrass a number of companies that once were backers of a project,
>>> but found that their priorities change. This is not theoretical. I
>>> often have meetings with some of those same people I talked to years
>>> ago about the purpose of incubation who want do things to set things
>>> right when their priorities inevitably change. The last thing we want
>>> to do is to embarrass them by pointing out that they are no longer
>>> active committers. I once was an active committer to Ant. Over time,
>>> I became less so. There was no single point in time when I stopped.
>>> And despite my departure, the project is still thriving. And in that
>>> case, neither my involvement or changing interests had anything to do
>>> with my employer.
>>>
>>>> One thing that's occurred to me in the past is: wouldn't it be nice to
>>>> know exactly who everyone on a given PMC works for, in the event of
>>>> "blocs" of voters banding together smelling fishy in terms of
projecthttps://xkcd.com/1053/ <projecthttps://xkcd.com/1053/>
>>>> independence?
>>> This comes up frequently, and the end result of the discussion
>>> generally is along the lines of:
>>> at most, that data should be taken as an indicator suggesting when
>>> deeper investigation is warranted. Even then, it should be something
>>> that should be a trigger for an investigation. It should be fishy
>>> behavior that triggers an investigation.
>>
>> +1 (minus the "thinko" he he)
>>
>> Another point on this. One thing that I have always loved about the ASF
is that identities here are built on what people do in our communities, not
"who they are." We don't currently force people to disclose employer or other
affiliations and I hope we never go there, partly because by doing so we will
have taken what should be irrelevant information and pushed it in front of
peoples' ASF identities.
>>
>> Phil
>>>
>>>> Then, on [5], I read this:
>>>>
>>>>> Apache projects are run solely by their PMCs, as projects independent
>>>>> of outside corporations or organizations. It is important to maintain
>>>>> both the actual independence of our PMCs from third parties, as well
>>>>> as to ensure that PMCs are clearly seen to be run as independent
>>>>> projects, free of any controlling, exclusive, or otherwise
>>>>> exclusionary relationships with third parties or outside
>>>>> corporations.
>>>> So again we have the problem of "writing it down may make it seem truer
>>>> than it really is," and creating the perception of people not knowing
>>>> how to take off their Corp hat and put on their PMC hat. We have to
>>>> balance this against the need for projects to have the assurances that
>>>> their PMC is acting neutrally. Right now, I think the only escalation
>>>> path is for the project to go to the Board if they feel the PMC is
>>>> railroading a project away from its best interests...and I'm still not
>>>> sure that doesn't put an unnecessarily high barrier in those
>>>> contributors' way.
>>> It's not perfect, and in the few times that it has occurred it has
>>> been quite messy, but you are correct that that is the escalation
>>> path. Not wanting to embarrass people (including myself when I
>>> inevitably mis-remember an important detail of a messy resolution),
>>> I'll refrain from commenting further. But this would make a good
>>> topic of conversation over one's choice of beverages...
>>>
>>>> But I digress.
>>> Thank you for doing so!
>>>
>>> - Sam Ruby
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
<mailto:dev-unsubscr...@community.apache.org>
>>> For additional commands, e-mail: dev-h...@community.apache.org
<mailto:dev-h...@community.apache.org>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
<mailto:dev-unsubscr...@community.apache.org>
>> For additional commands, e-mail: dev-h...@community.apache.org
<mailto:dev-h...@community.apache.org>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
