Mailinglist Archive: opensuse-project (76 mails)

< Previous Next >
Re: [opensuse-project] 2019-04-02 board meeting minutes
Hi,

On pią, Apr 19, 2019 at 5:14 PM, Richard Brown <RBrownCCB@xxxxxxxxxxxx> wrote:
DISCLAIMER: As Chairman of the Board, there are times I speak on
behalf of SUSE or the openSUSE Board.
This is not one of those times.
This is a topic which cuts right through my formal responsibilities as
openSUSEs Chairman and my longer standing personal commitments to the
Project.
Therefore I ask that everyone considers what I sahare in this thread
as my own personal view, and should absolutely not be considered to be
an official view of SUSE or the Board.
That said, I know what I say is obviously informed by my unique
position, so risk being interpreted with extra weight.
I want to make sure the parties I work most closely with have an
opportunity to correct, elaborate, or respond to anything I say.
As I expect the Board are all here I don't have to worry about them,
but I'm CCing Thomas Di Giacomo (President of Engineering, Product and
Innovation @SUSE) so he knows what's being said here and can either
step in to speak on behalf of SUSE or prompt me if I need to speak in
a more formal capacity.

> SUSE has also given a commitment that they will continue
> to provide openSUSE with all the core infrastructure they need for
> shipping releases and have reaffirmed this position to the board in
> recent weeks.
Ok. Is there a public statement from SUSE about that? It's cool that
somebody from SUSE told the board something, but how valuable is that in
the moment where SUSE is changing owner again? That is why I think the
board should try to get SUSE to make public statements about these things.

When EQT purchased SUSE, the Board didn't need to do anything to get
SUSE to reaffirm that commitment;
SUSE's CEO contacted me directly (waking me up early in the morning on
a vacation day no less) so I could provide such a statement on SUSE's
behalf personally to the community.

https://lists.opensuse.org/opensuse-project/2018-07/msg00000.html

This commitment has been repeated and reaffirmed at every opportunity,
in both formal and informal settings, pretty much whenever anyone from
SUSE's executive ever mention the words 'openSUSE'.
If I relayed them all to the mailinglists, I expect people would get bored.

There are many factors at play here (which I fear I delve into in
excessive detail below), but I personally do not have a shred of doubt
regarding SUSE's senior management commitment to openSUSE.

Let's go back in time, far far before all this happened, and explore the darkest
scenario.

Novell's commitment to openSUSE didn't stop them from signing agreement with
Microsoft, which was not well recieved in the community. There are some
decisions which might seem like a good idea from "this will benefit openSUSE"
PoV, but at the same time are "this will hurt other communities about which we
care". Community after all are not just openSUSE evangelists, they are people,
which contribute to stuff not only within the project, but also to the entire
ecosystem of communicating vessels of open source software. I would like to
understand, because I know it's impossible to go out into community and ask
about an agreements before they are finalized, openSUSE elects a board, is there
a policy to talk about such potential topic with them?

>> There would be topics enough to discuss I think, and to try to get real
>> commitments from SUSE. A few examples:
>>
>> a) Commitment to keep openSUSE as base distro for SUSE's enterprise
>> products. How would openSUSE look like if SUSE suddenly jumps on a deb
>> based distro to ship interesting enterprise applications? What would
>> currently hinder SUSE to do that?
> Legacy heaps of legacy, SUSE's enterprise customers do not want to be
> forced to make more changes then they need, swapping the underlying
> distro would probably cause most customers to consider other alternative
> distro's, I really don't see this ever happening.

Ok. I am not saying it is what will happen, more as an interesting
thought. In this sense, let me play the devils advocate: The "underlying
distro" is becoming more and more commodity, nothing SUSE can
differentiate from others big times any more. Customers loose interest
in the base since years. So why not joining the big community of people
doing deb based base systems with less people and concentrate with a
bigger number of developers on the enterprise apps that do differentiate?

I feel there is nothing wrong with your 'devils advocate' approach.
While it stand by my strong belief in SUSE's stated commitment to
openSUSE, I am also of the growing opinion that the execution of that
commitment is missing the desired mark on some fronts.

From a 'code/product' perspective, the story around
SLE/Leap/Tumbleweed is one which both SUSE and openSUSE can be proud
of and is a exemplar of a Company working with an empowered community
which I honestly believe more Companies and Projects should aspire
towards.
SUSE has even codified this way of working in it's formal Open Source
Policy, which is a key plank of the companies OpenChain certification:
https://opensource.suse.com/suse-open-source-policy.html
Yast, OBS, SUSE Manager/Uyuni, there are lots of good examples of SUSE
doing things right across the company.

