Bob Paulin @bobpaulin

For more, see table of contents

Open Development

• Code, processes of contribution available to whole organization.
• Each project might have some extra governance
• Developers can see, contribute and work with any code.

InnerSource

• Communities not product teams
• Communication is transparent
• Code/doc/issues accessible to everyone
• Code not usually externally available (outside company)

Apache Way

• Community over code – can’t do something that helps one person, but is bad for the community
• Consensus decision making
• Open communications – message lists for all projects. “If it’s not on the list, it didn’t happen”
• Earned authority – earned/voted on
• Community of pears
• Responsible oversight

More on Apache

• Hard to kill an Apache project. Struts is still cutting releases. People are still maintaining it because important to someone.
• When community goes away, project goes to attic

Open Development at work

• Consultants – there to advise
• “You can make buffalo go anywhere, just so long as they want to go there”. “You can keep buffalo out of anywhere, just so long as they don’t want to go there” – from “Secrets of Consulting” – recommends book for getting things gone
• People will go to great lengths to avoid pain. They need to understand how open development reduces their pain

Stories

• Tribal knowledge – once a month man comes down from the mountain and explains how things work to people
  • localized knowledge
  • can go with benevolent dictator on project
  • passed down mouth to mouth
  • only know if have relationship or proximity to person
  • document for different zip codes – needs to be clear to everyone. only use acronyms can google
  • document for dummies – should be clear to entry level developers
  • curse of knowledge – you’ve forgotten what is hard
• Man behind the mirror decision making – architect went to talk to everyone. All felt good after meeting. Months later, realized things weren’t working together. Contradictions, misunderstandings
  • Set decision making to INFO – anyone can read decisions
  • People get upset/feel excluded when planning happens via direct message
  • People make decisions in meetings without realizing it was a decision
  • Appoint a decision crier – someone raise hands and says sounds like a decision and notes should write it down. Also helpful to have a secretary who should write things down.
• Micro manager – can’t expect others to step up if still doing everything
  • Encouraged measured risk taking – let people take risks so can feel comfortable. Ex: can commit, but say something. Still don’t want it to go to production. Focus on learning over veto
  • Self driving car approach – still need to pay attention to wheel. Find bugs by finding mistakes people are continually making
  • Build reputation of new leaders – others start become accountable and show they can do it
  • Have to let make mistakes. Ok to commit something not perfect.
• Bike shed to oblivion – people get passionate when arguing about something important (to them). What color should the bike shed be.
  • Enabling constructive dissent – community, consensus, earned authority
  • Elephant rules – acknowledge the undercurrents. What is actual reason for dissent. Knowing whether comes from gut feeling. Acknowledge what is problem and what is relevant
  • Build failure hedge fund – sometimes things go wrong. Determine if can learn from them or will ruin company? If the later, veto. Normal to fail from time to time

My take

Good end of the day. Some “obvious” and some to experiment with. Nice inspirational talk. I like the mapping of “general” principles to Apache principles.