openSUSE is what you make it

How to change anything you want in the project

This talk is for openSUSE's aspiring new contributors, existing contributors, users, detractors, or just anyone curious at all about openSUSE. In other words, if you're at this conference, you should consider being at this talk ;)

The session will detail how openSUSE does what it does, and most importantly how openSUSE strives to empower ANYONE to be able to contribute to the project.

The presentation will outline examples of not only basic contributions to the distributions (Leap & Tumbleweed), but also explain through example and anecdote how anyone can influence, steer, and drive the direction of the openSUSE Project, including changing the scope of the Project by introducing new sub projects.

The session will end with a Q&A section for anyone to ask any question about contributing to the project in general, to provide feedback on any potential improvements to openSUSE's current contribution story, or to ask those first questions about that first contribution so that YOU can start making openSUSE YOURS.

Transcript

1. Richard Brown
   openSUSE Chairman
   rbrown@opensuse.org
   How to change anything
   openSUSE is what you make it
   Jiri Srain
   Project Manager
   Future Technology Team
   jsrain@suse.com
   

   View Slide

2. The openSUSE Project
   ●
   Open Source Community Project sponsored by SUSE
   ●
   Founded to “Promote the use of Linux everywhere”
   ●
   Produced the openSUSE Distribution
   ●
   Announced 9th August 2005
   

   View Slide

3. View Slide

4. Tumbleweed
   

   View Slide

5. View Slide

6. “Every good work of software starts by
   scratching a developer’ personal itch”
   

   View Slide

7. View Slide

8. View Slide

9. View Slide

10. “Those who do, decide”
    

    View Slide

11. “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

12. “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

13. “Those who do, decide” 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

14. “Those who do, decide” In Action
    ●
    Contributions do the talking. Automated OBS checks &
    openQA functional testing ensure your change will work.
    Majority of review effort 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

15. 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 different direction
    ●
    No major strife
    

    View Slide

16. View Slide

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

    View Slide

18. “Those who do, decide” - 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

19. Organisational
    Checksums
    

    View Slide

20. View Slide

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

    View Slide

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

    View Slide

23. 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

24. If you have a problem...
    

    View Slide

25. openSUSE Board
    “Leads” the overall Project
    ●
    Act as a central point of contact
    ●
    Helps resolve conflicts
    ●
    Decision makers of last resort
    ●
    Communicates community interests to SUSE (and visa versa)
    ●
    Initiates discussions about new project-wide initiatives
    

    View Slide

26. Getting Started with
    Contributing
    

    View Slide

27. Primary Communication Channels
    Mailing Lists
    – opensuse-factory@opensuse.org - Development list
    – opensuse-project@opensuse.org - Project related list
    – https://lists.opensuse.org - Index of more specific lists
    IRC
    – #opensuse-factory @ irc.freenode.net – Development chat
    – #opensuse-project @ irc.freenode.net – Project related chat
    – #opensuse-chat @ irc.freenode.net – Off Topic chat
    – #opensuse-* @ irc.freenode.net – Many more channels available
    

    View Slide

28. Do your homework
    Understand your topic
    ●
    Don’t assume, make sure you know what you’re talking about
    Research
    ●
    Google, openSUSE wiki, other FOSS Projects. Where have others tried and failed?
    Discuss
    ●
    Bounce ideas off other interested people in IRC, at openSUSE Conferences, etc
    

    View Slide

29. Plan your solution
    Knowing what you want to do is only the beginning
    Plan your solution, answer “how will you do it?”
    Details optional
    – Be sure on the direction and final outcome, details can always be
    finalised while in progress
    

    View Slide

30. Do you need help?
    If “No”
    – DON’T WAIT, proceed directly to ‘Do it’
    If “Yes”
    – Share with Project, Listen, Respond, and then Decide how to do
    it
    

    View Slide

31. Getting Help – Share with the Project
    Present plan
    – Avoid open ended questions
    – “This is what we need to do, and what I intend to do about it”
    – Describe findings from “Do your homework”, include proofs of concept if
    possible
    – Post on appropriate openSUSE Mailinglist
    It’s now the responsibility of the Project to convince you to do things
    differently
    

    View Slide

