Open collaborations: leadership succession and leadership success – Anne Smith & Myk Dowling
- Started playing Kerbal Space Program and using lots of mods to it.
KSP-CKAN
- Comprehensive Kerbal Archive Network
- 150k downloads of a previous release, 72k of last release
- 1035 starts on github
- 124 releases from 16 developers
- Written in C-sharp
Why was the project a success out of around 1.4 million projects?
Conway’s Law
- FOSS projects are generally modular
- C and C-derived languages are predictive of success
- Portability predictor of success
- Layered Development
83% of FOSS Projects fail. 46% before and 37% after a stable release
How do projects organise?
- First the founder 1-2
- Then a belt of users emerages
- Then a periphery – active users
- A core of developer emerges
- Some formality emerges
Onboarding People
- Relying on self-motivated people limits the number of people who will join your team
- If you lose people by brushing them off you reduce your team diversity, team diversity gives increased likelihood of success
- From the core to the periphery. Order of magnitude decrease in activeity but order of magnitude increase in size.
- Therefore is 1:1 level or work. Which is about the same level of code:support work that is needed.
- Flat structures are not stable; FOSS teams self-organise into a complex of a dual-layer structure
- Leaders should prioritise the people on the periphery. Many join for a short term need, the leader has to give them other reasons to stick around.
Links to other Projects
- Friction with Mod authors. Mods who though CKAN installed things the wrong way and caused problems got annoyed.
- Some authors of modules that were under FOSS asked for it to be removed, which CKAN resisted doing.
- CKAN was mostly orientated towards users and not so much towards the authors
- Significant group of mod authors considered opting out of CKAM
- Speaker proposed a policy that allowed mod authors to delete mod
Leadership
- Strong technical contributions
- Participatory behavior
- Organisation building behaviors
Leadership origin and style
- Typically the initial leader/s are the founder/s
- Often shared
- Leaders may move from core to periphery without losing the position
- Organisation focus vs Product (technical) focus
- People with both skills are the ones selected for leadership
CKAN in Transition
- Removed mods as requested
- Which broke things for some time
- Leadership got transfered over
- Original technical-orientated leader stepped back
- A more Organizational-orientated leader took over
- A clear and public succession is much better. Although some people still dropped out.
- But better and an acrimonious fork
Leadership Transitions
- Make speed and smooth
- Happen at the speed of military coups
- Limited participation from a predecessor assits in a smooth change
- Establishing succession rules helps
Review the state of your projects public-facing website from the POV of the peripheral people you want to attract.
Open Source Citizenship by Josh Simmons
Healthy Projects are vital which is why many companies are investing in projects
- They don’t just need money
What are companies doing now?
- Upsteaming contributions
- Contributing to the ecosystem
- Paid contributors on staff (full or part time)
- Hire out of the Project contributors
- Supporting with money, infrastructure etc. Both projects directly and other things
- Programs to help contributors get started.
- Sharing their experience
What companies provide is not always what communities want
What are Communities asking for?
- Volunteer design,
- UX/UI
- Project management
- technical writing
- data science
- marketing/PR
and yet, code still dominates. These skills need onramps to contribute to your projects.
- Contribute beyond what the company needs
- Projects want testing and QA resources
- Fund conference travel for contributors
- Event Space
- Open Source friendly contracts for employees who contribute to Open Source – See the “Contract Patch Program”
- Jobs the maintainers and contributors when heavily relying on their work
- If the maintainers are not getting paid that is a risk for the business
- Encourage Universities to give students credit for contributing to FLOSS
- Abide by community norms
Building a Culture of Open Source Citizenship
- Enumerate and value your dependencies
- Raise internal aweness
- Incentivise your people to contribute to open source
- train, train and train
- Be Patient
For FLOSS Projects
- Make it easy to learn about you project
- Have clear project government and licensing
- Say what you are looking for
- We want to know the invest we make in you is going to be used well and in a trasparant way
- Have a way to receive Money
- Look at being a member of a larger organisation like Software Conservatory
- See also open collective if you are just starting out
- Have a plan for how you are going to use the money
- Be prepared to work with corporate timelines
- Be prepared to onboard new contributors
- Contributor documentation
