On 4/17/19 6:05 PM, Sam Ruby wrote:
On Wed, Apr 17, 2019 at 6:04 PM Joan Touzet <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://xkcd.com/1053/.
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/
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
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
