Zeroth draft of a /companies section. #216
Conversation
source/companies/_index.md
Outdated
|
|
||
| ## [Benefits to Companies](/companies/benefits.html) | ||
|
|
||
| Active participation in open source projects provides significant strategic and operational benefits to companies, from talent acquisition to technology innovation and market positioning. |
There was a problem hiding this comment.
| Active participation in open source projects provides significant strategic and operational benefits to companies, from talent acquisition to technology innovation and market positioning. | |
| Active participation in open source projects provides significant strategic and operational benefits to companies, from talent acquisition to technology innovation and market positioning. | |
| Such cooperation works in both directions - 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.
This is covered in the sub-page. The _index.md page is intentionally as terse as possible, with expansion on the sub-pages.
There was a problem hiding this comment.
I think this chapter shold have few things that are "corporate speak" - mentioning direct savings companies might have by dedicating the peoople to open-source is crucial. Almost no company will be incentivised in investing in something that will make "industry better" - we need to find ways to explain it in terms of "direct savings" for those who are supposed to invest their money.
It is a very unappreciated effect of "being" in the open-source community, that you start to be respected by those who know most and can more eagerly share their knowledge. I have a great customer, that I work with for almost 4 years, and I literally saved weeks of their whole team's time by a weekly hour conversation with them. We need to make companies aware that their teams will be far more efficient if they will be respected by the community and recognised as contributors. It's not obvious, but very real in my opinion.
There was a problem hiding this comment.
This is covered in the sub-page. The _index.md page is intentionally as terse as possible, with expansion on the sub-pages.
Sure I can suggest it in the sub-page
|
|
||
| ## 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.
| ### [Employ Contributors](/companies/employ.html) | ||
|
|
||
| [](/companies/employ.html) | ||
|
|
||
| The most impactful way companies support open source is by employing developers and other professionals who contribute to projects. This includes not just code contributions, but documentation, community management, testing, design, and advocacy work. | ||
| </div><!-- End Employ --> | ||
|
|
There was a problem hiding this comment.
| ### [Employ Contributors](/companies/employ.html) | |
| [](/companies/employ.html) | |
| The most impactful way companies support open source is by employing developers and other professionals who contribute to projects. This includes not just code contributions, but documentation, community management, testing, design, and advocacy work. | |
| </div><!-- End Employ --> | |
| ### [Employ Contributors](/companies/employ.html) | |
| [](/companies/employ.html) | |
| The impactful way companies support open source is by employing developers and other professionals who contribute to projects. This includes not just code contributions, but documentation, community management, testing, design, and advocacy work. | |
| </div><!-- End Support --> | |
| ### [Support individual contributors](/companies/support.html) | |
| [](/companies/support.html) | |
| Another impactful way companies support open source is by financially supporting individual maintainers who maintain the projects. Maintainership often means a lot of work that is not easily classified as "new features" or "bug fixes" - there is a lot of thankless but necessary work needed in successful projects that maintainers do - making releases in a smooth and predictable way, continuous update of dependencies, reacting to security vulnerabilities, mentoring and "recruiting" new contributors, spreading the word about the project, triaging issues, reviewing PRs, improving documentation and a lot more. | |
| Supporting people financially (via B2B contracts, Individual Sponsorships, Fellowships) makes it possible for the Open Source community to keep their projects healthy and proactively addresss issues before they even happen. Think of regular checkups at the doctor being far more effective than going to the doctor when you start experiencing problems. | |
| . | |
| </div><!-- End Support --> | |
There was a problem hiding this comment.
Happy to move some of the description to "support.html" - I just think it should be created first so that I can comment on it in the PR.
There was a problem hiding this comment.
Yes, I believe this should be in employ.md
There was a problem hiding this comment.
How about separate one (support.md) ? For me employment is completely different than "supporting maintainers" who are not employees. For one employment practically excludes being supported simultaneously by competitors, while supporting maintiners does not. I would like to expand on that -and explain the difference in more datail.
There was a problem hiding this comment.
I don't understand the distinction you're making here. Happy to have you write such a document if you want, though.
There was a problem hiding this comment.
Suggesting that full-time employees cannot make decisions that balance the project with their employer is contrary to my experience at the ASF. I've put a "Support individual contributors" section in employ.md because I think that it's just a nuanced difference over full-time employes, and not "completely different", as you state here. Indeed, my ENTIRE GOAL with this set of documents is to help companies foster open source contribution in a project-first way, and stating that one can ONLY do this as an independent contributor is diametrically opposed to that message. So I'm ... reluctant. Perhaps you can convince me.
There was a problem hiding this comment.
This is not universally true. Some companies have explicit permission to participate in any open source project, regardless of who is participating (competitor or not).
It's not about participating in open-source projects but about being paid by competition. I can't imagine an employment contract where it's ok, where competitor of your employer allows you to be paid by their competitor. This is pretty much always forbidden (and considered conflict of interests).
There was a problem hiding this comment.
Suggesting that full-time employees cannot make decisions that balance the project with their employer is contrary to my experience at the ASF.
I do not mean suggesting that. I just merely say that not being employed gives you more freedom (for example the above freedom to be paid by competitor). I negotiated in my contracts with all my customers that it's ok if their direct competition pay me as well. I have not seen an employment contract where this would be allowed and welcome.
and stating that one can ONLY do this as an independent contributor is diametrically opposed to that message. So I'm ... reluctant. Perhaps you can convince me.
I was very careful to NOT say it this way. I only stated that it's different and gives individual more "income" safety (for example by the fact that you can get money from competitors). But I am absolutely aware that it's not the only way. Vast majority of people who are paid for OSS work are paid by their employees - I am fully aware of it. But I would like to make it clear that it's not the only way. Similarly as you do not want to say that the only way is to be independent, I want to state that it's not the only way to get paid to be employee.
It's very symmetrical IMHO, both are valid and have different set of incentives, freedoms and motivations.
There was a problem hiding this comment.
BTW. there are different ways that companies can pay maintainers without entering the employment status -> for example Tidal. GitHub Sponsors (I have been paid a nice one-time sum from Amazon few years back for example - without ever entering any business relationship with Amazon). I think - if we are recognizing "employment" for "individual contributors" - not recognizing all those options (which are different than sponsoring) - would simply miss out on making it a clear and possible option to follow - and for both parties, individuals, and companies.
I truly hope that by recognizing it as a "possibility" by the ASF will allow both individuals an companies to pursue it much more "vigorously" - and with more legitimacy.
I think having more options to follow that are "OK" is better than less - because it limits a number of cases where people do not want or "can't" enter employment relationship, or by companies that have different budgets and processes for "employees" vs. "contractors".
There was a problem hiding this comment.
BTW2. If there were "nuanced" difference of employees vs. contractors - why do we have those two terms at all? Also - in most EU countries, the non-compete agreements are mandatory for employees. So basically when you are an employee - non-compete is basically "given" by the status of employment contracts (even if not specified in the contracts) - for contractors, it is solely question of agreement between parties.
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?
6 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.