layout: true name: fullheader background-image: url(../client/img/david-lezcano-120708-169.jpg) background-size: cover

layout: true name: flockbottom background-image: url(../client/img/shwetha-shankar-137724-169.jpg) background-size: cover

layout: true name: palmsbottom background-image: url(../client/img/jeremy-bishop-257105-169.jpg) background-size: cover

layout: true name: treeright class: inverse background-image: url(../client/img/meduana-178155-169.jpg) background-size: cover

layout: true name: beachbottom background-image: url(../client/img/alexandre-perotto-46114-169.jpg) background-size: cover

layout: true name: pineapple background-image: url(../client/img/pineapple-supply-co-64690-169.jpg) background-size: cover

layout: true name: seashell class: inverse background-image: url(img/biel-morro-_l8ZdgJ9m7w-169.jpg) background-size: cover

layout: true name: closing background-image: url(../client/img/deborah-kunzie-49758-169.jpg) background-size: cover

layout: true name: thanks background-image: url(../client/img/stuart-guest-smith-150560-169.jpg) background-size: cover

layout: true name: menu background-image: url(../client/img/lance-asper-153777-169.jpg) background-size: cover

layout: true name: logorb class: left background-image: url(img/ComCodeLogo.png) background-repeat: no-repeat background-position: bottom .8rem right 5rem background-size: 10%

The Practical Apache Way

Effective Open Source Project Management

@ShaneCurcuru

Slides and Speaker Notes

]

What Is The Apache Way?

The Apache Way is a set of collective behaviors.

??? High level intro: the Way is a set of general behaviors that focus on how communities of people can work together.

These aren’t hard and fast rules; there’s no magic way to follow the way. These are behaviors that the whole community should adapt and model over time to really see the benefits.

Why Follow The Apache Way?

The Apache Way is designed to promote:

long-lived projects
serving the public good
community-led governance
welcoming new contributors
maintaining vendor neutrality

These behaviors are expected in ASF projects.

??? High level intro, mention concepts: community, openness, merit, consensus. Purpose is for long-lived projects run collaboratively.

These behaviors can serve any open community interested in longevity. They are not necessarily optimized for speed of development or any particular technical strategy; rather they are optimized for building and maintaining dispersed communities of collaboration.

What should we talk about next?

Community - over Code
Merit - recognizing your work
Open Development - for everything
Decision Making - consensus & votes
Communication - how we write
Charity - our mission
Questions To Answer

??? Community Over Code also means that You Need To Participate.

Each of these is a set of topics about a group of collective behaviors that focus on specific techniques to help collaboration.

What do you want to talk about?

Note: there’s an obvious first topic to cover!

Community

Community

What do we mean by community here?
- We don’t live together
- We don’t work together
- We don’t know each other
Except through this project

??? What does community mean here? Working on an independent open source project is very different than most other human activities. There are no other ties between project contributors who are widely distributed in location, in time, in experience, and in jobs outside our project itself. SPACEBAR

–

Community includes developers, writers, testers, sysadmins, devops, marketing, conferences… and users.

??? We should focus on an entire project community - all of us working to create or improve this specific projects in some way, and all the end users who come by with questions or bugs or improvements. The important thing is that the community owns our project. Not you, not me, not your company. All of us, together.

Having a shared sense of communal ownership keeps the work aligned in ways that make it clear users with fixes or new ideas will be accepted, and they might become a committer or PMC member with binding input in a project someday. Also: while contributors may be on other projects as well, many participants will only know you from one project.

Wear Your Hats

You are an individual here - not an employee
All participation is by individuals - not companies
Individuals get recognition
- Side effect for corporate teams: each employee participates separately
- Side effect for you: your merit stays with you across jobs

??? The ASF does not allow direct corporate participation in projects.
The ASF recognizes individual contributions. Merit accrues to individuals, and they are expected to act appropriately within each project community as an individual, not as an employee.

“Wearing your hat” may be a polite fiction - many employment agreements require putting employer interests first - but it’s a key part of Apache projects.

This ensures that newcomers - from big employers or small ones - are welcome in our projects, and also means that the merit you gain in an Apache project stays with you, no matter where you work. That helps encourage long-lived participants, across jobs, and allows those with deep expertise in Apache projects a better chance to continue their contribution over time.

Check Job Titles At The Door

Job titles don’t apply in projects
No hierarchy in community
Projects don’t have hierarchy
- Each project is separate
- Each PMC member gets one vote

