community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ruggeri <>
Subject Re: [Discuss] Attributing contributions to commercial vendors investing in projects
Date Fri, 19 Apr 2019 14:20:42 GMT

On 4/19/2019 12:06 AM, Alex Harui wrote:
> 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?
Hey there! That's my queue :-)

<hat type="VP Fundraising>
Yes! It is totally OK for projects to have their own thanks page.
Fundraising *especially* encourages it for targeted sponsorships[1]
directed to the project. Note the term "encourage". We do not require
projects to recognize nor dictate the way projects recognize such
donations... we just like to point out that it's a great idea to let our
sponsors know how much we appreciate them.

Fundraising does not have a position on whether a project should
recognize non-individuals for code donations.


Daniel Ruggeri

> 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" <> 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 < <>>
>     >>
>     >>
>     >>
>     >> On 4/17/19 6:05 PM, Sam Ruby wrote:
>     >>> On Wed, Apr 17, 2019 at 6:04 PM Joan Touzet < <>>
>     >>>> 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;;sdata=0DMGMfO645aEwOLqgCk0e5E68mTbFCV5C3LOIPlKIB0%3D&amp;reserved=0
>     >>> Instead many of the responses (again, including my own, and all
>     >>> presumably entirely unintentionally) could be taken along the lines
>     >>> "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
>     >>>> this sort: "If company Q wasn't supporting Project X, Project X
>     >>>> 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
>     >>>> 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
>     >>>> project home pages, you will necessarily impact how the project
>     >>>> 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
>     >>> 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
>     >>>> know exactly who everyone on a given PMC works for, in the event
>     >>>> "blocs" of voters banding together smelling fishy in terms of project
>     >>>> 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
>     >>>>> 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
>     >>>> 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
>     >>>> balance this against the need for projects to have the assurances
>     >>>> 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
>     >>>> railroading a project away from its best interests...and I'm still
>     >>>> 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: <>
>     >>> For additional commands, e-mail: <>
>     >>>
>     >>
>     >>
>     >> ---------------------------------------------------------------------
>     >> To unsubscribe, e-mail: <>
>     >> For additional commands, e-mail: <>
>     > 
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail:
>     For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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