TYPO3 Communications Workshop: Governance
•Download as ODP, PDF•
0 likes•465 views
Looking at the purpose of governance models in FOSS projects, the varieties of governance model and the varieties of contribution model
More Related Content
Similar to TYPO3 Communications Workshop: Governance
Similar to TYPO3 Communications Workshop: Governance (20)
More from osswatch
More from osswatch (16)
Recently uploaded
Recently uploaded (20)
TYPO3 Communications Workshop: Governance
- 2. In this session What are governace models? Why are they important in FOSS projects? Varieties of Governence models Contribution management styles Reflection on your own governance model
- 3. What's Governance? The roles and processes for decision making within a project Informs potential contributors Helps build sustainability Assures potential users Retains Control Helps the project achieve its goals Gardler, R. Hanganu, G. et al – Governance Models
- 4. What's Governance? Governance in Ubuntu http://www.ubuntu.com/about/about-ubuntu/governance Ensures... 1) There is a defined process that helps people contribute 2) Decisions are taken in a fair and transparent manner 3) Necessary decisions are taken, even when there's no clear consensus. There's also a clear path for appeal.
- 6. Benevolent Dictator Gardler, R and Hanganu, G. et al - Benevolent dictator governance model Folgel, K. - Producing Open Source Software
- 7. Qualities of a Benevolent Dictator Sensitivity to your own influence ● Letting people air ideas (even stupid ones) ● Ability to acknowledge own mistakes ● Ability to recognise good design ● Personality ● Folgel, K.
- 8. Linus's take on being nice "If you want me to "act professional", I can tell you that I'm not interested. I'm sitting in my home office wearign [sic] a bathrobe. The same way I'm not going to start wearing ties, I'm *also* not going to buy into the fake politeness, the lying, the office politics and backstabbing, the passive aggressiveness, and the buzzwords. Because THAT is what "acting professionally" results in: people resort to all kinds of really nasty things because they are forced to act out their normal urges in unnatural ways."
- 9. Meritocracy "Power for those who earn it"
- 10. Meritocracy Helen contributes work to the project Helen is elected or appointed to a leadership position Helen gains respect from peers Respect gives Helen's voice more weight in discussions Gardler, R and Hanganu, G. et al – Meritocratic governance model
- 11. Meritocracy Inclusive – Equality of opportunity ● Operates on consensus rather than votes ● "Lazy Consensus" helps expedite non-controversial decisions ●
- 12. Ubuntu – Striking a balance Read the Ubuntu Governance documentation http://oss.ly/ubuntu What are the roles? How are decisions made? Is it a Benevolent Dictatorship or a Meritocracy?
- 13. Project Management Raymond, E. - The Cathedral and the Bazaar
- 14. Cathedral Small group of experts ● Infrequent release cycle ● Heavily tested ● Contributions subject to heavy review ●
- 15. Bazaar Larger, less formal group ● "Release Early, Release Often" ● "With enough eyes, all bugs are shallow" ● Responsive to user and tester feedback ●
- 16. Bazaar More open to external contribution Apache HTTPD Linux Ubuntu Less open to external contribution GNU Emacs Apache OODT Cathedral Benevolent Dictator Less open to participatory governance More open to participatory governance Formal Meritocracy
- 17. Activity As a group, identify the roles within your project's governance structure ● ● Who has the final say in decisions? ● Discuss where your project sits on the graph. How do you communicate this information to your community and potential contributors? How could this be improved? ●
- 18. Summary Governance is important to define and communicate how your project operates ● You need to strike the right balances to retain the right amount of control while inviting the right amount of contribution ● There's no "one true way", it depends on your project's goals ● Communicating your governance model effectively is important for managing the expectations of contributors ●
- 19. References Questions? Gardler, R and Hanganu, G. et al (2013) Governance Models http://www.oss-watch.ac.uk/resources/governanceModels Gardler, R. and Hanganu, G. et al (2013) Benevolent Dictator Governance Model http://www.oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel Gardler, R. and Hanganu, G. et al (2013) Meritocratic Governance Model http://www.oss-watch.ac.uk/resources/meritocraticGovernanceModel Fogel, K. (2005) "What makes a good benevolent dictator?" Producing Open Source Software http://producingoss.com/html-chunk/social-infrastructure.html#benevolent-dictator Raymond, E. (2000) The Cathedral and the Bazaar http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ Canonical Ltd. Governance http://www.ubuntu.com/about/about-ubuntu/governance Linux Namesake argues in favour of being a jerk http://www.escapistmagazine.com/forums/read/7.822248-Linux-Namesake-Argues-In-Favor-Of-Being-A-Jerk Image Credits Cathedral, Frankfurt by Brian Burger http://www.flickr.com/photos/wirelizard/1414035429/ Istanbul - Grand Bazaar by Roger Woolstadt http://www.flickr.com/photos/24736216@N07/3498051077 Saint IGNUcius speaking by Beatrice Murch http://www.flickr.com/photos/blmurch/3001698026/ P1010100 by dazfuller http://www.flickr.com/photos/68293811@N00/4043153407
Editor's Notes
- * The rules and roles involved in making descisions within a project * What kind of decisions? * How people lose and gain power * How IP is managed, how management might change (copyright assignment? CLAs?) * How roadmaps are set * How to determine whether an issue has been closed. Also when it warrants re-opening (method of appeal?) * Important to give a project stability, and thus sustainability * Allows potential contributors to understand how to engage * Describes he QA process to give users confidence in the project's outputs * Ensures that overall control is maintained, but can provide a framework for transition if required. * Attitude to forking? * Try to keep everyone happy by being inclusive of as many ideas as possible * Encourage forking – this may actually put people off doing it due to the effort required * Provides a framework to ensure that the projects goals are met, e.g. commercial success, or just wide use * What are the metrics by which this is measured? * How are they fed back?
- * The rules and roles involved in making descisions within a project * What kind of decisions? * How people lose and gain power * How IP is managed, how management might change (copyright assignment? CLAs?) * How roadmaps are set * How to determine whether an issue has been closed. Also when it warrants re-opening (method of appeal?) * Important to give a project stability, and thus sustainability * Allows potential contributors to understand how to engage * Describes he QA process to give users confidence in the project's outputs * Ensures that overall control is maintained, but can provide a framework for transition if required. * Attitude to forking? * Try to keep everyone happy by being inclusive of as many ideas as possible * Encourage forking – this may actually put people off doing it due to the effort required * Provides a framework to ensure that the projects goals are met, e.g. commercial success, or just wide use * What are the metrics by which this is measured? * How are they fed back?
- For example, Ubuntu's governance model seeks to ensure that: * There is a defined process that helps people contribute to decisions regarding the Ubuntu community and distribution. It should be clear who is responsible for any given decision, and how others might contribute to the making of it. * Decisions regarding the Ubuntu distribution and community are taken in a fair and transparent fashion. * Necessary decisions are actually taken, even when there is no clear consensus among the community. There is a clear path for the appeal or escalation of a decision when necessary.
- Basically 2 styles of governance – Benevolent Dictatorship and Meritocracy While FOSS projects that are controlled by a sponsoring organisation might not be, Open development projects are meritocratic in nature, so "Formal Meritocracy" might be more appropriate It's not a switch where you have to pick one or the other, it's more like a scale where you need to find the right balance for your project and community.
- * There's no process for changing the leadership of the project, save for forking * The Dictator may have "leuitentants" that he or she consults * Quality developers must still have some influence, otherwise they'll leave *Folgel* * The "Benevolent" part is important, people have to like or at least repect you. No successful FOSS community project is a Malevolent Dicatatorship. If your community doesn't like how you're managing the project, they'll leave or fork it. * Ensures decisions are made as one person has the final say
- * What makes a good benevolent dictator * Sensitivity to your own influence, and thus self-restraint * Letting people air ideas, even stupid ones * Ability to acknlowledge stupid ideas * Ability to recognise good design, not necessarily do it yourself * Personality matters, you need to be likeable? Entertaining? Philanthropic? * This often means avoiding being a dick * Torvalds argues against this
- * People earn respect from the community by contributing to the project * As respect is earned (social capital is accrued), the contributor's voice carries more weight in discussions * The contributor may be appointed or elected by the community to a leadership position, or simply given commit rights
- The Cathedral and the Bazaar – Eric Raymond explores models of managing communities and soliciting engagements, particularly contrasting development of GNU Emacs with that of the Linux kernel.
- * A small core of highly committed contributors * Code developed within the core * Infrequent releases, heavily tested in private * Outside contributions might be accepted but only with heavy review
- * A large group of contributors with various levels of commitment * Contributions welcome from all * Parallises problem solving - "With enough eyes, all bugs are shallow" * More frequent, less tested releases - "Release early, release often" * "Stable" release supported for longer, "beta" releases made freqently * Responsive to user and tester feedback
- * You cannot initiate a project Bazaar-style * You need to present a plausible promise to encourage users, testers, and contributors to get involved. * You need to have something *runnable* to demonstrate this - not necessarily *complete* or *working* * The leadership needs to recognise good designs from others * Most projects will start in the bottom-left of the graph, and may move up or right as they mature * GNU Emacs – Raymond's classic Cathedral (up until c. 2008) vs Linux, the classic Bazzar * Top-level ASF projects follow Meritocratic governance * HTTPD follows a more bazaar-style model of soliciting patches from all comers * OODT is more cautious and considered – focus on quality over speed, development docs are there to reassure users, not bring in more developers * Ubuntu is somewhere in the middle – Dictatorship with clear meritocratic elements, welcoming (and sometimes reliant) on contrib, but very top-down on wider architecture decisions. * Your choice of development model may inform your choice of tools - It's no coincidence that Git supports the Bazaar style of working