But I do not share such positive views regarding all of SUSE's products.
Across significant parts of SUSE's portfolio there is a noticeable
absence of any effort to foster the same kind of productive
Community+Company collaboration that we are used to in openSUSE.
It is my strong personal view that SUSE needs execute better in this
regard, for its own benefits as much as for assisting the vibrancy and
general good health of the openSUSE Project.

Studio is calling, it would like its code open :P

And then there is the example of openSUSE Kubic & SUSE CaaSP, a
situation I am very closely involved in, and yet have very few
positive words to share.
One good thing I can say is that it all started with the best of
intentions to establish the sort of relationship missing with other
SUSE products and do things the right way.
Sadly, there have been times working on Kubic I have been requested by
SUSE to say publicly things & act in a way which I feel would have
compromised not only SUSE & openSUSE's best interests, but also my
personal responsibility to always act in a truthful manner when
interacting with fellow openSUSE contributors and our upstreams.
I will not air dirty laundry in detail here, but needless to say, my
faith in SUSEs ability to always do the right thing has been shaken.

While I do still believe SUSE's commitments from management, I do not
believe that it is possible for an organisation as large as SUSE to
always execute on those commitments in the way that it wants to.
This statement should not be controversial - if there wasn't truth to
it, the role of the Board to communicate communities needs to SUSE
would not already exist.

So even if I do have faith that SUSE will address the internal issues
there, I've become acutely aware of the potential damage openSUSE can
be exposed to when things don't work according to plan.
It has only been through actions of a few good people in and out of
SUSE who have largely mitigated the damage, and continued Kubic going
forward in an exceptionally healthy direction.
I don't want openSUSE to only be dependant on a few good people to
always bail it out when things go wrong - the Project should be
structured in a way to minimise the need for such exceptional
intervention.

I believe introducing an element of formal independence (or 'less
dependence') is a good step forward for both openSUSE and SUSE.

>> b) Lots of infrastructure topics
>> c) Investments of workforce into the build service for example.

And this is a similar situation, where commitment has not been met by execution.
openSUSE is in continual need of investment in terms of both hardware
and manpower to "keep the lights on" with it's current infrastructure.
openSUSE's guiding principles state SUSE will provide such
infrastructure:
https://en.opensuse.org/openSUSE:Guiding_principles#Governance
I think it is safe to say that SUSE has been unsuccessful in providing
openSUSE with sufficient quantities of both.
openSUSE suffers from an increasing age and fragility of its
infrastructure, and an increased reliance again on the exceptional
actions of a few good people, diving in when things go wrong to save
the day.
Again, I don't want openSUSE to be dependant on such exceptionalism -
we need the Project to be able to stand on it's own two feet.

Heroes are doing what they can to improve the state, but that's absolutely true,
worst of all, they don't have access to some critical stuff, like bugzilla-o-o,
forums-o-o, www-o-o, instead relying on Micro Focus to manage that properly.

In this area openSUSE is even more hamstrung than when looking at the
'code' perspective.
With code our contributors have the power to commit what they like and
steer openSUSE regardless of SUSE's contributions (or lack thereof).
With infra, as openSUSE currently has no legal entity, we are wholly
and utterly dependant on SUSE to take legal ownership of any hardware
donated to openSUSE.
This can complicate any donation of hardware or services to openSUSE,
not just in a practical sense (more people to talk to), but in a
financial one also.
I believe many companies would be far more comfortable donating to an
independent charitable body than having to sign over their hardware or
services to a commercial entity such as SUSE.
In other words, whereas with code openSUSE already enjoys a
significant amount of the autonomy it needs in a practical sense, from
an infrastructure perspective openSUSE is entirely dependant on SUSE
and SUSEs execution is not meeting its stated commitments here.

So here, I also feel an element of independence/less dependence on
SUSE is best for openSUSE.
There is an argument to be made that this will make things 'easier'
for SUSE also, a situation I am personally uncomfortable about,
because I do not think SUSE's failure to fulfil its commitments in
this area should be rewarded by openSUSE making steps to reduce SUSEs
needs to fulfil it's commitments.

I do have hope that SUSE will be stepping up to address these issues
regardless of what openSUSE decides to do regarding independence. I
think that is something SUSE should take care of.
All of the people involved in the discussions so far are showing a
pragmatism which I trust will cut through any emotion which would
otherwise risk the best outcomes for all involved.
I think that's essential - this shouldn't be an effort driven by
emotion, but by pragmatism, seeking to find the best way forward for
openSUSE & SUSE.
In an ideal world these circumstances should not have arisen, but the
Board, the Project, and SUSE, need to act on the realities we live in,
not the ideals we hope to reach.

