Zeroth draft of a /companies section.

[rbowen]

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.

[potiuk]

Suggested change

	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.

[rbowen]

This is covered in the sub-page. The _index.md page is intentionally as terse as possible, with expansion on the sub-pages.

[potiuk]

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.

[potiuk]

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

[potiuk]

Suggested change

	There are three primary ways that companies can engage with ASF
	There are several primary ways that companies can engage with ASF

[potiuk]

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.

[potiuk]

Suggested change

	### [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 -->

[potiuk]

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.

[rbowen]

Yes, I believe this should be in employ.md

[potiuk]

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.

[rbowen]

I don't understand the distinction you're making here. Happy to have you write such a document if you want, though.

[potiuk]

A bit more explanation, long, but I hope it can clarify it:

Employee (prety much always by definitiion) has a non-compete agreemeent and cannot cooperate with other stakeholders. This is regular clause in employment contracts, and one that is even valid according to California Laws. The laws in California forbid Employers to restrict people to switch to competition, but it's standard (and kind of morally correct) to expect your employees to also cooperate - while they are employees - (and get some money from) with your direct competition. This is expected by all the laws about employment I saw. And main reasons I refused to be an employee of Astronomer for example.

When it comes to "supporting maintainers" rather than "employing them" - such "support maintainers" does not imply (and actually it makes no sense) to have a clause forbidding the maintainer to be supported by direct competition of the company that supports the maintainer.

I think there is a huge difference between the two - and one that makes individuals much more empowered in the whole process.

Like in my case - I am supported by Astronomer and Google - both pay me to be "maintainer". If I were an employee of either of those - that would be impossible to be paid by the other, because this violates the standard "non-compete" agreements. I could "work on Airflow" for free - but legally, i would not be able to be paid by the competitor. Not mentioning any other agreements I can have. Employment contract heavily limits usually who you can get paid from.

For me - personally - it gives a lot more freedom, flexibility and also independence - my sources of income come from several, independent stakeholders, legally allowed in the contracts I have, and I do not have to make my decisions making to account "what happens if I loose my single income source". Not that I ever had to face that choice - actually, the fact that I have different stakeholders supporting me, this means that my decsion making process is far less influenced by it.

It's basically the same dillemma that ASF as an organisation faces (and any other Foundation). If they have a single source of income - no matter how hard you try, if you are not ready to quit "now", basically the one who holds your single source of income has a real impact on the decisions you make. This is why important point of ASF is either to always have a way out or to diversify the funding. Both are good strategies.

This is the same with individuals - yes, the commitership and PMC membership is with you - but if you are not ready to quit at any time without fear when you are an employee, or if you do not have diverse source of income, then employer who at any point in time can say "Don't do it, or this is your last thing you do as our employee" - they can have an upper hand on decision making of such an individual.

This is very basic thing - diversification of the source of your income. This is basic thing when you are investing money, but also this shoudl be - IMHO - one of the basic strategues to maintain your independence. Being able to quit any time is also a good one, and combining the two - being able to quit AND diversify - is an ultimate "I make my own decisions, for what I think is best for the project" safety net.

And yeah I will push a more detailed fixup for that soon.

[potiuk]

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".

[potiuk]

added a suggestion

[potiuk]

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.

[potiuk]

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.

[rbowen]

What change are you suggesting here?

[potiuk]

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)

[potiuk]

That's the proposal:

[potiuk]

Suggested change

	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.

[chia7712]

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...