Zeroth draft of a /companies section. #216
Conversation
|
|
||
| ## Ways to contribute | ||
|
|
||
| There are three primary ways that companies can engage with ASF |
There was a problem hiding this comment.
| There are three primary ways that companies can engage with ASF | |
| There are several primary ways that companies can engage with ASF |
There was a problem hiding this comment.
I fall victim of that far too often - specifying a number of things listed below is just very prone to get wrong when the list grows or shrinks.
source/companies/_index.md
Outdated
|
|
||
| [](/companies/sponsor.html) | ||
|
|
||
| Companies can provide crucial financial support through ASF sponsorship, in-kind donation of services, Community Over Code conference sponsorship, local meetup support, and direct contributor sponsorship programs. |
There was a problem hiding this comment.
Yes, I know that "direct contributor sponsorship" is here, but I think it's a very different thing for both contributors and companies, and it deserves a separate entry, because it introduces "maintainership" concept. Companies do not understand that OSS project need "maintenance". They only think in terms of "bugs" and "features". But "maintainership" is so much more and different than that and we need to be very precise - I think - on educating companies that it exists - not as the last point in the "Sponsor" part - especially that "supporting maintainers" is very different from "sponsoring".
source/companies/benefits.md
Outdated
| # Benefits of ASF Participation | ||
|
|
||
| Companies that actively participate in ASF projects realize significant strategic and operational advantages that extend far beyond cost savings. It's important to think strategically about how, where, and why you will participate and measure impact. It can be challenging to justify these benefits to management, as many of them are long-term. And these benefits will vary greatly depending on the nature of your business. | ||
|
|
There was a problem hiding this comment.
I moved the comments here. The first chapter is somewhat discouraging about the "short-term" gains, so I think it's worth to mention specific "short-term" gains the companies can have by establishing relationship with maintainers.
There was a problem hiding this comment.
I think some of those are listed below *establishing relationships" - but those are a bit "slogans" and if someone reads it, I think it should be clear what is the actual "gain" they have. I believe the first chapnter is the one that wil be read by somoene in the companies - to make quick decisions, the "details" below are nice but they do not show "what do I have" - for example "establishing relationship" does not ring "I save money" for corporate user. While "saving weeks of work" for your team "through establishing relationships" does.
There was a problem hiding this comment.
What change are you suggesting here?
There was a problem hiding this comment.
What change are you suggesting here?
I already did -> I moved all the changes above (from _index.md) to "benefits.md" Those are the suggestions I proposed - adding two more paragraphs under the original one which focused on the "long-term" benefits. The two paragraphs I proposed are focusing more on the short-term benefits and actual ways companies migh save money in shorter term (making their teams more productive)
There was a problem hiding this comment.
Sure, personal relationships are great, if you can find them/build them. But of far greater importance is establishing connections between the project and a corporate contributor (base). This feels like you are advocating some sort of intermediary to broker such connections with projects. I can see the benefits in the short term, but this set of documents is to help companies build their own relationships using open source and community best practices.
There was a problem hiding this comment.
I feel that for us (ASF) far greater benefit is to establish relationships between people - (for example employees of a company and maintainers). I do not want to introduce any intermediary, but to explain that companies can benefit for making their employees having good relationships with maintainers - even if they are not maintainers themselves. This is how it works in Airflow for example. As maintainers - we have great personal relationships with Amazon employees who contribute to Airflow, also with their management who contributes to the Airflow Summit.
And we work closely with those Amazon employees mainly because we have great relationship with them - not because they are Amazon employees. Same with Astronomer and Google.
We (PMC) vaalue Amazon, Astronomer and Google as stakeholders and we are grateful for them spending their energy and effort on Airflow. but we are not even supposed (as a PMC) to have relation with Amazon, Google or Astronomer. The best those companies can do (in relation to PMC) is to align incentives of their employees who are contributors and PMC members.
I think saying that PMC can have any "project direction" relationship directly with the companies - would be IMHO quite contradicting a lot of the "Vendor independence" in ASF. In ASF such relation should only be done through individuals who might or might not be employees, or even contractors of those companies. And I think we should be very clear about it.
This feels like you are advocating some sort of intermediary to broker such connections with projects.
Not sure what kind of intermediary we are talking about. PMC <-> individual contributor relationship is clear. PMC <> company relationship is essentially "should not happen". So if we are talking about PMC <> individual contributor <> Company relationship - the individual is intermediary. I do not see any other intermediaries here.
source/companies/benefits.md
Outdated
| Companies that actively participate in ASF projects realize significant strategic and operational advantages that extend far beyond cost savings. It's important to think strategically about how, where, and why you will participate and measure impact. It can be challenging to justify these benefits to management, as many of them are long-term. And these benefits will vary greatly depending on the nature of your business. | ||
|
|
There was a problem hiding this comment.
| Companies that actively participate in ASF projects realize significant strategic and operational advantages that extend far beyond cost savings. It's important to think strategically about how, where, and why you will participate and measure impact. It can be challenging to justify these benefits to management, as many of them are long-term. And these benefits will vary greatly depending on the nature of your business. | |
| Companies that actively participate in ASF projects realize significant strategic and operational advantages that extend far beyond cost savings. It's important to think strategically about how, where, and why you will participate and measure impact. It can be challenging to justify these benefits to management, as many of them are long-term. And these benefits will vary greatly depending on the nature of your business. | |
| However, such cooperation works in both directions and some of them are short term - when maintainers see company that is actively participating in the project, they are eager to help and solve problems that individuals from the company are raising. | |
| Personal relationships with maintainers also makes it possible to save even weeks of going in a wrong direction in your deployments, because maintainers will know your context and will be able to help to make better decisions. | |
There was a problem hiding this comment.
Ah, ok, I see. I think that these sentiments are reflected in the #avoid-conflicts section, and in the #attract-collaborators sections. Let me know what you think.
| # Benefits of ASF Participation | ||
|
|
||
| Companies that actively participate in ASF projects realize significant | ||
| strategic and operational advantages that extend far beyond cost savings. |
There was a problem hiding this comment.
I think the introduction in benefits.md is a great place to explicitly mention the value of influence through merit.
How about tweaking the first paragraph like this?
...advantages that extend far beyond cost savings. Key among these is the ability to influence the project's trajectory through employees who have earned committer status. It's important to think strategically...
There was a problem hiding this comment.
...advantages that extend far beyond cost savings. Key among these is the ability to influence the project's trajectory through employees who have earned committer status. It's important to think strategically...
I personally think this is quite against the spirit of the ASF to suggest that this way. Wth the Apache Way, the whole idea is that individuals act on their own behalf, and with the direction of the project not being "skewed" unnecessarily by the fact that the company employs committers and PMC members.
Of course that's a bit of idealistic approach to think that employees interests are neglected by their employees - that would be insane to think tihs is happening. However I think in this case this work in a bit of a different direction (Ideally - according to how ASF model of influence on the project should work).
I think by employing committers and PMC members, what company achieves is not "influencing the trajectory" directly, but making PMC members and committers incentives more aligned with the company interests.
There is a subtle difference there - as a company management you should not be able to "tell" those PMC members what to approve and what to not approve, you can tell them what is the overall direction the company is going and let those PMC members and committers decide what they do - whether it aligns with this direction, or not.
I think "influence the trajectory" might be understood more of "tell employees what changes they should implement and release" - which of course happens. But it has nothing to do with what "committer" status gives. Committers can "approve" things. Anyone can implement them. What you implement and submit as a PR to the project (as employee) is logically different thing that what you "accept" as a "committer". Your employee can tell you to "work on something" but they cannot tell you to "get something merged" - not formally and legally according to the ICLA every committer and PMC member signs.
There was a problem hiding this comment.
I really like your point about 'alignment of incentives.'
Perhaps we can frame it this way: Having employees who are committers ensures that the company's use cases and business context are deeply understood within the PMC. It’s not about a manager telling a committer what to merge (which violates the ICLA), but about the committer bringing a pragmatic, real-world perspective to the decision-making table. This naturally bridges the gap between the project's roadmap and the company's needs.
There was a problem hiding this comment.
I think it's a bit too detailed of a description that has no "i instantly understand it" vibe. I think this is what @rbowen also wants to achieve here (that's my understanding) that the message is "short" and "easy to grasp" even by somoene who does not understand how Open source works in detail - so this should be rather on a "slogan" side of things.
So in a sense "influence project trajectory" is a good "slogan" - even if ti can be a little too much crossing the "line" that ASF puts on the project decision making.
I would rather formulate it in a way that is positive, but also asserively sets the boundaries and is very "open" about communicating ASF position. For example:
"While companies, cannot directly influence direction of the project, when you hire committers and PMC members, their incentives are naturally more aligned with your company goals".
There was a problem hiding this comment.
"While companies, cannot directly influence direction of the project, when you hire committers and PMC members, their incentives are naturally more aligned with your company goals".
I like the alignment angle. Just a nit: Starting a 'Benefits' section with a negative ('While companies cannot...') might be less appealing. How about we flip it to focus on the positive 'bridging' aspect first?
There was a problem hiding this comment.
But companies can directly influence the direction of a project. That's something that we actively solicit, and should optimize for. I'm not a big fan of pretending that's not the case. It leads to pretty actively confusing companies. We ask them to participate, and scold them when they do. This entire set of documents is explicitly intended to combat that.
(Other remarks here seem to be about previous versions of this doc that no longer survive, so I'm not sure what they're in reference to. Perhaps another pass is warranted?
There was a problem hiding this comment.
But companies can directly influence the direction of a project.
I am not saying it's different. Quite the contrary. I am even proposing to explain how (by aligining incentives). What I am really telling that "influence the project" is ambiguous. And can be understood differently. There are quite a few projects that have more influence than what we want - maybe because we leave the "influence" up for interpretation. I think it should be clear that "people" have decision making power, where their decisions might be subject to having aligned incentives.
That leaves explicitly power for the people to decide, where companies might only do everything to make people incentivised, but not telling them what to do. I think being explicit is better than implicit here. Having explicit statement about it so that those people can simply send links to their employees - "look I am just following what ASF expects, and my decision is different than what you asked me to do" is very powerful for the individuals.
If we leave it as "influence", then the manager will be entitled to say "but ASF wrote that I can have influence, so they want you to follow what I tell you".
I think It's a chance to not be vague about it. But be very clear that we expect employees who contribute to ASF to make their own decisions. Just stating it at the page where we say "companies can have influence" does not seem a bad idea I think?
There was a problem hiding this comment.
I like the alignment angle. Just a nit: Starting a 'Benefits' section with a negative ('While companies cannot...') might be less appealing. How about we flip it to focus on the positive 'bridging' aspect first?
It might be cultural difference where I prefer to say "be careful, but do it" rather than "do it, but be careful". But I am perfectly OK with it as long as it is clear that the decision making stay with individuals who contribute - no matter their "employment/contracting" status. And that it's ok if their decisions are different than their employees/ This is where "aligining the incentives" play a big role - because it means that they cannot "expect" that people will follow their goals, but that they should make it so that their employees want to do so.
|
Thanks @rbowen! The only thing I can do is pick on a little grammar. I appreciate what you’ve provided. |
fleshed out. Talks more about ways to respect project independence. More about transparency, although I don't think we're done here yet.
| <!-- Employ --> | ||
| <div class="col-md-4"> | ||
|
|
||
| ### [Employ Contributors](/companies/employ.html) |
There was a problem hiding this comment.
Would love to see a different title used here as employing contributors directly has many issues.
There was a problem hiding this comment.
Perhaps this is a "Sponsor Individuals" and the next one is "Sponsor Projects"
There was a problem hiding this comment.
Would love to see a different title used here as employing contributors directly has many issues.
I do think we should mention employment as one of the options (contracting and sponsoring individuals as well) - becaue it's the fact and even welcome that many contributors, committers, PMC members are employees. This is a good thing - for example one that allows Airflow to thrive (amongst other things). But I think we should just be explicit about boundaries of the influence - this is what I wanted to clarify how much influence companies might expect (see my "aligining incentives" proposal).
|
|
||
| TO BE WRITTEN: | ||
|
|
||
| Focus on: |
|
|
||
| This goes [far beyond code contributions](/contributors/non-code.html), | ||
| although that is the most obvious and visible way that you can participate. | ||
|
|
There was a problem hiding this comment.
So how do companies find these people to support?
7 participants
This is far, far, far from complete, or even a first draft. Just making it public so that people can see what I'm working on.