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.
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.
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)
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. | |
| # 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.
|
Thanks @rbowen! The only thing I can do is pick on a little grammar. I appreciate what you’ve provided. |
|
|
||
| Advocating for ASF projects, while respecting the project's independence | ||
| and honoring the project's brands, can significantly drive adoption of | ||
| the project, which can advance your own company's business |
There was a problem hiding this comment.
| the project, which can advance your own company's business | |
| the project, which can advance your own company's business. |
| working in the same space. | ||
|
|
||
| And by collaborating with your peers on the common tasks, you'll be able | ||
| to better focus on what is your unique business differentiators. |
There was a problem hiding this comment.
| to better focus on what is your unique business differentiators. | |
| to better focus on your unique business differentiators. |
4 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.