FOSDEM 2018 - Distributions are not Democracies

This session will explore many different governance and decision making models in the Distribution world.
Few projects aspire to operate under wholly democratic principles. This talk will explore some of the many flaws and problems with this approach, and how projects often struggle to operate democratically and at scale. Alternatively the session will also discuss the benefits, and weaknesses of less democratic governance models, such as Technical Committees, Governing Boards, and Benevolent Dictators for Life. Finally the talk will explore a simple, but scalable model of Distribution governance, empowering, enabling, and supporting the contributors in your project to create an environment where "Those that do, decide".

Transcript

1. Richard Brown
   openSUSE Chairman
   rbrown@opensuse.org
   Distributions are not
   Democracies...
   ...and that’s okay
   

   View Slide

2. Does Governance Matter?
   

   View Slide

3. CC-BY-SA Gage Skidmore
   

   View Slide

4. OGL v.3
   

   View Slide

5. CC-BY-SA WDKrause
   

   View Slide

6. View Slide

7. Who does your Project
   serve?
   

   View Slide

8. Users
   

   View Slide

9. Users
   

   View Slide

10. Our Projects do not exist to benefit Users
    

    View Slide

11. Our Projects SHOULD not exist to benefit Users
    ●
    Users should benefit from the ‘Products’ of our Projects, our
    sofware, our distributions.
    ●
    But the Project exists to provide a collective benefit to our
    Maintainers/Contributors/Volunteers
    ●
    This collective benefit is made manifest in the Project’s
    structure, organisation, ethos, and ultimately how it practices
    Governance
    

    View Slide

12. Maintainers? Contributors? No, Volunteers!
    ●
    Any Open Source Sofware Project lives or dies by the actions of its’
    Contributors
    ●
    These people may write code, provide artwork, support users, or
    share ideas
    ●
    They may be employed to do that work, or not
    ●
    Unless they’re hired as slave labour, they’re still Volunteers
    ●
    Open Source Projects shouldn’t use slave labour
    

    View Slide

13. “Linux is only free if your time has no value”
    - Jamie Zawinski
    

    View Slide

14. The Curse of the
    Committee
    

    View Slide

15. Apache httpd
    ●
    All major changes must be voted on
    ●
    Any Apache developer can vote (+1), abstain (0) or veto (-1)
    ●
    Only “active httpd developers” have binding (+1) votes
    ●
    3x binding votes and no (-1) vetos required
    

    View Slide

16. View Slide

17. Scale
    ●
    Can only handle a specific capacity of incoming requests
    ●
    Adding more members to the committee can inversely afect
    committees bandwidth
    ●
    Raises barrier to entry (in either perception or reality) for new
    volunteers
    

    View Slide

18. Debian Technical Committee
    ●
    Decide on any matter of technical policy
    ●
    Decide any technical matter where Developers’ jurisdictions
    overlap
    ●
    Make a decision when asked to do so
    ●
    Overrule a Developer
    ●
    Ofer advice
    

    View Slide

19. Debian & systemd
    ●
    Technical Committee decided to support systemd by default
    ●
    No decision on whether packages may depend on a specific
    init system
    ●
    Some people don’t like systemd
    

    View Slide

20. View Slide

21. Afer the apocalypse
    ●
    Strife from Feb 2014 – Nov 2014
    ●
    Final decision “General Resolution is not required” on the
    topic of binding packages to an init system
    ●
    Lots of upset volunteers & users on each side of the debates
    ●
    Fork (Devuan)
    

    View Slide

22. Welcoming our Corporate
    Overlords
    

    View Slide

23. “Corporations Are People, My Friend”
    - Mitt Romney
    

    View Slide

24. Fedora & Red Hat
    Fedora Council
    ●
    Primary Role: identify, organise and enable the Project’s short,
    medium, and long term goals
    ●
    Currently 10 people
    ●
    8 Employed by Red Hat
    ●
    3 Directly appointed by Red Hat
    ●
    2 Elected by community (1 Red Hat employee)
    

    View Slide

25. Fedora & Red Hat
    Fedora Engineering Steering Committee
    ●
    Roles: Approval/Coordination of Changes, Maintainer Dispute
    Resolution. Responsible for what sofware is ofered to end
    users.
    ●
    Currently 9 people
    ●
    7 Employed by Red Hat
    

    View Slide

26. “In real open source, you have a right to
    control your own destiny”
    - Linus Torvalds
    

    View Slide

