On Samstag, 11. August 2018 14:25:16 CEST Valorie Zimmerman wrote:

> In addition there is the widespread opinion that amateurs are better
> than professionals for KDE, and that if there are professionals
> working on software, that the volunteers will leave. In fact, this
> idea seems widespread in the FOSS world. From what I have seen,
> professionals can *increase* volunteer contributions, by laying the
> groundwork for successful onboarding, by paying attention to details
> which volunteers left undone or did improperly, by doing work that no
> volunteers have the skills or interest in doing, in ensuring that
> documentation is up-to-date, by thinking of tasks such as training
> sessions for bug-triage, documentation writing, packaging, testing
> days and so forth.

Hi Valorie,
Thank you for bringing this topic up!

Interestingly, in almost all conversations I had at Akademy about this topi=
c,=20
people were actually very positive about the prospect of growing an ecosyst=
em=20
of companies around KDE. Maybe it's the difference between the people who a=
re=20
still active and want to see people spend paid time on KDE, and those who a=
re=20
mostly watching KDE from the sidelines and want to go back to "the good old=
=20
times=CC=A3"=E2=84=A2 when KDE was just a bunch of enthusiastic geeks who w=
anted to change=20
the world as a hobby.

=46or those people who claim that having paid people work on a Free Softwar=
e=20
project will inevitably kill all motivation for volunteers, let's look at s=
ome=20
examples within or close to KDE:

1. Plasma: If you look at the percentage of regular Plasma developers who a=
re=20
employed by Blue Systems, you could indeed think that nobody wants to work =
on=20
it as a volunteer anymore.
However, the reality is the other way around: It's not that volunteers stay=
=20
clear of Plasma because it has so many paid developers, it's rather that=20
whenever a very active Plasma contributor is looking for a job, chances are=
=20
high that they get that job from Blue Systems, to be able to spend more tim=
e=20
doing what they've been doing before as volunteers. Kai Uwe or Roman are th=
e=20
latest examples.
In fact, as far as I know, all of the Plasma developers who work for Blue=20
Systems have started working on Plasma as volunteers and then got hired by=
=20
Blue Systems.

2. Krita: Krita has become very popular as a volunteer project, until it gr=
ew=20
to a point where it became difficult to sustain it purely with volunteer wo=
rk.=20
The team started the Krita Foundation to raise money to pay for 1.5 (or 2.5=
,=20
different sources have told me different numbers) people to work on it.
It continues to grow, and I have not heard of volunteer contributions going=
=20
down since then.

3. ownCloud / Nextcloud: ownCloud was envisioned as a company-driven projec=
t=20
from early on, but always aimed to have a healthy base of volunteer=20
contributors. However, their "open core" model with a mandatory contributor=
=20
license agreement, together with a decision-making process that wasn't as o=
pen=20
as outside contributors had hoped, resulted in the community not shaping up=
 as=20
envisioned.
So what Frank did was fork out Nextcloud, without a CLA, fully open source =
and=20
with more focus on community, but still with a paid core team. As far as I=
=20
know, this has worked out exceptionally well and they now have both a=20
commercially successful company _and_ a big, happy volunteer community.

4. Kontact: The current business client for the Kolab server is still based=
 on=20
Kontact, yet most of its development is currently volunteer-driven.=20

5. KOffice / Calligra: Their story is very complex, so much so that I would=
n't=20
dare trying to retrace it from my limited insight into it. I'd rather leave=
=20
that to the team. I'm just listing it here so that people won't think I've=
=20
left it out on purpose.

What I gather from these examples is that having a company involved in the=
=20
development of a KDE- or KDE-related project does neither guarantee its=20
success nor its failure. Whether it's a positive or negative influence (or=
=20
both) very much depends on the way that the company engages with the=20
community.
If the company takes full control of development and only maybe accepts a=20
small patch here and there from outside volunteers, then of course voluntee=
r=20
contributors will lose their motivation pretty quickly.

If, however, the company makes sure that people employed by it still consid=
er=20
themselves as part of the community just like everybody else - which is wha=
t=20
Blue Systems does, for example - they can happily coexist with volunteer=20
contributors.

I - this is my personal opinion, not necessarily the board's stance - fully=
=20
agree with Valorie that a healthy ecosystem of companies and/or foundations=
=20
around KDE, with paid contributors collaborating with KDE's volunteers, wou=
ld=20
not just be a good thing, but actually necessary for us to be able to compe=
te=20
with other products (be they FOSS or proprietary) that are doing the same.

So what I'd like us to do, instead of cowering in fear of the dangers of th=
e=20
dreaded business world meddling with our volunteer-driven community, is=20
actively looking for ways we could promote the growth of a company and/or=20
foundation ecosystem around KDE!

Best,
Thomas