openSUSE is what you make it

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.

C4d991702dcb0afa2b2afd8464be7f66?s=128

Richard Brown

May 25, 2018
Tweet

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
  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
  3. None
  4. Tumbleweed

  5. None
  6. “Every good work of software starts by scratching a developer’

    personal itch”
  7. None
  8. None
  9. None
  10. “Those who do, decide”

  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
  12. “Those who do, decide” • Quality & Common Standards defined

    by consensus, enforced by Open Source automation overseen by willing senior Volunteers (Release Managers/Engineers)
  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
  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
  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
  16. None
  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.
  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?
  19. Organisational Checksums

  20. None
  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
  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
  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
  24. If you have a problem...

  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
  26. Getting Started with Contributing

  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
  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
  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
  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
  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
  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
  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
  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
  35. Do It You’re all set! Get to work. Start your

    engines! Time to inconvenience some electrons with your code!
  36. SUSE & openSUSE

  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
  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
  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
  40. SUSE & openSUSE – Working Together Stable code & contributions

    Upstream innovations Mutual collaboration
  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
  42. YaST Example

  43. What is YaST • Yet another Setup Tool • Installation

    and Adminitration tool of openSUSE • Mostly developed inside SUSE
  44. How can you contribute? • Write your own module •

    Fix your favorite bug • Implement your missing feature
  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?
  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
  47. Need help to implement your change? • Don’t hesitate to

    ask! • yast-devel@opensuse.org • #yast channel on freenode.org
  48. Created a PR and nothing happened? • Yes, that can

    happen :-( • Contact us to get our attention • Do not take any feedback personally
  49. Anything you can help with? • YES!!! • Why not

    to try fixing a simple bug? • https://bugzilla.opensuse.org/buglist.cgi?quicksearch=yast-community
  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 :-)
  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!
  52. Join Us at www.opensuse.org

  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/