Consider Slowing Down the Release Schedule!

[Emmet O'Neill]

Hey all,

I've been busy finishing up a personal project with Eoin recently, but this
is something that I've been thinking about for a while and I'd like to
throw it out there.
I'm writing to the mailing list because I'm almost never awake for the
weekly meetings (4-5AM on a monday isn't great for me. heh) and this is a
better format than a series of IRC messages.

Anyway, two of Krita's goals for 2019 were to (a) drastically reduce the
number of bugs and (b) to release every month.
While you all did tons of great work on 'a' and we very nearly fulfilled
'b', I want to advocate for a different strategy in 2020:
slowing the release cycle down to 1, 2, or (at most) 4 releases per year.
Here's why...

*1.)* Less time between releases means less testing, and less testing
likely leads to more bugs.

*2.)* Most people don't care for bleeding edge updates, they want a stable
tool that works consistently.

I don't think the average Krita user is looking for a new version each
month,
and I'd imagine that most users are not following the release schedule
closely or running the latest version.
There are very few large projects, FOSS or otherwise, that release monthly,
and for good reason.

In general, I think what users want is a tool that empowers them to create
their artwork, while being solid, reliable, and consistent.
On the other hand, those that do want to be on the bleeding edge have a
number of ways to do that, including nightlies and building from source.

*3.)* A monthly cycle increases work without increasing reward.

There is an 'overhead' of time and effort associated with each release,
from the community beta tests,
to build and packaging process itself, to the patch notes, to the various
platform submissions, to the various website and social posts, etc.
At best (assuming everything goes right and nothing has to be redone) the
work associated with this task is linear--more releases does not result in
less work per release.

On top of that, a monthly cycle adds complexity to support, as 10 users who
all downloaded Krita in 2019 might each have a different version.
Even under the (big) assumption that a user has a version from within the
last year, it's still difficult to know which version (and which bugs) they
might have.

This amounts to a time/effort/support burden of our own design, when those
resources could be used on something else,
and there's really no evidence that it benefits either the project or its
users in the long term.

*4.)* The community won't stay excited about small, incremental updates
forever.

In my opinion, just like time and money, community interest is a *resource*--it
can earned, it can be saved, and it can be spent.
Getting the community to do things that benefit the project, be it
donations, contributions, testing, or peer support are necessary *sinks* on
that resource.
This resource in particular is critical to the project's growth and
survival, and it's the community, above all else, that we ought to nurture.
It's absolutely worth considering, then, how we make sure that we're
working with the community is a sustainable way.

Do we want community members to help with the burdens of support and
testing? Yes, of course.
Is offloading the majority of support to the community realistic? Maybe, in
the long term.
But, is getting a small pool of enthusiastic volunteer users to adequately
test and fill out surveys every month sustainable? In my view, no.

After a few months, the novelty and the "sure I'll help out" attitude will
run dry, especially if users are asked to test versions where changes are
mostly incremental and opaque.
New versions will go under-tested, bugs will be missed, the user experience
will suffer and more time will be spent chasing bugs.
Give the community work, and they'll eventually lose interest. On the other
hand, give the community reasons to be excited and they'll be happy to put
in some work.

Fewer, bigger, and more meaningful updates will give members of the
community more reason to be excited, and I think it'll result in more
people willing to do support and testing.

---

At any rate, I don't want to diminish or undercut any of the work or
successes that Krita had in 2019, as it was a great year for Krita by most
metrics.
But I also believe that a strong vision for 2020 and the future is
necessary to make sure that the project continues to grow and that the best
is yet to come.
Slowing down the release cycle would help ease some of the current burdens
on the project, and in my opinion,
would also give us time to focus on making meaningful improvements and
delivering cool new features instead of being caught in a constantly
fluctuating tide of bug reports each month.

Give it some thought and let me know what you all think. =]
- Emmet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20200119/b459d196/attachment.html>