“It’s not a hierarchy, it’s a community”

??? Wearing your project hat means you’re acting on behalf of the project as a whole, not your employer. Sometimes you need to do things as an employee; that’s fine. But mark it clearly, and when voting on serious project decisions, wear your project hat.

Yes - this sometimes means as an employee, you may be collaborating on a specific project technology with employees of your corporate competitors. This is fine - in fact, it’s part of why Apache is called the Switzerland of open source; we are the vendor-neutral place were everyone can work together on specific technologies.

In any case: please do thank your employer (when appropriate) for giving you time to contribute back to ASF projects!

Independent Governance

PMCs are community-led governance
- ASF projects are vendor-neutral
ASF owns the trademarks
- ASF board ensures neutrality

??? The net effect of all the above is that projects are governed for the public good and the best interests of the project community as a whole.

PMCs are expected to make releases and vote in new committers based on how many positive contributions individuals make in the project, not on their employer or background.

When PMCs slack in their duties, the board is here to provide oversight and if necessary, correction. Both at the PMC level and the board level we expect people to act for the public good - and the fact we are a 501C3 organization, with directors elected from merit - not sponsor dollars - means we can back it up.

It’s rare, but the board can and will step in if a commercial company is abusing their influence within an Apache project; we also have a Vice President of Brand Management who addresses trademark issues.

Merit

Take a different way?

Continue Onward?

What YOU Have Done

The contributions you have brought to the specific project, as defined in the context of that project by that community.

“You gain merit by doing things the community values”

??? Merit at the ASF is often misunderstood, and perhaps (in retrospect) it wasn’t the best term to choose. But the meaning here is specific, and is focused on actual project contributions, not employment, background, or other personal characteristics.

Your merit is the value you bring to a project as judged by that project’s community.

Every project is its own merit structure. Merit is not transferable, and it doesn’t expire. It may get stale through inactivity, but it stays with you through jobs and careers. If you come back to a project after being away, you’ll still be a committer.

Growing Your Scope

The more you do, the more power you may be granted to take actions:

User
Contributor
Committer
PMC Member
PMC Chair / VP
ASF Member
Director

??? Each step is defined by the merit you are recognized for by that specific community. Each step means you can get a vote on new tasks, in the context of that community.

The key steps are being a committer - changing code yourself - and being a PMC member - voting on releases or new committers on that project.
Most of the other levels are about visibility and having a say, but not necessarily having a deciding vote.

In particular, Project VPs / Chairs of their PMC don’t have any extra votes; their duties are really about communicating issues to the board. At the Membership level, you have a say in the Foundation, but not the projects.

Merit is Not Authority

Leaders versus Managers

“Merit grants privileges - commit, binding votes”

“Merit is not authority - community makes decision”

??? You are still part of the community - it’s not a hierarchy; everyone with merit (commit bit) has a chance to influence the consensus in most project decisions equally.

Everyone can propose and commit new work. Just because you don’t find it valuable, doesn’t mean some other part of the community can’t think it’s valuable to them. Merit is about the ability to do new things, not really about stopping the rest of the community from their new work.

Enough merit in a project can gain you Respect in the community. People will listen to you because they respect and trust your judgement, not because you have authority in the project.

Anti-pattern: Umbrella projects

Apache Jakarta was an umbrella project: many different sub-projects and communities, with different technologies.

PMCs should be coherent communities to equitably recognize merit.

??? A cautionary tale: in the past, we have had successful projects that grew in scope - both technical and social - until they were too big to govern themselves effectively.

When a project grows such that different groups of committers running sub-projects can’t evaluate each other’s work or use different governance processes to manage sub-projects, then it’s probably too big.

Everyone doesn’t need to directly work on each sub-project, or be an expert there - but you do need to have enough broad community members paying attention, so that the PMC could reliably detect issues (or make security releases) if something happens in any sub-project.

Open Development

Take a different way?

Continue Onward?

Time Shifted Communications

Asynchronous communication enables:
- Dispersed communities:
- …dispersed in location / culture
- …dispersed in abilities / expertise
- …dispersed in time
Our only connection: this project

??? Remember: we are a dispersed community, each with our own lives and jobs. We need to show the work we’re doing - and allow feedback - in whatever timeframe works for everyone else on the project.

You don’t need to wait for everyone’s feedback - but do recognize that sometimes other committers will have better ideas, or will be willing to do some of the work for you. That’s why formal decisions in Apache projects always have a minimum amount of time that must pass before getting finalized.

