On Monday, July 8, 2024 1:11:15 PM PDT Jeff Mahoney wrote:
On 7/7/24 15:47, Shawn W Dunn wrote:
Pursuant to Richard and Robert's talk at oSC 2024:
https://media.ccc.de/v/4411-we-re-all-grown-up-opensuse-is-not-suse
Thoughts?
Hi folks -
TL;DR at the end.
Others have said that governance, rebranding, and the foundation should be handled individually and with differing priorities. I disagree. I think all three are intertwined and, if handled properly, present a unique opportunity for the project to re-establish itself.
I'm absolutely in agreement with you on this, in that the conversations and concerns are intertwined. And pretty hard to just say "Well, we have three seperate issues, that need to be dealt with in their own vacuums"
openSUSE has maintained a relatively small community compared to other popular but similar projects (e.g. Fedora, Ubuntu, Arch) since its inception. I think there are a few big reasons for that.
1. The perception that SUSE owns openSUSE and contributing to openSUSE is like working for SUSE for free
Part of this is naming.
Part of this is SUSE requiring the board chair to be a SUSE employee.
Part of this _could_ be that openSUSE releases and SUSE products are inter-related, with Tumbleweed being periodically stabilized into enterprise releases and those enterprise releases being contributed back to the community to form the basis for Leap. The latter relationship is one that mirrored the relationship between Fedora / Red Hat / CentOS until recently.
It's not an exact mirror of the relationship between Fedora/CentOS/RHEL, but close enough that the minutae aren't that relevant.
Part of this is that SUSE still owns and mandates control over the infrastructure, though that is changing. The main ongoing reason for this is for security: the openSUSE and SUSE IDP authentication systems use the same backend. That means that anyone with administrative access to those systems could obtain access to corporate credentials. As a result, those systems must be managed by SUSE employees. There's a project to decouple the authentication systems underway and, IMO, once that's complete, there should be no reason why SUSE should exclude community members from any openSUSE systems.
Agreed, and I'm glad this is being worked on, I've personally been of the opinion that this should have happened a long time ago.
Part of this is that, legally, openSUSE isn't a separate organization. The Geekos foundation was set up relatively recently but it's not formally attached to the project in any way other than Patrick's motivation and commitment. Those are both substantial but also not binding.
This list is probably incomplete, but you get the idea.
Yes, this is something that seems to be a recurring misconception, where people are aware of the Geeko Foundation existing in the first place. At the moment, to the best of my knowledge, the Geeko Foundation isn't formally "attached" to openSUSE in any official capacity, and is it's own thing, uninvolved in the governance of the project.
2. The lax governance leads to inconsistent expectations
The current openSUSE board structure is a one-stop shop and I feel it's pulled in too many directions simultaneously. If we go the route of the Ubuntu-style governance, I would suggest removing the requirement for a SUSE employee to be the chair of either board and instead put that requirement in the place of the Shuttleworth role above: a very-rarely used veto or direction setting role, largely removed from the day-to-day operation of the project. The rules about limiting the number of SUSE employees on the board(s) would still apply otherwise.
Agreed, and part of the reason I ran for the board in the most recent elections, and accepted the offer to join the board to fill a vacancy, is because I've been unhappy with what's been percieved by me (and others), in the lack of clarity or purpose in the governance.
Moreover, the ad-hoc nature of pretty much every other team means that it's difficult to understand what the roles and responsibilities are for each one. In Robert's (other) talk about non-technical contributors, there was a discussion about how newcomers to e.g. the marketing team aren't always clear on what they can and cannot say or do while representing the project. The options were either to know who the right person to ask was or to default to asking for forgiveness instead of permission. That's not something a lot of people are comfortable with doing when they're new to a project. Delegating marketing to a specific team with well defined contacts, processes, and the authority to determine guidance for its members would be a good start.
Absolutely, and this has been a constant source of frustration to many contributors, myself included.
3. The project doesn't have a clear mission
The openSUSE project is largely driven by the people who do the technical work. It's a volunteer effort, so that's mostly to be expected. When there are conflicts, it's uncertain how they're resolved. Maybe it's the board. Maybe it's whomever speaks last in a drawn out discussion/argument. Maybe it's whomever gets a submit request approved first. In the Ubuntu model, the Technical Council is the tiebreaker, but it's expected to take guidance and input from the teams actually doing the work.
This has been a long-term issue within the project, for certain, and one that needs to be solved. I don't know what that *looks* like yet, and I'm certainly not the person to make that decision. It's why we need to discuss it.
Also from Robert's other talk was a comment about how in order to become a member of the project, one must have made contributions. Those contributions are typically considered technical ones. Documentation, marketing, design, community building, etc are vital to a successful open source project and those aren't recognized as much as technical contributions.
Another long term issue as well. And something we need to be better at, regardless of what happens.
That said, while there is some focus on user experience, the project mostly seems to be contributors scratching their own itches. And if that's the direction that we want the project to go, it should be a conscious decision. One of the main things that's a barrier to adoption by new users is the perception that the releases are full of small annoyances that other distros take more seriously. The arcane nature of snapper, performance of zypper, (historically) codec inclusion, and the relatively recent secure boot shim issue are some easy examples from a quick scan of reddit posts about this topic. If we want to grow the project, we'll need to take those more seriously as well.
Agreed.
If there is a renaming, I don't think it should be the gateway to make all of the projects that make up the ecosystem to be independent of one other under one umbrella. Several people in the audience at oSC mentioned that this is the path to irrelevance, and I agree. A brand tying the projects together is the identity and, more practically, what makes it easy to get relevant results when searching. A search for "openSUSE Leap" or "openSUSE Tumbleweed" yields what I expect to see as the top hit using Google. A search for "Leap" doesn't yield anything related to openSUSE until the fourth page. Tumbleweed does a bit better -- it's the last entry on the second page. Deciding on a new name won't be an easy process. There will be many ideas and fewer good ones. It will need to be easily recognizable and searchable. (I am terrible at naming things, btw.)
I couldn't agree more, regarding this. I feel like individual project that want to "go their own way" as Richard has proposed should certainly be *possible*, but I wouldn't want to make it the default for everything. We just don't have the contributor base, across the current project, for that sort of potential duplication of "infrastructure", from my perspective.
Rebranding is an expensive operation because it means getting the word out about the new brand, explaining why it came about, and (importantly) getting new swag out to community members. With a new name must come a new logo too. That will need to be designed. There will need to be new t-shirts with the logo and name given out at every opportunity. If the new logo lends itself to being a mascot, new plushies will need to be made. New stickers. People have stacks of stickers and drawers full of t-shirts that will need to be replaced. There will need to be a marketing campaign bigger than any the openSUSE project has ever done in the past. That's a lot of effort and expense. I will say that if the project decides to rebrand at SUSE's request, I will pursue support from within SUSE to make it successful.
Yeah, and that question has come up. As a board member, if a Rename/Rebrand is what is decided on, I certainly will be pushing SUSE to provide a budget and whatnot for what needs to be done. But that's not something that's easy to attach a number to, or even discuss, until the underlying questions regarding the entire idea of a Rename/Rebrand is more solidified.
Lastly, if the project is to be more independent, there needs to be a legal organization backing it that isn't SUSE. It could be the Geekos foundation, but if that is to be the case, there will need to be formal governance and accountability built into it. SUSE funds some operations of openSUSE directly now, but could potentially direct that to the foundation instead. That can't happen without a formal process in place that shows how the money will be spent, what the processes are, and a clear definition of roles and responsibilities.
Agreed.
In summary, I don't have a strong opinion on the renaming, but it could be an opportunity to revitalize the project under a new name, new governance, and new independence. That, in turn, could make the project more attractive to new contributors and users who aren't SUSE employees. With projects that used to be wildly popular on the decline, it could be the right opportunity to make a splash.
Thanks,
-Jeff
[1] https://ubuntu.com/community/governance/community-council [2] https://ubuntu.com/community/governance/technical-board [3] https://ubuntu.com/community/governance/delegation
I am currently looking into the governance of some of the other projects out there, and looking how they do things, the pros and cons, etc. And attempting to put together a bit of a summarization on what future governance *could* look like. Because at the moment, there's just not anything else on the table, and we're all just kind of flailing our arms. But thank you for the links to how ubuntu is doing it, I'll have a look.