Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
8ebf78d
First draft of a /companies section.
rbowen Dec 28, 2025
26bb0ab
Flesh out some of the prose a little more
rbowen Dec 28, 2025
93a5d59
Structure, ALC
rbowen Dec 28, 2025
43bf90c
Expand slightly
rbowen Dec 28, 2025
0701c96
Fix formatting
rbowen Dec 29, 2025
12442a4
Draft prose around main points
rbowen Dec 29, 2025
6c8acdf
formatting
rbowen Dec 29, 2025
e746de2
Benefits of engagement
rbowen Dec 29, 2025
2a26e03
Try to incporporate some of Jarek's comments, which are no longer dir…
rbowen Dec 29, 2025
7375f46
Formatting of front page
rbowen Dec 29, 2025
250289a
Trying to be keep these intro blurbs as brief as possible
rbowen Dec 29, 2025
62b3851
formatting
rbowen Dec 29, 2025
29a5691
formatting
rbowen Dec 29, 2025
60fac07
better position the benefits section
rbowen Dec 29, 2025
8261e2c
less is more
rbowen Jan 2, 2026
80e3544
Phrasing change, thanks rich7420
rbowen Jan 2, 2026
1216891
TO BE WRITTEN
rbowen Jan 2, 2026
198e527
Adds a section about supporting non-employee contributors. Needs
rbowen Jan 2, 2026
f30f69e
Talks about proactively talking about what you're working on.
rbowen Jan 2, 2026
1034375
Typo
rbowen Jan 5, 2026
5d0c4bc
Sponsor/Intern orgs and programs
rbowen Jan 16, 2026
c25d7d3
First draft of advocacy page
rbowen Jan 16, 2026
629c9b2
Attempt to address Hen's question "So how do companies find these people
rbowen Jan 16, 2026
3c37e0b
... contracting with ...
rbowen Jan 16, 2026
ee3a202
... or contracting with ...
rbowen Jan 16, 2026
7721ff4
... or contractors ...
rbowen Jan 16, 2026
63b6c21
... or contractors ...
rbowen Jan 16, 2026
5dae375
apostrophe
rbowen Jan 16, 2026
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions source/companies/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
---
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

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.

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)
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

@potiuk potiuk Jan 2, 2026

Choose a reason for hiding this comment

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

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


[![employ](/images/company-employ.jpg)](/companies/employ.html)

Support ASF projects by employing, or otherwise financially supporting, developers, and other professionals,
who contribute directly to projects.<br />
[[Read more ...](/companies/employ.html)]
</div><!-- End Employ -->

<div class="col-md-4">
<!-- Sponsor -->

### [Financial Sponsorship](/companies/sponsor.html)

[![sponsor](/images/company-sponsor.jpg)](/companies/sponsor.html)

Sponsor the ASF, the Community Over Code conference, project events,
and local meetups.<br />
[[Read more ...](/companies/sponsor.html)]

</div> <!-- End Sponsor -->

<!-- Advocacy-->
<div class="col-md-4">

### [Advocacy](/companies/advocacy.html)

[![advocacy](/images/company-advocacy.jpg)](/companies/advocacy.html)

Companies can advocate for ASF project adoption both publicly and with
their customers, while appropriately using open source project brands.<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.*
53 changes: 53 additions & 0 deletions source/companies/advocacy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
title: Open Source Advocacy
url: /companies/advocacy.html
tags: ["companies", "advocacy", "branding"]
---

# Open Source Advocacy

Since the earliest days of the Apache Software Foundation, companies
have built their business and reputation around ASF projects, and we
have always encouraged that. We, in turn, depends on the good will of
companies. How companies speak about ASF projects is a critical part of
our public image.

## Respect Our Brands

Like any organization, the ASF has [Trademark
Policy](https://www.apache.org/foundation/marks/) which describes
appropriate and inappropriate ways to use the brand of the ASF, and of
ASF projects. We expect companies to familiarize themselves with these
policies, just as they would when working with another company or
partner.

## Be Proactive About Education

Be sure that anyone speaking on behalf of your company understands
and respects the [ASF Trademark
Policy](https://www.apache.org/foundation/marks/). Most violations of
these policies have historically come from company spokespeople who do
not understand the nature of the ASF, or of open source software, and
speak of our projects like just another of your company's products.

Be proactive about educating these individuals about appropriate ways to
speak about these projects. Use this website as a reference, and
encourage them to talk directly to projects if they have any questions
about how best to represent your work in and around these communities.

## Community First

When you mention ASF projects, we ask that you put the community first.
It's great to celebrate what your company and employees are doing in and
around ASF projects - we welcome and encourage that! - but be sure to
give credit where it's due. The community as a whole makes our projects
work, and contributes to your success.

Some companies make claims about their involvement in ASF projects that
imply that they own the project, or are primarily responsible for it.
Phrases like "creators of ..." or "primary contributors to ..." devalue
the work that the rest of the community does, and unfairly take credit
for the work that others have done to contribute to your success. We ask
that you not do that.


65 changes: 65 additions & 0 deletions source/companies/benefits.md
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@potiuk potiuk Dec 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

@potiuk potiuk Jan 2, 2026

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The 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?

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 your unique business differentiators.
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.*
Loading