Nadia Eghbal, @nayafia
- Doing research around open source activity
- Evolution of open source contributions
- Different models, emerged over time
- Brief history of different models for managing open source contributions
- What the future holds
- Different models for different market needs
- Markets: users, contributors
- History
- BDFL prevalent (Benevolent Dictator for Life, Linux, Python)
- Anyone can have their say, but 1 person (BD) has final say
- Made sense when the market was smaller
- Open source was a counter-culture, alternative
- Harder to code, fewer contributors
- BDFL benefits:
- Centralized leadership, governance
- Centralized roadmap, direction
- Drawbacks:
- Less democratic
- Best you can hope for is influence
- BDFL made companies nervous, both contributing and using
- Arbitrary decisions made by someone outside of our control
- Meritocracy (Apache Software Foundation, 1999)
- Multiple actors weighing in
- Anyone with merit can make contributions, can have a binding vote
- 👍 Great for company buy-in, path for participation
- Apache helped with legal protections, creating a neutral safe space
- Partially why open source has been successful
- Still some friction:
- *with merit, what does this mean? how is it achieved?
- From ASF: people have to earn the right
- Commitment, care, work well with others (not going to rock the boat)
- You need to prove yourself, by spending time on the project
- Makes sense in theory, but…
- Favors people who can pay to play (people with time)
- E.g. companies who can devote full time contributors have more weight, say in process
- Liberal contribution (Node.js, 2010s)
- More users, tech, talent than ever before
- Git, GitHub made this easier for anyone to jump in
- Common interface, pattern, for contributing
- 49% of ppl on top GitHub projects only contributed once 😮
- More NOISE, under meritocracy this was bad 👎
- But, opportunity! Engagement! Harness! Redirect!
- CLA requirement? Can we drop it?
- Node adopted a liberal contribution policy (Getting people to contribute is hard, Git is good at removing things — Mikel Rogers, Node.js)
- Results:
- Waaaaaay more contributions 📈
- Free marketing, WOM (word of mouth) ambassadors
- Nodeschool
- New perspectives, skills, backgrounds (inclusion)
- People need to be enabled to do good work — Mikel Rogers
- Also, Rust adopting this contribution model
- Originally used BDFL -> core team -> federated structure
- 1200+ contributors, contributing regularly
- diverse range of perspectives in both design and decision-making — Alex Crichton, Rust
- Care about end-user perspective
- Liberal contribution models:
- Floodgates, not bottlenecks
- Ultimately less work for maintainer, although counterintuitive
- Consensus seeking (focus on major concerns), rather than consensus
- Once there are no more major issues, we’re 🆒?
- Emphasize discussion
- Meet contributors where they are
- Value of good docs, contribution guides, tagging beginner bugs
- Default to yes
- Here’s what I need from you in order to be able to accept
- Floodgates, not bottlenecks
- BDFL prevalent (Benevolent Dictator for Life, Linux, Python)
- Do BDFLs still matter?
- Yes, early in life of project. Central person important
- BDFL can help incubate, set direction
- Like starting a company
- Liberal contributions can help with managing growth
- Project trajectory chart 📈
- Move towards liberal contributions as project matures, grows
- Case study:
- Django, Jacon Kaplan-Moss (…I realize our community doesn’t need [BDFLs])
- Modern projects using BDFL?
- Clojure: 1 person making vast majority of contributions
- Works because Clojure is sustainably supported (by Cognitect), and everyone is happy with the situation 😄
- BDFL as a long-term strategy, requires luck (find a company to hire you to work on project forever)
- Liberal contribution reduces burden on individual maintainer
- A framework for sustainability
- Narrow scope? BDFL could work…
- Dependent on community and culture
Wed Jun 29 10:01:56 PDT 2016