27. Ubuntu & Canonical
    ●
    Self Appointed Benevolent Dictator for Life
    ●
    Community Council – Appointed by SABD4L
    – Conflict Resolution, Non-Technical Decision Making, etc
    ●
    Technical Board – Appointed by SABD4L
    – Responsible for all core technical decisions
    – Package Selection, Versions, Installation Processes, etc
    ●
    Sub Teams appointed by CC or TB
    

    View Slide

28. “In real open source, you have a right to
    control your own destiny”
    - Linus Torvalds
    

    View Slide

29. openSUSE & SUSE?
    

    View Slide

30. Direct Democracy
    

    View Slide

31. “It has been said that democracy is the worst
    form of government except all the others that
    have been tried.”
    - Winston Churchill
    

    View Slide

32. openFATE
    ●
    openSUSE equivalent to SUSE’s internal feature tracking tool
    ●
    Designed to allow the community to propose features & vote
    on them
    ●
    Hundreds of feature requests
    ●
    Thousands of votes
    ●
    Impact on Project’s priorities: Negligible
    

    View Slide

33. “Democracy is the art and science of
    running the circus from the monkey cage”
    - H. L. Mencken
    

    View Slide

34. Back, to the Future!
    

    View Slide

35. “Every good work of software starts by
    scratching a developer’ personal itch”
    - Eric S. Raymond
    

    View Slide

36. You don’t need to tell Volunteers what to do
    ●
    They are going to know what needs to be done
    ●
    They need to have the tools and environment to do it
    ●
    They need to feel empowered that they can do it
    

    View Slide

37. You don’t need to tell Volunteers what to do
    ●
    They are going to know what needs to be done
    ●
    They need to have the tools and environment to do it
    ●
    They need to feel empowered that they can do it
    ●
    If you tell them what to do, they won’t listen anyway
    

    View Slide

38. Core Principles
    ●
    Respect your Volunteers
    – They don’t have to work with you
    ●
    Enable your Volunteers
    – They need the tools and processes to do their work
    ●
    Trust your Volunteers
    – The best person to decide anything, is the volunteer doing that
    thing
    

    View Slide

39. Core Principles, Pt 2
    ●
    Respect, but Challenge
    – New volunteers should be able to work with, or replace, another
    ●
    Enable, but Guide
    – The tools and processes should encourage good practices for
    sustainable maintainership
    ●
    Trust, but Verify
    – When conflicts of opinion arise, you need a tie-breaking solution
    

    View Slide

40. “Those who do, decide”
    - openSUSE
    

    View Slide

41. “Those who do, decide”
    ●
    Open Source works best when decisions are made as close as
    possible to the actual contribution – ie. the Volunteers doing
    the work
    ●
    Self-organised Teams - Volunteers working on the same thing
    should work together
    

    View Slide

42. “Those who do, decide”
    ●
    Quality & Common Standards defined by consensus,
    enforced by Open Source automation overseen by willing
    senior Volunteers (Release Managers/Engineers)
    

    View Slide

43. Do-ocracy In Action
    ●
    Anyone can login to openSUSE’s OpenBuildService and
    submit any change to any package
    ●
    No Permission Required. Existing Volunteers will be
    automatically notified & given the opportunity to review your
    change
    

    View Slide

44. Do-ocracy In Action
    ●
    Contributions do the talking. Automated OBS checks &
    openQA functional testing ensure your change will work.
    Majority of review efort is therefore contemplating “how easy
    is it to carry this change ?”
    ●
    No Steering Committees, Community Managers, Technical
    Boards, Benevolent Dictators or Project Managers
    

    View Slide

45. openSUSE & systemd
    ●
    First major distribution to adopt systemd (July 2010)
    ●
    Default since September 2012
    ●
    Changes made by volunteers who wanted it
    ●
    Volunteers who didn’t want it always had the opportunity to
    contribute in a diferent direction
    ●
    No major strife
    

    View Slide

46. View Slide

47. Do-ocracy - Benefits
    Agility – Able to rapidly respond to changes in upstream projects &
    adopt new technologies
    Flexibility – Every upstream is diferent, with diferent release
    schedules and support lifecycles, openSUSE volunteers can adapt their
    way of working for maximum eficiency and comfort
    Freedom – No restrictions on finding innovative solutions. “If it works,
    and you’ll support it” is the primary acceptance criteria.
    

    View Slide