32. Getting Help – Listen
    Listen to feedback
    – The openSUSE Project contains many experienced contributors, listen to them.
    – Consider their feedback.
    – A well informed & well reasoned proposal should illicit well reasoned &
    informative responses
    Deciding to do something different at this point is not a ‘failure’, but a
    learning experience
    

    View Slide

33. Getting Help – Respond
    Respond to feedback
    – Fast feedback drives innovation.
    – Discuss why you do, or do not agree with feedback.
    – Explain why.
    These discussions are how you find colleagues to
    contribute with you
    

    View Slide

34. Getting Help – Decide
    Decide what to do
    – You do not need to accept all, or any, of the feedback
    – If you remain convinced that your planned course is correct, continue
    on it
    – If something gets in the way, find compromises
    Two competing solutions in different directions can often be
    resolved by accomplishing both
    

    View Slide

35. Do It
    You’re all set!
    Get to work.
    Start your engines!
    Time to inconvenience some electrons with your code!
    

    View Slide

36. SUSE & openSUSE
    

    View Slide

37. SUSE & openSUSE
    ●
    openSUSE is an independent Open Source Project
    – Sponsored by SUSE, AMD, IP Exchange, B1 Systems, Heinlein &
    AppliedMicro
    ●
    SUSE acts as primary sponsor & patron
    ●
    SUSE formally contributes as peers in the community &
    encourages it’s staff to also contribute in their spare time
    

    View Slide

38. SUSE & openSUSE – Working Together
    ●
    Leap shares a common code base with all SUSE Linux
    Enterprise Service Packs
    ●
    Tumbleweed will provide the base for all future SUSE Linux
    Enterprise Major Releases
    

    View Slide

39. SUSE & openSUSE – Working Together
    ●
    Complete openSUSE Toolchain is also used by SUSE internally,
    including Open Build Service, openQA & KIWI
    ●
    Not just tools & technology, openSUSE processes often inspire
    improvements to SUSE development processes
    

    View Slide

40. SUSE & openSUSE – Working Together
    Stable code & contributions
    Upstream innovations
    Mutual collaboration
    

    View Slide

41. SUSE & openSUSE – Working Separately
    ●
    openSUSE is free to set it’s own direction & all that entails
    ●
    Examples
    – Different default desktop (KDE in openSUSE, GNOME in SLE)
    – Different product scope (Unified openSUSE Distros, SLES/SLED)
    – Different installation workflow
    

    View Slide

42. YaST Example
    

    View Slide

43. What is YaST
    ●
    Yet another Setup Tool
    ●
    Installation and Adminitration tool of openSUSE
    ●
    Mostly developed inside SUSE
    

    View Slide

44. How can you contribute?
    ●
    Write your own module
    ●
    Fix your favorite bug
    ●
    Implement your missing feature
    

    View Slide

45. How do you provide your code?
    ●
    Devel project in Open Build Service
    – https://build.opensuse.org/project/show/YaST:Head
    – Similar branches for older releases
    ●
    Wait: What about git repo?
    

    View Slide

46. How do you provide your code correctly?
    ●
    https://github.com/yast/
    ●
    Find and fork the needed repository
    ●
    Implement your change
    ●
    Create a Pull Request
    ●
    Answer the reviewer comments
    ●
    Get it approved and merged
    

    View Slide

47. Need help to implement your change?
    ●
    Don’t hesitate to ask!
    ●
    yast-devel@opensuse.org
    ●
    #yast channel on freenode.org
    

    View Slide

48. Created a PR and nothing happened?
    ●
    Yes, that can happen :-(
    ●
    Contact us to get our attention
    ●
    Do not take any feedback personally
    

    View Slide

49. Anything you can help with?
    ●
    YES!!!
    ●
    Why not to try fixing a simple bug?
    ●
    https://bugzilla.opensuse.org/buglist.cgi?quicksearch=yast-community
    

    View Slide

50. Where can you learn more?
    ●
    https://en.opensuse.org/Portal:YaST
    ●
    http://yast.opensuse.org/
    ●
    And, most importantly: Just ask if you need more :-)
    

    View Slide

51. In Closing
    ●
    You decide what happens in openSUSE
    ●
    No part of the project is off limits to contributors
    ●
    The Project is here to help
    ●
    Have a lot of fun!
    

    View Slide

52. Join Us at www.opensuse.org
    

    View Slide

53. 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