Mailinglist Archive: opensuse (1451 mails)

< Previous Next >
Re: [opensuse] 13.2 vs Leap vs Tumbleweed
On 7 February 2016 at 12:38, Oliver Kurz <okurz@xxxxxxx> wrote:

"Staying a few versions behind" can work because others with a close enough
environment of yours have hopefully already tried out the new version,
reported bugs and fixes have been provided. The probability for this will
increase the longer you wait with the downside of missing new features.
Eventually also bugs are not fixed anymore for the old version you were
intended to jump on.

This statement has triggered an interested train of thought I wish to
share with everyone for their opinions

First I want to start by making a few assumptions

I believe everyone wants to/should want to run supported software.
This means not only that 'it works', but that it is cared for and
maintained. By maintenance in this context I mean 'security &
functionality issues are found & fixed', and possibly also 'new
features and hardware enablement are provided.

I realise this isn't true of everyone in every circumstance - but if
you're an exception to the above assumption, then it doesn't matter in
the context of this discussion as you can pick whatever openSUSE
release that suits your use cases.

I also wish to make the assumption, more of an assertion really, that
open source developers are primarily interested in developing 'new
stuff'. The open source model's openness to innovation is what drives
contributions to open source software. I believe this to be equally
true regardless of the other motivations behind a particular persons
contributions. Volunteer, employed, whatever, at their heart I believe
the vast majority of open source developers are interested in
developing 'new stuff' - whatever that 'new stuff' may be.

Maintenance of 'old stuff' is time consuming, complex and often
thankless work that often requires more thought and effort than
developing new stuff. Some developers may embrace this task to a
greater or lesser degree, but regardless I think few would argue with
the statement that they would rather be doing 'new stuff'.

It is also worth mentioning that 'maintenance' of old stuff often also
means resolving integration issues with other parts of the stack that
are still moving. This can often be even worse in terms of time,
effort and complexity, and sometimes can just be fundamentally

This leads to a situation where many volunteer led open source
projects often make dramatic strides forward while simultaneously
reducing/removing the maintenance of previous versions.

Plasma 5 is a perfect case study of this approach, with the KDE
project abandoning maintenance of KDE 4 relatively quickly. That meant
no security and bug fixes from the wider KDE Community.
This led to a situation where our openSUSE KDE team felt they had no
choice but to adopt Plasma 5 when they did as the alternative
(continuing support for KDE 4) would have been way too much work for
them to do on their own, especially when considering there are other
parts of the operating system that are still moving forward and for
good reason (eg. Kernel, udev, systemd for the enablement of new
hardware and other pieces of software)

I think it's also safe to say that in a good number of Projects, not
just desktop orientated ones, there is a trend towards 'fixing things
in new versions' and not expending too much effort ensuring that
previous versions receive those same fixes.

This is a story repeated throughout the open source world, but I
believe it to be mostly a fact of life which people either have to
accept, or pick up a text editor and get to work fixing it themselves,
because the motivation of the current breed of open source software
developers is unlikely to change

Therefore, considering these factors, I actually think anyone who
believes in the 'sticking to previous versions' approach is misguided.
If it works for them, great, but the bulk of the collective open
source worlds interest, attention, and new lines of code, are all
being written for the 'current and next' versions of their software.
That's where their interest lies, and focusing our collective efforts
and attention on using and improving the quality of what is done there
is the only way true progress is made.

That said, there is a counter-weight to this situation

Enterprise Linux distributions have enterprise customers who are
prepared to pay for the stability/reliability they require, which
enables companies like SUSE to pay salaries to dedicated maintainers
to do that maintenance work that they otherwise would be unlikely to
be self-motivated to do

But Enterprise distros are a very different beast as a result of this

For example, Leap/Tumbleweed have approx 8000 packages in their official repos
SLES has about 2500 - All that maintenance really costs a lot of time,
effort, and money, so a very broad package selection is not possible.

Leap/Tumbleweed has many different desktop environments, because we
have a community that is able and willing to work on integrating them
all together

SLES, and every other Enterprise distribution, all only use GNOME.

Because of their very 'rearward facing' approach, the problems they do
find, the issues they do fix, are rarely relevant to the upstream
projects they are using, as those projects are often months, if not
years ahead. It helps their users, and that's the point, their users
are willing to pay for it.

And so, considering all of this, what does this mean for openSUSE?

Well we have Tumbleweed, which fully embraces the idea that you can
make a reliable linux distribution even when doing 5 releases a week
containing several hundred packags including new kernels. Everything
done there is easy to feedback to every other upstream open source
project, so not only does it help openSUSE but everyone else.

Wishing for the open source world to be slower is unlikely to provide
any noticeable result, so there is something to be said about just
rolling up ones sleeves, hopping on the boat, and trying to help steer
it as part of a crew, rather than trying to go it alone which is a
heck of a lot more work.

And we have Leap, which takes that very stable, professionally and
extensively maintained enterprise codebase and then expands upon it
with those community packages.
From the openSUSE developers perspective it's easier to maintain -
that's 2500 packages less for them to worry about, so they can focus
more on maintaining the remainder. But it is still volunteer work, and
that work is still heavily impacted upon by decisions by various
upstreams. It's not easy, it's not fun, and it's often not that
rewarding either. And always, we could do with more help

So, maybe if Leap or Tumbleweed isn't hitting your sweet spot, the
answer is to start learning how to help maintain those parts of the
software stack that matter to you?
Join those mailinglists and IRC channels, ask the current maintainers
questions. Offer to help. File bug reports. Learn how to file better
bug reports. Come to the openSUSE Conference in June and talk to
everyone involved.
If packages are missing from our distributions, we have published
guides on how to get them into our distributions, help them get in. If
you can't do it yourself, then find someone to do it *with* you, so
you can learn to do it in the future.

Adding unsupported repos, or staying with previous versions after they
are no longer supported and hoping for things to change isn't going to
help things change, and I worry that the people doing that will just
find themselves dissapointed in a long run.
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups