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://xkcd.com/1053/ >> <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/ <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>
