layout: true name: fullheader background-image: url(img/david-lezcano-120708-sml.jpg) background-size: cover
layout: true name: flockbottom background-image: url(img/shwetha-shankar-137724-smb.jpg) background-size: cover
layout: true name: palmsbottom background-image: url(img/jeremy-bishop-257105-sm.jpg) background-size: cover
layout: true name: treeright background-image: url(img/meduana-178155-sm.jpg) background-size: cover
layout: true name: beachbottom background-image: url(img/alexandre-perotto-46114-sml.jpg) background-size: cover
layout: true name: pineapple background-image: url(img/pineapple-supply-co-64690-sm.jpg) background-size: cover
layout: true name: closing background-image: url(img/deborah-kunzie-49758-sm.jpg) background-size: cover
layout: true name: thanks background-image: url(img/stuart-guest-smith-150560-sm.jpg) background-size: cover
layout: true name: menu background-image: url(img/lance-asper-153777-sm.jpg) background-size: cover
layout: true name: logorb class: left background-image: url(img/Apache_NA_Logo-b.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 President, Brand Management
The Apache Software Foundation
@ShaneCurcuru
]
template: logorb
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 Apache projects.
??? Very high level intro, mention concepts: openness, merit, consensus. Whole day of sessions: pick the ones that make the most sense to you.
template: logorb
The Apache Way - Morning
Wednesday Schedule
- 9:00am Apache Way: Effective Open Source Project Management, Shane Curcuru
- Coffee Break
- 10:15 A Tale Of Two Developers In The Apache Way, Andrew Wang & Alex Leblang
- 11:15 From dev@ to user@ to The Apache Way, Steve Blackmon
- 12:15 Apache Way: Software is Easy; People are Hard, Benjamin Young
- 1:05pm Lunch (on own)
??? Tales of 2 developers with Andrew and Alex: how corporations - and their employees - can best get involved in Apache projects, told from your employee’s perspective.
From dev@to user@ with Steve: How projects can make it easy to attract new contributors
Panel on Software is easy, people are hard Panel discussion with Benjamin and Apache experts - how Apache projects can survive where others get dominated by one company, or run out of ideas, and their volunteers disappear.
template: logorb
The Apache Way - Afternoon
Wednesday Schedule
- 1:05pm Lunch (on own)
- 2:30pm The Apache Way For Business, Nick Burch
- 3:30pm Committed To The Apache Way, Sharan Foga
- 4:20pm Coffee Break
- 4:40pm Keynotes
- 5:50pm Lightning Talks
??? The Apache Way For Business with Nick Burch and an expert panel of Apacheites, explaining how your company should think about engaging with Apache projects.
Committed to Apache with Sharan: How individuals can get recognized for contributions in other ways besides code
Keynotes a couple of talks about IOT and machine learning, then a great talk about how Comcast’s developers make use of the Apache Way.
template: closing
Apache Way
Defining The 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 the past.
template: logorb
What we AREN’T Talking About
- But I’m not going to do that
- What does history matter now?
- Why do we care how or why it happened?
- You want actionable information on What To Do!
??? But is that really important? You want to learn the behaviors, right? Actionable information. Let’s get to the good stuff.
So this is a new kind of Apache Way talk.
But in a diverse and dispersed world, having the why behind the rule - or the rationale to the policy - is a key way to ensure the community can understand it, know it’s proven value, and then have an intelligent and focused way that we could work on changes. That’s still there - but we’ll save the whys for after we talk about the whats.
template: menu name: menu
Apache Way: Menu
What behaviors should we talk about next?
- Community - over Code
- Merit - recognizing your work
- Open Development - for everything
- Decision Making - consensus & votes
- Communication - how we write
- Questions To Answer
.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?
template: flockbottom name: community
Community
.footnote[ Take a different way? | Continue Onward? ]
template: logorb
Community
- What kind of community do we mean?
- 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 people widely distributed in location, in time, in experience, and in jobs besides the project itself. SPACEBAR
–
- Community includes developers, writers, testers, sysadmins, devops,… and users.
??? The important thing is that the community owns the project. Not you, not me, not your company. All of us.
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 is a volunteer and most 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 health project.
template: logorb
Community - No Jerks Allowed
- “No jerks allowed” - a key early message
- FOSS communities value group contributors, not lone wolves
- Diverse communities that can attract new contributors over time
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.
template: logorb
Community - Wear Your Hats
- You are an individual - not an employee
- No corporate participation in Apache
- Individuals get recognition
- Side effect for corporate teams: all team members must participate separately
- Side effect for you: your merit stays with you
???
The ASF does not allow direct corporate participation in projects.
We only recognize individuals. Merit accrues to individuals, and they
are expected to act with their project hat on at times.
This 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 our projects work.
This both 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.
template: logorb
Community - Check Affiliations At The Door
- Not talking about hierarchy
- Because we 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.
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.
template: pineapple name: merit
Merit
Take a different way? | Continue Onward? |
template: logorb
Merit - What YOU Can Do
.left-column[ Merit ]
.right-column[ Defined by the value you bring to the specific project, 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 - some 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, but it stays with you through jobs and careers.
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 binding vote on new tasks.
template: logorb
Merit - Not Authority
- Leaders vs. managers
“Merit does not buy you authority (community must still agree)”
“Merit gets you privileges: commit access, voting on committers”
??? You are still part of the community - it’s not a hierarchy; everyone with merit (commit bit) has a say in basic decisions.
Everyone can propose and do new work. Just because you don’t find it valuable, doesn’t mean some other part of the community thinks it’s valuable.
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 split up into separate projects.
template: palmsbottom name: open
Open Development
.footnote[ 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.
template: logorb
Open Development - Archiving Everything
If It Didn’t Happen On-List It Didn’t Happen
- Must be public list unless there’s a reason for private list
- Asynchronous lists provide time for
- feedback
- critique
- new ideas
- others to show their work
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. 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.
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
- Motivation should be best for project as a whole
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.
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 from our brand.
People trust they can just use stuff from Apache without being surprised by any unusual licenses or changes.
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 - is a good thing.
Consensus doesn’t mean everyone thinks it’s perfect - just that any proposed change is better somehow than we have now.
template: logorb
Decision Making - Votes When Needed
“Voting is a shortcut to move consensus forward in a timely manner”
“Voting is a way to record an official consensus”
??? 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… not as good.
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 as being an act of the ASF as a foundation, and not just a bunch of individual developers.
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, but it’s not required.
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 many major decisions in Apache projects.
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.
template: treeright name: communication
Communication
.footnote[ 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.
ASF Code of Conduct https://www.apache.org/foundation/policies/conduct
??? This is how we operate, in all Apache project and foundation spaces.
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.
template: closing
Where next?
.footnote[ 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 | https://shanecurcuru.github.io/slides/ ]