Archiving Everything

If It Didn’t Happen On-List It Didn’t Happen

Archived and searchable history enables:
- feedback
- critique
- new ideas
- others to show their work
Public archives are the default

??? Note: while the ASF currently relies on mailing lists, we are actively adapting this lesson to other technologies like slack, discord, wechat.

What this means is: if it didn’t happen in a space managed by the project, that is archived in a well-known place, and easily searchable, then it didn’t happen.

Archiving everything means that newcomers can get up to speed with all the information of the project available for them in an easy to share and search way - this helps newcomers understand where the project is going, and see how the community interacts with each other. Archives are also valuable for long-term cohesion, because when repeat questions come up, we can see our past decision - and the discussion that led to it.

You should default to using a public list - like dev@ or user@ - for almost everything. There are only a few things, like security bugs or personnel matters - that should be done on private lists.

Archiving things is just another way to enable long-term time-shifting.

Make Transparent Decisions

Motives usually external to the community
- How does a decision benefit the project?
Engage community at all steps:
- Telegraph your intent
- Draft designs openly
- Submit work in chunks
- Always seek feedback

??? Ensuring decisions are made openly - when everyone has the same information and time to read it - is required of Apache projects.’s required.

Telegraph your intent: email dev@ with your ideas ahead of time. This allows feedback, encouragement, someone else to point out similar code is already over there, etc.
Draft designs openly. Put the rough first draft on the wiki/website/dev@ list, and then do your edits in public. This allows feedback on the architecture as it’s being built, and again, gets better ideas. It also allows a sense of community ownership.
Submit work in chunks (add: on a regular and frequent basis). Checkin the shell of the API. Then checkin each section of implementation. If you’re waiting for your code to look perfect before showing anyone else, you’re not really helping the community. Doing the development in the open allows for… you guessed it, feedback.
Welcome feedback along the way. This doesn’t mean you need to accept every change request or suggestion. But it does mean you can take the best ideas from the whole community to add them easily, as the individual bits of work are being done.

Long-term Stewardship

Apache License v2.0
- Maximum user freedom
Trust in ASF as organization
- To maintain open development
- To continue to provide source code

Apache Attic - where quiet projects slumber forever

??? A goal of the ASF is to encourage maximum inbound contributions. Using the broadly permissive Apache License v2.0 is a key part of this - both from the legal details point of view, and as an important and enduring part of the Apache brand.

People trust they can just use stuff from Apache without being surprised by any unusual licenses or changes. They also trust that Apache will be around in 10 years to provide access to the source code. The Apache Attic is here to maintain every codebase we’ve ever shipped, to be available read-only as long as the ASF itself is around.

Decision Making

Take a different way?

Continue Onward?

Consensus Preferred

Consensus within community
Choose a good path forward
- Improve something; don’t regress
- Community values different things

??? There is no perfection - just getting better step by step. Our goal is to serve the public good, so any new features - as long as they don’t fail the tests or unduly slow down performance - are a good thing.

Consensus doesn’t mean everyone thinks it’s perfect - just that any proposed change is better somehow than we have now.

Building a true consensus is important for major changes. But for minor changes, going for “Lazy consensus” is fine: providing an opportunity for people to object; if no one does, go ahead.

Votes When Needed

“Voting records an official consensus”

“Voting is a shortcut - when required”

