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

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

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

layout: true name: treeright background-image: url(img/meduana-178155-smeu.jpg) background-size: cover

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

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

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

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

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

layout: true name: logorb class: left background-image: url(img/apacheconeu.png) background-repeat: no-repeat background-position: 98% bottom background-size: 20% background-origin: padding-box

template: fullheader

Coming Up Next

.left-column[

Shane Curcuru

] .right-column[

The Apache Way: Effective Open Source Project Management

]

??? Tips: Press ‘?’ for help; press ‘P’ for speaker notes.

template: fullheader

The Apache Way

Effective Open Source Project Management

.left-column[

Shane Curcuru

]

.right-column[

Vice Chairman

The Apache Software Foundation

@ShaneCurcuru

]

template: logorb

The Apache Way: Introduction

The Apache Way is a set or behaviors and practices developed at the ASF and designed to promote long-lived successful projects by focusing on stable governance and encouraging new contributors.

These behaviors are required of all Apache projects.

??? High level intro, mention concepts: openness, merit, consensus.

template: closing

Apache Way

History And Behaviors

template: logorb

Apache Way History

  • Creation of the ASF as a Foundation
  • PMC Organization and Growth
  • History of the Apache Way

??? The traditional Apache Way talk leads you through the journey of the ASF itself, how it was founded, the history of our communities, and a lot of other stuff from our past and how we built the Way over time.

template: logorb

What we AREN’T Talking About

  • But I’m not going to do that
  • What does history matter to newcomers?
  • You want actionable information on What To Do!

??? But how important is that today? You want to learn the behaviors, right? Actionable information. Let’s get to the good stuff. Anyway, Lars covered Apache history yesterday morning in the “Behind The Scenes” talk.

So this is a new kind of Apache Way talk - I want to focus on the specific behaviors and actions that work best with Apache communities. Along with the “what to do”, I’ll provide some of the “Why we do it that way” too, since it’s always important to understand the rationale behind the Way.

template: menu name: menu

Apache Way: Menu

What behaviors should we talk about next?

.footnote[The Apache Way is participatory! You are part of the community!]

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

Each of these is a set of topics about a kind of behaviors that Apache projects are expected to follow. What do you want to talk about?

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

template: flockbottom name: community

Community

.footnote[ Take a different way? | Continue Onward? ]

template: logorb

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 our 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,… and users.

??? We should focus on an entire project community - all of us working to create or improve our 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 our work and goals aligned. Being able to become a committer or PMC member with binding input in a project is a clear incentive.

template: logorb

Community - No Jerks Allowed

  • “No jerks allowed” - a key early message
    • Apache communities value group contributors, not lone wolves
    • Diverse communities attract more new contributors over time
    • BDFL not allowed in Apache PMCs

??? There are many ways to say this - No Jerks Allowed, Avoid Poisonous People, be decent, whatever. The point is, where everyone unteer and many people are doing this as a side task or second effort, ensuring that everyone is welcome is the most important factor for a long-lived healthy project. Our communities rely on many volunteers; ensuring it’s a welcoming project for newcomers should be your goal.

template: logorb

Community - No Jerks Allowed

  • “No jerks allowed” - a key early message
    • Apache communities value group contributors, not lone wolves
    • Diverse communities attract more new contributors over time
    • BDFL not allowed in Apache PMCs

Be Excellent To Each Other

??? In the immortal words of Bill and Ted: Be Excellent To Each Other.

This is important for any community, and doubly so for Apache projects, since we’re all also part of the larger ASF community. We have a code of conduct - not because we want to use it, but because we don’t want to have to use it, since the great majority of our communities keep discussion polite to start with.

Plus, when everyone is a volunteer, raising your concerns politely and concisely is more likely to get people to help you.

template: logorb

Community - Wear Your Hats

  • You are an individual - not an employee
  • No corporate participation at Apache
  • Individuals get recognition
    • Side effect for corporate teams: each employee participates separately
    • Side effect for you: your merit stays with you

??? 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 mean you have to look out for your employer - but it’s a key part of how Apache projects work.

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.

template: logorb

Community - Check Affiliations At The Door

  • Not talking about hierarchy
  • Because we don’t have one - each project is separate
  • We each volunteer with same powers (and superpowers in a PMC)
  • Your PMC doesn’t care what your dayjob role is

??? 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 neutral place were everyone can work together on specific technologies.

template: logorb

Community - Independent Governance

  • ASF owns the trademarks
  • ASF ensures neutrality, development
  • PMC owns the brand
  • PMCs govern independently

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

