A general look into the openSUSE Project, where we've come from, what we're working on, and what sets us apart from other similar open source projects.
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 staf to also contribute in their spare time
is also used by SUSE internally, including Open Build Service, openQA & KIWI • Not just tools & technology, openSUSE processes ofen inspire improvements to SUSE development processes
to set it’s own direction & all that entails • Examples – Diferent default desktop (KDE in openSUSE, GNOME in SLE) – Diferent product scope (Unified openSUSE Distros, SLES/SLED) – Diferent installation workflow
Both openSUSE Distributions are GPLv2+ collective works • Limited “NonFree” Sofware available in Additional Repo – Does not include closed source Linux kernel modules • No CLA / Copyright Agreement Your contributions, your copyright
decisions are made as close as possible to the actual contribution – ie. the person doing the work • Self-organised Teams - People working on the same thing should work together
by consensus, enforced by willing senior contributors (Release Managers/Engineers) • No Steering Committees, Community Managers, Technical Boards, Benevolent Dictators or Project Managers
rapidly respond to changes in upstream projects & adopt new technologies Flexibility – Every upstream is diferent, with diferent release schedules and support lifecycles, openSUSE contributors 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.
Choice” - too many choices can be overwhelming to newcomers Misconceptions – Established contributors may be seen as de-facto decision makers and inadvertently discourage new innovative contributors. Few newcomers want to ‘rock the boat’ even when the Project welcomes it. Deadlock – Multiple contributors may not always agree, who decides if compromises cannot be found?
and Substantial” contributions to the openSUSE Project • Receive @opensuse.org email addresses • Voting rights in Board Elections & Major Decisions • Has right to recall the Board (25%+ recall vote required)
Full voting Board Member, with additional responsibility to provide continuity and to represent SUSE to the Board & Project. • Holds veto power. • Elected Board Members can appeal to replace Chairperson.
– [email protected] - 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 – Of Topic chat – #opensuse-* @ irc.freenode.net – Many more channels available
sure you know what you’re talking about Research • Google, openSUSE wiki, other FOSS Projects. Where have others tried and failed? Discuss • Bounce ideas of other interested people in IRC, at openSUSE Conferences, etc
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
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 diferently
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 diferent at this point is not a ‘failure’, but a learning experience
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
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 diferent directions can ofen be resolved by accomplishing both
2006 • Used to reproducibly build the openSUSE® & SUSE® distributions • Can also build packages for other distributions (Fedora/Red Hat, Ubuntu, Debian, Arch, etc) • Also used by ownCloud, Endless Linux, Linux Foundation, VideoLAN (VLC), Dell, Cray, Intel and more. http://openbuildservice.org
Able to fully test Linux distributions from install to user applications • Integral part of the openSUSE® Tumbleweed & Leap process • Used by SUSE® to test SUSE Linux Enterprise • Recently adopted by Red Hat to test Fedora http://open.qa
not scary • More actively contributing SLE code back to openSUSE helps both • Result is more stable for openSUSE users • SLE engineers more actively engaged with ongoing upstream developments • ‘Investing in the Future’ - Less chance of regressions for SLE 15 Such contribution encourages alignment with SLE, which aids an accelerated pace of SLE development, which furthers aid openSUSE development. Repeat ad infinitum.
based on the SLE sources PLUS their openSUSE packages? – As stable as Enterprise Linux – As broadly featured as Community Linux – The perfect Stable Distro for Desktops & Servers?
changing, always needing to adjust workflows • The Arch Way - “Do it yourself, it’s a learning exercise” • The Gentoo Way - “Do it yourself, and you can read the Arch wiki while everything is compiling” • Something went wrong or changed in a way you don’t like? Too bad, good luck undoing it, you can always start again
rolling releases, rely on “Passive Testing” • Put new packages in a “Testing Branch”, wait X days then assume “it’s good enough” and ship! • Works better or worse depending on size of developer & testing communities • Still basically Russian Roulette
install uses btrfs & snapper • Automatically configured to snapshot root filesystem when packages are installed • Unwanted changes can be safely rolled back, even from GRUB
Read Only btrfs Filesystem • Kubernetes • All without reinventing packaging (using rpm, not ostree/snap) • Tumbleweed-Kubic prototypes available now • Leap-Kubic coming soon
communities out there • Community led & driven; while still backed by a strong corporate partner that does not, and cannot, exert excessive control • Leading Innovators in the areas of sofware integration, testing & delivery/distribution • Believers in the motto “Have a lot of fun!”
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 [email protected] Design & Inspiration openSUSE Design Team http://opensuse.github.io/branding- guidelines/
sysrich
shukob
karugamo
n3xem
ivargrimstad
l2hyunwoo
ma_cho29
yusukebe
alexanderschranz
chobishiba
mototakatsu
marcelgsantos
kutakutat
bcantrill
kneath
brettharned
addyosmani
danielanewman
trallard
andyhume
ufuk
panda_program
notwaldorf
holman
vanstee
![Richard Brown openSUSE Chairman [email protected] A Reintroduction](https://files.speakerdeck.com/presentations/d44ae883bab64b2c98449982d8dc7762/slide_0.jpg){kind=link}
![Primary Communication Channels Mailing Lists – [email protected] - Development list](https://files.speakerdeck.com/presentations/d44ae883bab64b2c98449982d8dc7762/slide_27.jpg){kind=link}
![“Every good work […] starts by scratching a […] personal](https://files.speakerdeck.com/presentations/d44ae883bab64b2c98449982d8dc7762/slide_28.jpg){kind=link}
