Stuff everyone knows and forgets anyway
Use this chapter to remind yourself and everyone else.
(Short URL: http://bit.ly/TOSWFailure)
Fail spectacularly, and don't forget to take notes.
The main part of this story starts at 2:52, as linked here, and includes this from Takeo Fukui, President and CEO of Global Honda:
Communities require care and feeding to get started ...
By giving good and regular care, your communities ...
... And communities need to be left to grow and evolve
Remember what you learned in Kindergarten
- Play nice
- Don't run with scissors
Seriously, you would be surprised at how many of the most basic rules are broken that our parents and teachers thought they taught us many years ago.
Four new virtues to live by
These four virtues were described by Brian Fitzpatrick and Ben Collins-Sussman in their seminal talk on avoiding poisonous people in communities.
Turn newbies in to instant contributors with the power of To Document
People offering help should require that the help be documented.
When the asker is a new member of the community (newbie), this is a great way to turn them from an annoyance in to an instant contributor.
Take extra extra extra care to have all discussions in the open
(Short URL: http://bit.ly/TOSWOpenDiscussions )
Even if it means stopping and restarting a conversation in a public/archived location, keep this in mind at all times.
If it's not in the public record, then it doesn't exist.
This means that when you have private discussions, and such hallway conversations do happen, the responsibility is on the participants to record as best as possible the conversation -- notes taken in the middle and at the end can suffice as such documentation. The results of this discussion, minus privately sensitive matters, must be sent to the main openly archived discussion area, such as the community mailing list.
Trust but verify. A commitment to participatory transparency invests into the mutually held bank of trust. "Just trust us" decisions done behind closed doors spend from the bank of trust. The bank can go broke all too easily.
Radically visible meetings at all times
There is a reason mailing lists and open chat networks are the baseline for all communication in successful open source projects.
No decision point is too small to pre-announce to a mailing list
While we can grow trust in the community about technical or other decisions, there are common problem circumstances we can avoid:
- The corporate sponsor and staff are always more suspect, so need to take extra care to share the decision making process
- We cannot guess what is important to contributors, nor why. Presuming they don't care about a decision is a bad idea.
It's okay to be disappointed but never okay to be surprised
(Short URL: http://bit.ly/TOSWSurpriseNotOK)
Sometimes we hold back on letting people know information because we are concerned they'll be disappointed. When mishandled, those folks end up disappointed and surprised, which is a potently negative combination.
How to let a mailing list run itself
- Everything must be discussed on the list.
- If you break rule 1, you must make sure that whatever the discussion was, the details and results are published on the list
- This happens often, so it is incumbent that decisions come back to the list from IRC, phone calls, f2f meetings
Take even more care to do all design decisions in the open
Even when all content is done using open resources, if you make design decisions via in-person meetings, hallway discussions, over lunch, during the daily commute, and so forth, then you are leaving the community out of work that really matters. They'll notice and care.
People talk with each other, and that's fine. Just consider it to be pre-decision discussions and follow these rules:
- A decision doesn't exist unless it's discussed on the mailing list first.
- A conclusion isn't justified unless the discussion demonstrating it and evidence backing it up are visible publicly.
- A discussion doesn't exist unless it's on the mailing list - send at least a summary of all non-public discussions to the mailing list, with the conclusions open for further discussion.
Use version control for your content as well as code - everyone watches the changes
Equally important is that all project members watch these changes. Responding to the changes on a mailing list, bug report, or wiki discussion page keeps the discussion associated with the node of origin.
For example, major design decisions need to ...
Choose open tools that can be extended
It is risky to choose closed tools that a community cannot easily scale itself.
Make sure everyone has an equal and clear method for access to write-commit to open tools
More people want to do good for your project than want to do bad. Don't punish the do-gooders because of the potential evil someone might do.
Tie this together with open content
Don't forget to document code, processes, methods, reasons, etc.
Focus on healthy and open community interaction
(Short URL: http://bit.ly/TOSWHealthyInteraction )
If your goal is to have a healthy community that can grow to scale while supporting itself, then you have to think of it as you would any other relationship.
Perhaps you do business based on your project's output, such as selling support for open source software you help create. In that class, the community is your open supply chain. The healthier that supply chain is, the better the product is that you do business around.
The key to healthy community interaction is focusing on transparent communication.
- Every decision is not real and binding until it has been discussed openly.
- Organizations that have private communication on other matters, such as corporations, must take extra vigilence to keep communication open and transparent. It's too easy to make decisions in the hallway, which creates community mistrust.
- If your supply chain is important to you, you and all your people must keep healthy communication as a higher priority than personal agendas and taking offense.
Make governance as clear as possible
(Short URL: http://bit.ly/TOSWClearGovernance )
Use your lawyers well while avoiding too much legalese
(Short URL: http://bit.ly/ )
Do not let poisonous people bog down the community
(Short URL: http://bit.ly/ )
Communicators need to communicate - do not let liaisons go silent
(Short URL: http://bit.ly/ )
Disable poisonous communication
(Short URL: http://bit.ly/ )
Seek consensus - use voting as a last resort
Voting is best left for deciding who is in charge and the occasional very contentious issue. Don't you wish it weren't contentious? Wish you could go back and make a consensus?
Reassign your benevolent dictators while evolving toward a consensus-based democracy
(Short URL: http://bit.ly/TOSWConsensusDemo )
Do not forget to release early and release often
Release early and release often is for more than just code
(Short URL: http://bit.ly/TOSWReleaseEarly )
Every idea deserves the light of day as early as possible.
A common mistake is to wait to release a document, process, marketing plan, etc. until it is "just right". People who otherwise fully understand how not to do this in code forget when it comes to other parts of a project.
Apply this rule:
- If a piece of information is confidential, keep it private;
- Otherwise, get it out in the public soonest ...
... using techniques such as these ...
- Bounce the idea off the mailing list(s)
- Make a wiki page
- Add to another wiki page
- File a ticket in a tracking system
- Make a non-coding prototype
- Wireform web page in a wysiwyg editor
- Inkscape or GIMP mock-up/collage
- Bar napkin and pen, scanned or photographed
Evolve with the growth of your audience and contributors
Use a predictable schedule type and stick to it
Regardless of what type of schedule you choose, you need to stick to it and keep your community informed about the status of the schedule. Remember, it's OK to disappoint people sometimes, but not surprise them.
There are two main types of schedule for delivering open source:
- Time based
- Feature based
A good teacher is a good student - ask questions and put yourself in a position of being taught by others
Part of practicing the open source way is teaching others about how and why they want to adopt this way of working, thinking, and acting.
Remember that in all your interactions, it helps for you not to presume that you are an expert and know all there is to know. Even in domains you are familiar with, ask basic and dumb and open and revealing questions. Ask any questions that help you make sure to reveal and map the principles of The Open Source Way to an individual domain.
Strive to drive barriers as low as possible
(Short URL: http://bit.ly/TOSWLowBarriers )
If you want open collaborators, you must make all barriers as low as possible. You must advertise this access-level clearly.
If there are levels of access, such as "can write to the mailing list and file bugs" all the way over to "can commit major code changes to the source repository", then you must make it clear what these levels are and how to obtain them.