??? 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 merit - how much an individual creates value for that project.

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.

template: pineapple name: merit

Merit

Take a different way? Continue Onward?

template: logorb

Merit - What YOU Have ACTUALLY Done

.left-column[ Merit ]

.right-column[ The value you bring to the specific project, as defined in the context of that project by the project community. ]

“You gain merit by doing things that specific community values”

??? Meritocracy is a word we use that is often misunderstood - many other communities see it as having a different connotation than the ASF uses.

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

Every project is it’s 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.

Side note: “Mertocracy” is an overloaded term in the modern age, and we probably should find a new way to explain this term.

template: logorb

Merit - Growth

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.

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.

template: logorb

Merit - Not Authority

  • Leaders or managers?

“Merit gets you privileges: commit access, voting on committers”

“Merit does not buy you authority (community must still agree)”

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

template: logorb

Merit - Umbrella Projects

Problem area: Umbrella projects

Jakarta was an umbrella project - with many different subprojects and components - and communities.

The PMC must be a coherent community to be able to recognize merit in all contributors.

??? 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 modules can’t evaluate each other’s work - or vote on releases - it’s probably too big.

The board is here to backstop communities. Each community needs to be coherent and work as a single unit - when you’re bigger than that, you should probably split up into separate projects.

template: palmsbottom name: open

Open Development

Take a different way? Continue Onward?

template: logorb

Open Development - Time Shifting

  • Yes, we use mailing lists
  • Asynchronous communication is critical
    • …a dispersed community
    • …dispersed in space
    • …dispersed in abilities / expertise
    • …dispersed in motivation
    • …dispersed in time
  • Only know each other through the 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 you do need to 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.

template: logorb

Open Development - Archiving Everything

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

  • Asynchronous lists provide time for
    • feedback
    • critique
    • new ideas
    • others to show their work
  • Must be public list unless there’s a reason for private list

Allows newcomers to learn at any time

??? 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. Even if your documentation doesn’t lead new users through this, having it available both for people to find, and especially for people to reference when questions come up is the most important thing.

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.

template: logorb

Open Development - Transparent Decisions

  • Your motives aren’t transparent to the community
    • Motivated by boss, by outside technical need, by just being a geek
    • How does this decision benefit the project

The right way to work is to:

  • Telegraph your intent
  • Draft designs openly
  • Submit work in chunks
  • Welcome feedback along the way

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

Open source does not always mean open development.

Apache projects always practice open development - it’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.

template: logorb

Open Development - Pragmatic License

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

Apache Attic - where quiet projects slumber

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

template: beachbottom name: decision

Decision Making

Take a different way? Continue Onward?

template: logorb

Decision Making - Consensus Preferred

  • Consensus within community
  • Choose best path forward
    • Or even an improvement
    • Your perfection may be someone else’s “meh”

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

template: logorb

Decision Making - Votes When Needed

“Voting is a way to record an official consensus”

“Voting is a shortcut to move consensus forward in a timely manner”

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

template: logorb

Decision Making - Timeline

  • Minimum time to make a decision: 72 hours
  • Allows timeshifted input from community

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

template: logorb

Decision Making - No Deadlines

  • Because we don’t have any - besides those we agree on together
  • Because our deadlines are “earliest date” something can happen

??? The ASF relies on volunteers (from the Apache perspective) to do our work. Therefore in project areas, we don’t have deadlines, other than 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.

template: treeright name: communication

Communication

Take a different way? Continue Onward?

template: logorb

Communication - Styles

Don’t be a jerk; avoid the poisonous people.

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

??? You can’t overemphasize this message!

template: logorb

Communication - Conduct

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

ASF Code of Conduct https://www.apache.org/foundation/policies/conduct

??? This is required for how we work, in all Apache project and foundation spaces. 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.

template: logorb

Communication - Kindness

Be kind - everyone here is a human being, and a volunteer.

??? 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 partipants to vote or help with your ideas.

template: logorb

Communication - Language

“The core development activity must be in English.”

  • Because… translation software isn’t social
  • The whole community must be able to evaluate each other’s work
  • The board needs to be able to provide 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 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 development 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.

template: closing

Where next?

Take a different way? Continue Onward?

template: thanks name: closingslide

The Apache Way

Needs Your Input!

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

Get involved with documentation - improve the Apache Way!

.code[https://github.com/ShaneCurcuru/slides/]

name: last-page template: thanks

Thank You & Questions!

.footnote[ By: @ShaneCurcuru | Apache v2.0 | http://shaneslides.com ]