How to handle KDE not respecting YOUR distros requirements?

[Richard Brown]

Hi Thomas,

Good questions, few of them are easy to answer with hard facts, but I
will do my best to answer them with my opinions supported by what
facts I have to justify them.

I apologise in advance for how brutal some of these statements may
be..I mean everything I say in the best interests of helping KDE.

On 27 March 2016 at 19:49, Thomas Pfeiffer <thomas.pfeiffer at kde.org> wrote:
> On Sonntag, 27. März 2016 15:34:07 CEST Richard Brown wrote:
>
>> Why all the doom and gloom? Because I think it's important we be
>> realistic about where we are before we can improve things
>>
>> Doing the same as 'the other guys' is not a viable option when they
>> have the dominant position.
>
> Hi Richard,
> for me (and I suppose I'm not the only one), the important question is: How
> did GNOME and other DEs it shares technology with get to that dominant
> position?

To answer this broad question, I think the answer is "GNOME aimed
small, so missed small".
It clearly defined itself a target and built their stack to meet that
goal, while simultaneously establishing good, healthy, communication
routes and relationships with an entire ecosystem of other
distributions and projects.
They made it clear what they were going to do in advance, and
communicated how and when they will get there. They never delivered
anything less than they promised.
And even though they never made themselves formally 'modular' in the
way that KDE attempted, their clear goals coupled with clear
communication made it easy for other projects to hook into what they
were doing and adapt and extend it as they saw fit.

> Or more specific questions:
> - What makes GNOME appear to be the more viable alternative for enterprise-
> oriented distributions?

To be frank, trust

Even the great big change to GNOME 3 didn't come as a surprise, with
clear plans laid out well in advance. GNOME work very hard to
pro-actively communicate with Enterprise distributions about what they
are doing, while simultaneously listening to their concerns and
working to address them.
It's quality was not perfect at release, but was acceptable. The
initial GNOME 3 versions at least achieved what they set-out to
achieve.
All changes since then have been incremental, clear, measured, with
each release being of a high quality which has been increasing from
release to release, with GNOME taking a greater responsibility for
ensuring what they do is of a high quality.

This makes it very easy for Enterprise distributions to consume,
indeed it seems to be encouraging Enterprise distributions to adapt
and adopt new stuff from upstream GNOME faster, because it can be
trusted without little fuss.

We're probably a while away from a GNOME 4, but casual discussions are
already bouncing around, and the current leanings seem to be towards
avoiding a 'big technical epoch' change like GNOME 2>3 had..this
further raises Enterprise distributions trust in GNOME

Meanwhile, KDE 4 seemed to come pretty much out of the blue. It didn't
seem to have a clear agenda or purpose besides 'it's a new KDE'
It's quality was not very good at launch and took a while to get better

As KDE 4 progressed I would describe the messaging at the time as very
scattered. Plasma Netbook? Active? Mobile? Where was the KDE Project
going? That kind of uncertainty of purpose totally alienates an
Enterprise distribution from wanting to base it's multi-million dollar
businesses on your desktop.

Quality improved, but communication did not. Plasma 5 seemed like
another sudden change and a reset to zero without learning many of the
lessons of KDE 4 (besides the quality at 5.0's launch wasn't as bad at
4.0's)

The goal, the mission, the purpose of the KDE stack remains pretty
much an unspoken mystery, and the modularisation makes it harder to
interpret what that purpose might be
Meanwhile each Plasma, Frameworks, and Qt release at the moment seems
to be huge leaps desperately trying to achieve some kind of return to
the reliability and functionality that KDE had before 4.x died a
death.

Each of these big leaps requires a lot of work to keep your Qt based
stuff working nicely with it (we're seeing that on a much smaller
scale with our Qt based applications in openSUSE)

That is not a foundation upon which I think any Enterprise can put
their faith into. Especially when you consider they are often thinking
with a mindset of "can we support this for *years*?".
There just isn't enough clear communication or quality technical
execution in either the short-term or the long-term from KDE at the
moment for that level of trust to exist.

> - What makes GTK and GNOME appear like the more viable base to build on for
> the majority of new desktop environments (not to all of them, though, see
> Unity 8 or LXQt as quite visible counter-examples)?

It's a common misconception that the transition to GNOME 3 (and it's
obviously mixed reception by users) was reflected in terms of lower
contributors and contributions to gtk/gtk3

This couldn't be further from the truth - I remember seeing slides at
FOSDEM that showed the graph accelerating since the release of GNOME
3, and the use of gtk3 by a growing number of DE's seems to reflect
that.

I think Developers are drawn to projects with clear goals, clear
missions, and quality outcomes from those projects. Even when they
disagree with some of those outcomes, it validates the technology
chosen as a suitable base, which is where adaptation and alteration
come into play.

I think KDE's size plays against it here too. It's a big stack, a huge
stack, with many many complicated pieces presented in a complicated
way.

There is also a bit of a 'popularity avalanche' at play also. GNOME 3
and Cinnamon came out of the gate with gtk3 support, and are
successful in their own right. That set a good foundation for other
DE's like Pantheon and Budgie to build from. Heck, even the most die
hard gtk2 fans in MATE are now moving everything to gtk3

Meanwhile for KDE there is only Plasma and the very fresh Unity 8
which is still heavily dependant on gtk3 applications. lxqt has a lot
of promise, but seems to be struggling with adoption and taking a long
time to get there. I don't know why that is, I'd suspect all the heavy
engineering that Qt seems to be going under isn't exactly helping lxqt
getting their stuff put together

> - Are desktops and applications based on GTK and GNOME libraries easier to
> deploy than those based on Qt and KDE Frameworks? If so: Why?

I think that is the perception, yes

I think it's a combination of the Enterprise factors I listed above -
more gradual change, less dramatic changes, clearer communication
about changes so less surprises and less things to be fearful over

I also think it benefits from the network effect - more people are
doing it (GNOME, Cinnamon, MATE, Pantheon, Budgie, etc) so any pain
points that do exist are easily discussed away and there is a greater
library of solutions from other Projects already out there.

>> They already have the buy-in from a wider ecosystem of distributions
>> who put them first. They can afford to make questionable choices. It
>> seems no matter how questionable their choices may have already been
>> it is not negatively impacting their adoption rates compared to KDE.
>
> Those choices have initially impacted their adoption rates quite negatively,
> resulting in a slew of forks (Unity and Cinnamon arguably being the most
> successful ones), but they have recovered from that impact by constantly
> providing great releases. One of the things that make these great releases
> easier to achieve for them is, ironically, the very fact that they don't care
> about anything or anyone outside of GNOME all that much. This doesn't make
> other DE communities very happy, but it does help them streamline their own
> work.

It's a controversial opinion, but I prescribe to the belief that a
Project can survive, in fact prosper, by focusing on the needs and
growth of it's contributor base. Build something beautiful, that your
contributors want to build, build it well, and communicate that
clearly, and while you may alienate and upset some users in the short
term, in the long term you will end up with more than you lost, and
with a stronger developer base to deal with what they need in the
future.

GNOME is an example of this philosophy that worked, and indeed
practically every single on of those 'slew of forks' has ended up also
contributing to the wider, broader GNOME ecosystem.
They have adoption in a plurality of distributions, meanwhile other
people may have plenty of different visions for a gtk-based DE than
GNOME shell, but they all seem to be quite productive building that
upon gtk and often using GNOME applications also, leading to a pretty
healthy family.

I do not have any accurate figures on the current KDE developer base
but I do remember monitoring commit-digest throughout 2013 and 2014
and being concerned about the decreasing trend of activity. I think
it's important KDE find a way to turn that around.


>> KDE has to be better, smarter, leaner to compete. It needs to be
>> easier for packagers to work with than the alternatives. Easier to put
>> together. Easier to maintain. Easier to track changes.
>
> While being easy to deploy is of course a very important factor for the
> success of any software, I do not think that this is what we want to be our
> USP. I don't think "Plasma, the desktop environment which is the easiest to
> deploy" would be the tagline for a breakthrough, especially given that
> desktops which primarily aim to be "lightweight" and are happy to sacrifice
> functionality for that would always beat us in that arena.

Maybe, but right now my perspective is Plasma is overly complicated to
track changes, understand changes, adopt changes, and deploy..
And all of this is across a much bigger and broader stack than the competition
End of the day, your distribution packagers will be asking themselves
the question "Why am I doing all this work?" and the answer needs to
be a lot more compelling that the current, which I would often
categorise as "well this is what we've always done for KDE"

>> I personally think the whole Plasma/Applications/Frameworks/QT split
>> has dramatically increased the workload of distribution packagers here
>> for little or no benefit to users (I recognise it's easier to develop)
>
> What are the specific factors that increase the workload of packagers? What can
> we do to reduce that workload? It would be great if you could put your answers
> to that in a reply on the "What would distributions like KDE to do?" thread so
> that we have all of that information in one place.

Will do my best to encourage one of openSUSE's actual KDE packagers to
reply there with absolutely concrete examples, rather than fill up
that thread with my perspective which often comes from a more 'high
level overview' of how KDE fits in with everything else openSUSE is
doing.

>> But maybe going on a diet isn't an option - If KDE wants to remain as
>> technically large as it is and continue to provide such a broad
>> offering, then at least it has to do a much better job of selling
>> itself to distributions
>
> ...or selling itself to users, who would then look for distributions shipping
> it by default. It's both mostly two sides of one coin, though.

There is no point selling KDE to users if there is not sufficient
support in sufficient distributions to provide polished, healthy, well
maintained KDE experiences.
Focusing KDE's upstream marketing efforts towards the users first just
adds pressure to your distributions, who aren't exactly pressure free
when it comes to living with KDE these days :)

>> And I understand why - I've been saying for years that Qt is a
>> superior platform for desktop and desktop application development from
>> gtk. But that being true hasn't changed how many distributions put
>> their faith into which desktop stack first.
>
> Canonical seems to be convinced, but that is probably mostly because mobile is
> a strong additional focus for them.
> It should be for other distributions, too, however, if they want to stay
> relevant in the future.

and yet, they have taken Qt and seem to be building everything by
themself on it..and not adopting anything else from the huge, broad,
KDE family of everything

Maybe that can be read as a warning sign about KDE's own relevance in
the future?

>> Advertising through software capability only speaks to a very narrow
>> market, and problems with software quality erode that market
>> dreadfully quickly. I think it's safe to say KDE has had severe
>> problems with software quality lately, and I do not think that putting
>> all of the responsibility of testing onto distributions is a sensible
>> strategy to turn that around.
>
> We do not intend to put all of the testing responsibility on distributions,
> but we need distributions to get our software into users' hands for testing
> (one of the reasons why our software doesn't get enough testing before release
> is that currently our users have to build it themselves before they can test
> it), Neon is one effort towards improving that, and we are very happy that
> openSUSE Argon and Krypton will expand the base of users (including
> contributors) that can test our software before its release further.

Changing hats by a second and speaking as a QA engineer employed by
SUSE and not as an openSUSE guy

Testing by users is great

Testing by users should *never* by your first line of testing

Look at doing something like GNOME Continuous https://build.gnome.org/#/

Look at adopting openQA http://os-autoinst.github.io/openQA/
https://www.youtube.com/watch?v=a8LmqhwpVvg

Build some robot to test your stuff actually works before letting any
distribution put it in the hands of any users

It's 2016, we shouldn't be using human guinea-pigs.

Neon, Argon and Krypton should be phase 2 after you have tested your
built stuff in some clean, unsullied tidy environment
or maybe even phase 3, as you should be testing stuff before anyone
submits anything to a code tree.. There's infinite examples of
'traditional' software projects who practice CI like that..and if
that's not good enough, well we manage to do it for a distribution and
it wouldn't be too hard to adopt the same method for something more
narrow such as a specific desktop environment.


>> Is there more KDE can do to make sure it's offerings are well tested
>> before distributions have to find a way of making all the parts work
>> together?
>
> Honestly, we don't really know. We'd be very happy for further ideas on how we
> can get more people to test our software. If we test it only ourselves, we
> test only the things _we_ do with it, and most of our bugs happen either in
> areas that we ourselves just don't use enough to notice them, or under
> circumstances that are different from those under which our developers
> operate.
>
> The three noble gas -named distributions we have now are a great help to
> facilitate testing software before it's released, but we of course also need
> people to actually use those for structured testing.
>
> I don't know if other DEs have the resources for paid QA, but we certainly
> don't, so we have to rely on volunteers (which are not the developers
> themselves, see above) for that.

Volunteers are expensive too, in terms of time, motivation,
enthusiasm, beer, and more ;)

I'd recommend going for something automated, GNOME Continuous, openQA,
and traditional CI tooling like Jenkins and Travis should be on your
radar first and foremost..

Then your Volunteers can spend their time focusing on the high value
risk areas, which should provide more beneficial feedback to your
developers.

Cover your ass automatically, and then the humans can spend their time
making the product better than that baseline.

>> KDE needs to make it very easy for distributions to sell the premise,
>> promise, and benefits of using KDE to their users.
>
> Again: How can we help with that besides better promo in general?

Don't just do general promo on your own. Get together with those
distributions shipping your stuff. Work with them to provide them with
targetted, reusable, resources that they can use to their users. Make
their lives easier, give them less stuff to do, and they will love you
for it.

>> That's my 2c anyway..
>
> Thank you for your input! Now I'm looking forward for input on the "What would
> distributions like KDE to do?" thread, so we can work on improving the
> situation!

See you there ;)