-
Notifications
You must be signed in to change notification settings - Fork 188
Best practice for companies around ASF projects #216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 14 commits
8ebf78d
26bb0ab
93a5d59
43bf90c
0701c96
12442a4
6c8acdf
e746de2
2a26e03
7375f46
250289a
62b3851
29a5691
60fac07
8261e2c
80e3544
1216891
198e527
f30f69e
1034375
5d0c4bc
c25d7d3
629c9b2
3c37e0b
ee3a202
7721ff4
63b6c21
5dae375
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,73 @@ | ||
| --- | ||
| title: Companies and Open Source | ||
| url: /companies/ | ||
| tags: ["companies", "business", "navigation"] | ||
| --- | ||
|
|
||
| # Why your company should participate in ASF projects | ||
|
|
||
| All modern digital infrastructure is dependent on open source software, | ||
| and **ASF projects are everywhere**. | ||
| Companies must think strategically about how they will engage with the | ||
| open source projects on which they rely in order to ensure | ||
| sustainability, and **influence the direction of these projects** for the | ||
| benefit of their customers. | ||
|
|
||
| ## [Benefits to Companies](/companies/benefits.html) | ||
|
|
||
| Active participation in open source projects provides significant | ||
| strategic and operational benefits to companies, including talent | ||
| acquisition, influence over industry standards, strong company | ||
| partnerships, and greater customer trust.<br /> | ||
| [[Read more ...](/companies/benefits.html)] | ||
|
|
||
| ## Ways to contribute | ||
|
|
||
| There are three primary ways that companies can engage with ASF | ||
| projects. Each has costs and benefits that should be carefully | ||
| considered. | ||
|
|
||
| <div class="row"> | ||
| <!-- Employ --> | ||
| <div class="col-md-4"> | ||
|
|
||
| ### [Employ Contributors](/companies/employ.html) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would love to see a different title used here as employing contributors directly has many issues.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Perhaps this is a "Sponsor Individuals" and the next one is "Sponsor Projects"
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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). |
||
|
|
||
| [](/companies/employ.html) | ||
|
|
||
| Support ASF projects by employing developers, and other professionals, | ||
| who contribute directly to projects. This includes code | ||
| contributions, documentation, community management, testing, design, and advocacy work.<br /> | ||
| [[Read more ...](/companies/employ.html)] | ||
| </div><!-- End Employ --> | ||
|
|
||
|
rbowen marked this conversation as resolved.
|
||
| <div class="col-md-4"> | ||
| <!-- Sponsor --> | ||
|
|
||
| ### [Financial Sponsorship](/companies/sponsor.html) | ||
|
|
||
| [](/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 support programs.<br /> | ||
| [[Read more ...](/companies/sponsor.html)] | ||
|
|
||
| </div> <!-- End Sponsor --> | ||
|
|
||
| <!-- Advocacy--> | ||
| <div class="col-md-4"> | ||
|
|
||
| ### [Advocacy](/companies/advocacy.html) | ||
|
|
||
| [](/companies/advocacy.html) | ||
|
|
||
| Companies can advocate for ASF project adoption both publicly and with | ||
| their customers, while appropriately using open source project brands | ||
| and promoting the value of community-driven development.<br /> | ||
| [[Read more ...](/companies/advocacy.html)] | ||
| </div> <!-- End Advocacy--> | ||
| </div> <!-- End Row --> | ||
|
|
||
| *The Apache Software Foundation welcomes corporate participation that aligns with our mission of providing software for the public good.* | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| --- | ||
| title: Open Source Advocacy | ||
| url: /companies/advocacy.html | ||
| tags: ["companies", "advocacy", "branding"] | ||
| --- | ||
|
|
||
| # Open Source Advocacy | ||
|
|
||
| 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 | ||
|
rbowen marked this conversation as resolved.
Outdated
|
||
|
|
||
| While it's fine to associate your company's name and reputation with an | ||
| ASF project, you must do it in ways that don't confuse or mislead the | ||
| public about the project's independence. | ||
|
|
||
| Be sure your marketing department understands and respects the [ASF Trademark | ||
| Policy](https://www.apache.org/foundation/marks/). | ||
|
|
||
| [... To Do ...] | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,65 @@ | ||
| --- | ||
| title: Benefits of Open Source Participation | ||
| url: /companies/benefits.html | ||
| tags: ["companies", "benefits", "business value"] | ||
| --- | ||
|
|
||
| # Benefits of ASF Participation | ||
|
|
||
| Companies that actively participate in ASF projects realize significant | ||
| strategic and operational advantages that extend far beyond cost savings. | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the introduction in How about tweaking the first paragraph like this?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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".
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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. |
||
| It's important to think strategically about how, where, and why you will | ||
| participate and measure impact. | ||
|
|
||
| ## Influence the roadmap | ||
|
|
||
| While it can sometimes take months, or years, to gain expertise and | ||
| trust in an established community, showing up to do the daily | ||
| project maintenance -- issue and PR triage; reviewing PRs; planning and | ||
| executing community events; answering user questions -- you'll quickly | ||
| begin to establish that you can be trusted, which will make it easier | ||
| for you to influence the direction of the project. | ||
|
|
||
| Decisions about the direction of Apache projects are made by the people | ||
| who show up to participate in the conversation. If you don't join the | ||
| conversation, then your competitors will decide how tomorrow's | ||
| technology will shape up. | ||
|
|
||
| Make sure someone on your team is reading the project [mailing | ||
| lists](https://www.apache.org/foundation/mailinglists.html) every day, | ||
| and advocating for your priorities. That's what community means -- | ||
| showing up to own the future of the project. | ||
|
|
||
| While trust does not necessarily transfer to other employees, over time, | ||
| as project participants see your company actively contributing to the | ||
| project, and demonstrating ownership, they'll be more willing to work | ||
| with you. | ||
|
|
||
| ## Recruiting | ||
|
|
||
| By working upstream on projects, you directly showcase to potential | ||
| employees what they might be working on. This helps attract the right | ||
| kind of talent to work on your priorities, and they'll begin to see your | ||
| company as a partner in the project, and an attractive place to work. | ||
|
|
||
| Being involved in the day-to-day life of the project | ||
| gives you direct access to the most qualified people in the world to | ||
| work on your team. And you know they'll be arriving with the skills you | ||
| need. | ||
|
|
||
| ## Business and Strategic Advantages | ||
|
|
||
| For more than 25 years, the ASF has been a place where industry | ||
| standards have been set and implemented. Collaborating in those | ||
| projects is the most effective way to shape industry standards and best | ||
| practices. You'll be building trust with current and potential | ||
| customers, and building strategic partnerships with other companies | ||
| 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. | ||
|
rbowen marked this conversation as resolved.
Outdated
|
||
| Collaborate on what all share; Compete where you excel. | ||
|
|
||
| *The benefits of open source participation compound over time, creating | ||
| sustainable competitive advantages and fostering innovation that drives | ||
| long-term business success.* | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,76 @@ | ||
| --- | ||
| title: Employing Open Source Contributors | ||
| url: /companies/employ.html | ||
| tags: ["companies", "employment", "contributors"] | ||
| --- | ||
|
|
||
| # Employing Open Source Contributors | ||
|
rbowen marked this conversation as resolved.
Outdated
|
||
|
|
||
| If your business relies on an open source project, employing | ||
| contributors to the project is the most effective way to ensure that | ||
| your priorities influence project decisions. (See | ||
| [Recruiting and Employee Satisfaction](/companies/benefits.html#recruiting-and-employee-satisfaction)) | ||
|
|
||
| This goes [far beyond code contributions](/contributors/non-code.html), | ||
| although that is the most obvious and visible way that you can participate. | ||
|
|
||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So how do companies find these people to support?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I feel like this starts with ownership. If you believe that investing in a project is critical to your company, then you hire people to do that work, just like you would with any product you were going to take to market. Viewing open source as somehow fundamentally different than an in-house software development project is the root of many antipaterns in how companies interact with open source. They're really the same thing.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Or - again let me repeat it - you might look for getting a maintainer on another type of contract, not employment. For many companies, this is often a decision to make (and there is a significant difference):
This has very different properties - starting from non-compete (mentioned), going through much more flexible part-time or even hourly-based or task-based contract models. In case of contracting non-employees - for example - companies might even use 3rd-parties (such as Tidelift, HeroDev and many similar) to setup those relationships - and this is not employment - in very strict legal sense of it. And it actually might help to solve the "how do companies find those people" - because they can do that through those third parties (and many already do). Employment has very concrete definition and a lot of limitations - other forms of contract can be much more flexible. I would strongly advocate for making it clear that "employment" is not the only way companies might make maintainers get money - and I am not really sure why this seems to be a controversial thing to add those form of contracts explicitly (it seems pretty obvious - both, that is happening already and that is very distinct from employment). |
||
| ## Effective ways to contribute | ||
|
|
||
| While many companies contribute here and there to open source projects, | ||
| having a carefully considered strategy for doing so will lead to more | ||
| consistent, measurable results, and greater influence in the project's | ||
| decisions and roadmap. | ||
|
|
||
| ### Allocate Dedicated Time | ||
|
|
||
| Earning trust in open source projects takes consistent engagement, and | ||
| visibility to the community. Thus, having guaranteed dedicated time to | ||
| focus on upstream work will result in better long-term results. | ||
|
|
||
| Giving employees a specific time allocation - 10-20% of their schedule | ||
| is typical - will ensure that they remain visible to the community, and | ||
| are able to have focused time to build their skills. | ||
|
|
||
| Trust earned by one contributor does not necessarily rub off on your | ||
| other employees. So don't assume that you can just swap out one employee | ||
| for another. | ||
|
|
||
| ### Recognize Contributions | ||
|
|
||
| Include open source contributions in performance reviews and career | ||
| advancement considerations. Define specific metrics, such as PRs | ||
| accepted, reviews, public speaking engagements, or promotion to | ||
| committer or PMC member, which are tied to promotion opportunities. This | ||
| will help employees feel appreciated, and communicate that engagement in | ||
| open source projects is not considered charity or altruism, but is a key | ||
| part of company goals. | ||
|
|
||
| ### Support Conference and Meetup Participation | ||
|
|
||
| Fund employee attendance at relevant conferences and encourage speaking | ||
| opportunities. Understand that attending conferences is primarily about | ||
| creating opportunities to collaborate with peers, and this, in turn, | ||
| will accelerate your business priorities. | ||
|
|
||
| ### Respect Project Independence | ||
|
|
||
| Take time to understand ASF ethos, the [ASF Trademark | ||
| Policy](https://www.apache.org/foundation/marks/), and the reasons why | ||
| we value project independence. Trust takes a long time to earn, but can | ||
| be burned very quickly by misusing a project's brand. | ||
|
|
||
| Ensure contributions align with long-term project goals rather than | ||
| solely short-term company priorities. That ensures that the project as a | ||
| whole remains healthy. | ||
|
|
||
| ## Getting Started | ||
|
|
||
| 1. Identify projects your company already uses or depends on | ||
| 2. Connect with existing contributors in your organization | ||
| 3. Start with small, manageable contributions | ||
| 4. Build relationships within project communities | ||
| 5. Gradually increase involvement and responsibility (See [Becoming a | ||
| committer](/contributors/becomingacommitter.html)) | ||
|
|
||
| Companies that invest in employing open source contributors create a sustainable model that benefits the entire ecosystem while building internal expertise and community relationships. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,42 @@ | ||
| --- | ||
| title: Financial Sponsorship of Open Source | ||
| url: /companies/sponsor.html | ||
| tags: ["companies", "sponsorship", "funding"] | ||
| --- | ||
|
|
||
| # Financial Sponsorship | ||
|
|
||
| The sustainability of our projects relies on consistent funding for | ||
| infrastructure, legal services, marketing, events, and many other | ||
| expenses. Financial sponsorship is a direct way to participate in | ||
| keeping the lights on. | ||
|
|
||
| ## ASF Sponsorship | ||
|
|
||
| Companies can sponsor the ASF with an [annual | ||
| donation](https://apache.org/foundation/sponsorship.html), | ||
| [conferences sponsorship](https://communityovercode.org), | ||
| targeted donations to a particular project, or in-kind donations of | ||
| products or services. | ||
|
|
||
| ## Event and meetup sponsorship | ||
|
|
||
| In addition to the [main ASF conference](https://communityovercode.org), | ||
| many ASF projects have their own events. These are usually listed on | ||
| [events.apache.org](https://events.apache.org), and announced within the | ||
| project community itself. | ||
|
|
||
| Sponsoring, and speaking at, these events, is perhaps the fastest way to | ||
| raise your profile in a project community, and for your employees to | ||
| earn trust and visibility within the project. | ||
|
|
||
| Supporting local gatherings of open source enthusiasts is a great way to | ||
| foster community growth, and can help your company attract and retain | ||
| experts in your employ. | ||
|
|
||
| See also the [Apache Local | ||
| Communities](https://cwiki.apache.org/confluence/display/COMDEV/Apache+Local+Community+-+ALC) | ||
| for local and regional groups where you can engage with other ASF | ||
| enthusiasts. | ||
|
|
||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.