.bottomnote[https://community.apache.org/committers/decisionMaking.html] .topnote[community-led governance]

??? Here are two quotes about voting - the +1/-1 you’ve all heard about. One of these is a good use of voting, the other is… necessary.

You must vote on releases. In some cases, the vote is the formal record that a PMC or the board made a decision. That keeps the decision an act of the ASF as a foundation, and not just a bunch of individual developers. Votes are also normally used on new committers/PMC.

Voting to speed consensus… it can be OK in some cases, but where possilbe we prefer to work through to a better consensus. Some projects choose as a whole community to use votes more often, if that works for them. As long as the decision process allows the whole project community to have their input, the use of votes or full consensus is up to the project.

Timeline For Decisions

Minimum time for decisions: 72 hours
Allows time-shifted community input

??? Your project community is from around the world, and from all sorts of backgrounds. For example, some people commit during a dayjob; some people only have time on weekends or when the kids are asleep.

Ensuring sufficient time for most community members to comment is required for major decisions in Apache projects.

One exception is for security issues: serious security breaches can be fixed as soon as possible, to help ensure our users aren’t harmed.

No External Deadlines

Because we don’t have any - unless we agree on them together

??? The ASF relies on volunteers (from the Apache perspective) to do our work. Therefore in project areas, we don’t have deadlines, other then ones the project defines as a community. Working towards a project roadmap is a great way to encourage users and contributors - but if the project slips deadlines, that’s just fine.

Remember: security issues often do have deadlines.

Communication

Take a different way?

Continue Onward?

Be Kind

Be kind.

Everyone is a volunteer here.

??? Remember: everyone else in the community here at Apache is a volunteer. Being kind in your words and tone, and respecting everyone else’s input (even if you disagree) and especially respecting everyone else’s time that they volunteer for your project is important.

We can and do often have serious disagreements. But doing so with communication styles that are kind and respectful is critical for the long term health of any project - or even just to get other project participants to vote or help with your ideas.

Netiquette

Ask smart questions

Make it easy for communities to answer your question.

??? Netiquette. Smart questions. Reproduceable bug reports. Clearly communicating the what, why, and how of your request.

Asking smart questions means respecting the time of all the other volunteers reading your email - and ensures that they know what action you’re requesting (bugfix, information, project suggestion) quickly and easily just from what you wrote.

Codes of Conduct

Don’t be a jerk; avoid the poisonous people… and help the community do something about it.

ASF Code of Conduct Updates coming soon 2025

https://www.apache.org/foundation/policies/conduct

??? The ASF has a Foundation-wide code of conduct that is required behavior in all Apache project and foundation spaces. NOTE: The Board is likely adopting a new, more detailed code of conduct this winter.

The intent of the Code of Conduct is not to be a hammer; it’s meant to be a framework we can use to help both individuals and whole communities to see the expected standards of discourse we want on Apache lists.

How Open Source Projects Survive Poisonous People https://www.youtube.com/watch?v=-F-3E8pyjFo

Language

“Core development activity must be in English.”

Translation software isn’t social
The whole community must be able to evaluate your work
The board provides oversight to all communities

??? At the current time, it’s only practical for the ASF to provide governance and hosting to communities that can operate their primary dev@ list in English.

This doesn’t mean it can’t be done - it certainly is being done in China and elsewhere - just that the ASF can’t support non-english as the primary project planning language. User support, translation, outside evangelist work can be in any language, as long as you can report the status of your work periodically to the project in English.

Charity

Take a different way?

Continue Onward?

Apache Software Is Always Free

Free of cost forever
Free of restrictions
Licensing policy: no surprises

https://www.apache.org/free/

??? The ASF is a public charity, and our mission is explicitly to produce software that is useful, and always free of cost or restrictions for people to use.
Alongside the permissive Apache license itself, the ASF’s policies around acceptable software that our projects can contain is focused on ensuring that users don’t find any surprising restrictions in any of our products.

While our pragmatic licensing focuses on the legal enablement of open source, so that everyone can contribute, many ASF committers also have some form of altruism guiding their work - enjoying building things for free to give away.

Apache License

Minimal restrictions on uses
Maximum number of inbound contributors

https://www.apache.org/free/

??? Our pragmatic and permissive license is designed with no surprises, and provides maximum freedom for users and redistributors. This also means it allows the maximum number of contributors, because people or organizations with any sort of business model or otherwise can contribute without any impact to their goals outside the project.

Where next?

Take a different way?

Continue Onward?

The Apache Way

Needs Your Input!

These slides - and indeed the whole of the apache.org website and Shane’s theapacheway.com website - are open source.

Get involved with documentation - improve the Apache Way!

https://theapacheway.com/about/ ]

Thank You & Questions!

The Practical Apache Way

Effective Open Source Project Management

@ShaneCurcuru

Slides and Speaker Notes

What Is The Apache Way?

Why Follow The Apache Way?

Apache Way Menu

Community

Community

Wear Your Hats

Check Job Titles At The Door

Independent Governance

Merit

What YOU Have Done

Growing Your Scope

Merit is Not Authority

Leaders versus Managers

Anti-pattern: Umbrella projects

Open Development

Time Shifted Communications

Archiving Everything

Make Transparent Decisions

Long-term Stewardship

Decision Making

Consensus Preferred

Votes When Needed

Timeline For Decisions

No External Deadlines

Communication

Be Kind

Netiquette

Codes of Conduct

Language

Charity

Apache Software Is Always Free

Apache License

Where next?

The Apache Way

Needs Your Input!

Thank You & Questions!