48. Do-ocracy - Risks
    Freedom – “Paradox of Choice” - too many choices can be overwhelming
    to new volunteers
    Misconceptions – Established volunteers may be seen as de-facto
    decision makers and inadvertently discourage new innovative volunteers.
    Few newcomers want to ‘rock the boat’ even when the Project welcomes
    it.
    Deadlock – Multiple volunteers may not always agree, who decides if
    compromises cannot be found?
    

    View Slide

49. Organisational
    Checksums
    

    View Slide

50. View Slide

51. Conflicts happen
    ●
    Volunteers are human (mostly)
    ●
    Humans have diferent ideas
    ●
    Sometimes these diferent ideas are not compatible with each
    other
    ●
    Compromises can be hard to find
    

    View Slide

52. Conflicts are not technical decisions
    ●
    Volunteers arguing over a technical diference is NOT a
    technical problem
    ●
    Conflict resolution needs a human touch
    ●
    All sides need to be heard, and feel they were heard
    

    View Slide

53. Conflicts are not technical decisions
    ●
    Compromises can be found to the strangest problems
    ●
    Decision making in conflicts must ALWAYS be a last resort
    ●
    Previously conflicting volunteers ultimately will still be
    implementing the solution
    

    View Slide

54. If you have a problem...
    

    View Slide

55. openSUSE Board
    “Leads” the overall Project
    ●
    Helps resolve conflicts
    ●
    Central point of contact
    ●
    Decision makers of last resort
    ●
    Communicates community interests to SUSE (and visa versa)
    

    View Slide

56. openSUSE Board Composition
    5 Board Members
    ●
    Elected by established contributors (openSUSE Members)
    ●
    2 year term
    ●
    2-3 elected each year
    ●
    No more than 2 Board Members can have same employer
    

    View Slide

57. openSUSE Board Composition
    1 Chairperson
    ●
    Appointed by SUSE
    ●
    Full voting Board Member, with additional responsibility to
    provide continuity and to represent SUSE to the Board &
    Project
    ●
    Elected Board Members can appeal to replace Chairperson
    

    View Slide

58. “Corporations Are People, My Friend”
    - Mitt Romney
    

    View Slide

59. Corporations can be people too
    ●
    In a do-ocracy, a corporation must contribute as peers
    ●
    No control, besides that which they share as volunteers in the
    project
    ●
    They have to keep up with their ‘upstreams’ - other volunteers
    create work for them
    ●
    They have to persuade the project at large to work with them
    ●
    Keeps them honest
    

    View Slide

60. Corporations know how to do this
    ●
    Kernel
    ●
    OpenStack
    ●
    Xen
    ●
    Almost all open source corporations practice these principles with
    their ‘upstreams’, but many shirk doing so in their own
    distributions
    

    View Slide

61. In Conclusion
    

    View Slide

62. ❤ your Volunteers
    ●
    Distributions, get rid of your Technical Committees and
    Dictators
    ●
    Favour Do-ocracy over Democracy
    ●
    Trust & Empower your Volunteers to drive your project
    ●
    Have a conflict resolution/mediation body. Limit their scope.
    ●
    Corporations, yield control. Treat your distribution communities
    like your other upstreams.
    ●
    Have a lot of fun!
    

    View Slide

63. Join Us at www.opensuse.org
    

    View Slide

64. License
    This slide deck is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license.
    It can be shared and adapted for any purpose (even commercially) as long as Attribution is given and any
    derivative work is distributed under the same license.
    Details can be found at https://creativecommons.org/licenses/by-sa/4.0/
    General Disclaimer
    This document is not to be construed as a promise by any participating organisation to develop, deliver, or
    market a product. It is not a commitment to deliver any material, code, or functionality, and should not be
    relied upon in making purchasing decisions. openSUSE makes no representations or warranties with respect
    to the contents of this document, and specifically disclaims any express or implied warranties of
    merchantability or fitness for any particular purpose. The development, release, and timing of features or
    functionality described for openSUSE products remains at the sole discretion of openSUSE. Further,
    openSUSE reserves the right to revise this document and to make changes to its content, at any time,
    without obligation to notify any person or entity of such revisions or changes. All openSUSE marks
    referenced in this presentation are trademarks or registered trademarks of SUSE LLC, in the United States
    and other countries. All third-party trademarks are the property of their respective owners.
    Credits
    Template
    Richard Brown
    rbrown@opensuse.org
    Design & Inspiration
    openSUSE Design Team
    http://opensuse.github.io/branding-
    guidelines/
    

    View Slide