Even with that hope, there still "what's best for openSUSE?" echoing in my mind.
As openSUSE's patron, SUSE has been owned by many companies before
reaching it's current state of independence.
While each of those transitions in recent years have been beneficial
to openSUSE, and there are no SUSE 'stage changes' on the horizon, the
future is unwritten and always brings with it risk that 'next time'
might not be so fortuitous.
With openSUSE in an imperfect, but healthy and productive relationship
with SUSE, now is a better time to structure openSUSE in a way to
potentially mitigate any risks the future may hold, rather than
waiting for things to be in a state where there is no good way
forward.

I see you finally read my initial email starting this whole thing, nice :P

The vision what openSUSE will do, what it will head for, how it will
stay relevant if it loosens the relationship with SUSE

My personal vision is simple.
I want both openSUSE and SUSE to be able to have their own cakes and
to eat each others.
Put bluntly, I want openSUSE to have the legal structures and entities
it needs to be able to do it's own things, have it's own
infrastructure, run it's own services, raising it's own money.
At the same time, I want SUSE to be contributing to openSUSE more
heavily than it already does, with more of it's products more engaged
with openSUSE's codebases and tooling, with SUSE funding openSUSE at
least as much as it does now.
Sure, I realise this is a lot to ask, but I not only believe this is
possible, but it's best for all involved.

A more independent openSUSE with it own money, infrastructure
(including some donated by SUSE), should find itself more easily doing
what we already do.
This will benefit SUSE as long as openSUSE does it right and SUSE
continues to work closely and collaborate with openSUSE.
In other words - if openSUSE is able to do more on its own, how is
that anything but a benefit to SUSE as long as SUSE is still able to
take what openSUSE is doing and turn it into something commercially
viable?

There is nothing that says SUSE needs to formally own openSUSE to
productively work with openSUSE.
SUSE is "the open open source company" - it should be able to handle
it's partner community having a more open relationship than our peers
in the Red Hat/Ubuntu worlds.

Let's rag on openSUSE for a second here.

YaST on Fedora/Ubuntu when? In all seriousness, there is a fair share of
software, developed by openSUSE has not been fully beneficial to other
distributions, which is a shame. There is a visible group of people that would
be happy to be able to run OBS on Fedora or Debian, but they can't do that with
latest version, because it requires heavy patch work. Solution to that is
*fairly* easy, copy openQA packaging:

* put OBS in %_datadir and %_libexecdir (this differs for Fedora in this case,
to be /usr/libexec and not Debian's/openSUSE's /usr/lib), allow to change all of
this at build time

* have a working rpmspec for Fedora as well as openSUSE (alright, this is harder,
especially since SUSE/openSUSE specs have some obsession with backwards compat
with sysv macros, and ends up defining own macro in the spec, instead of using
systemd one, which is way more cross distro)

* allow ruby packaging to not be that version precise, because Fedora packages
gems and openSUSE bundles gems for OBS specifically

* test other distros while developing OBS

But why? It encourages to contribute to the software which you can run on you
favourite distro afterwards :D

Then there is a topic of YaST, which I feel like I should just leave for
another time, too much stuff. In both cases only fragments of openSUSE
software have been somewhat useful to other distros, libyui to Manatools
and obsbuild to Fedora (and OBS 2.7 as a whole to Debian, but that required
quite a bit of work to get there, and was dropped rather quickly when it
didn't prove useful enough with their process).

When you say "we" here, you mean the board, right? Feels strange to me
that this kind of important topic is worked through by the board and
later be presented to the community. But maybe that is only me.

There is absolutely no way this topic will see any conclusion of any
form without significant involvement from the community and (if it
comes to it), binding votes from the membership regarding any
constitutional change to the Project.

I feel like everybody should just read documentation on Foundation from back in
the day. There are a bunch of drawbacks, which will most likely come up as we go
along with all this.

And keep in mind openSUSE contains a trademark inside of its name, I wonder how
that will go :/

At these early stages, I think it's best the Board acts under its
"Communicate community interests to SUSE" charter while scoping out
the scale, plausibility, and practicality of the options, before
presenting them to the community in a more cohesive way for serious
consideration.
I have trust, faith, and confidence in my board colleagues desires to
accurately reflect the needs and desires of the community at large, as
they understand them.
Meanwhile the Board has been minuting these efforts in it's meetings,
and sharing those publicly with the expectation that it _would_ cause
discussions like this.
Every post in this thread is welcome and helpful, both to inform the
discussions, but to help everyone understand where this is coming from
so, I hope, we can all find the best solutions going forward.

IOW - If you agree or disagree with anything I say in this mail, good,
please add your feelings to this debate. That's the best way you can
contribute to this part of the Project right now.

LCP [Stasiek]
https://lcp.world


--
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
To contact the owner, email: opensuse-project+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups