<div dir="ltr"><div>Hey all, <br></div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Anyway, two of Krita's goals for 2019 were to (a) drastically reduce the number of bugs and (b) to release every month.</div><div>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: <br></div><div>slowing the release cycle down to 1, 2, or (at most) 4 releases per year. Here's why...</div><div><br></div><div><b>1.)</b> Less time between releases means less testing, and less testing likely leads to more bugs.</div><div><br></div><div><b>2.)</b> Most people don't care for bleeding edge updates, they want a stable tool that works consistently.</div><div><br></div><div>I don't think the average Krita user is looking for a new version each month, <br></div><div>and I'd imagine that most users are not following the release schedule closely or running the latest version.</div><div>There are very few large projects, FOSS or otherwise, that release monthly, and for good reason.</div><div><br></div><div>In general, I think what users want is a tool that empowers them to create their artwork, while being solid, reliable, and consistent.</div><div>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.<br></div><div><br></div><div><b>3.)</b> A monthly cycle increases work without increasing reward.</div><div><br></div><div>There is an 'overhead' of time and effort associated with each release, from the community beta tests, <br></div><div>to build and packaging process itself, to the patch notes, to the various platform submissions, to the various website and social posts, etc.</div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div><br></div><div>This amounts to a time/effort/support burden of our own design, when those resources could be used on something else, <br></div><div>and there's really no evidence that it benefits either the project or its users in the long term.<br></div><div><br></div><div><b>4.)</b> The community won't stay excited about small, incremental updates forever.</div><div><br></div><div>In my opinion, just like time and money, community interest is a <i>resource</i>--it can earned, it can be saved, and it can be spent.</div><div>Getting the community to do things that benefit the project, be it donations, contributions, testing, or peer support are necessary *sinks* on that resource. <br></div><div>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.</div><div>It's absolutely worth considering, then, how we make sure that we're working with the community is a sustainable way.</div><div><br></div><div>Do we want community members to help with the burdens of support and testing? Yes, of course.</div><div>Is offloading the majority of support to the community realistic? Maybe, in the long term.<br></div><div>But, is getting a small pool of enthusiastic volunteer users to adequately test and fill out surveys every month sustainable? In my view, no.</div><div><br></div><div>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.</div><div>New versions will go under-tested, bugs will be missed, the user experience will suffer and more time will be spent chasing bugs.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>---</div><div><br></div><div>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.</div><div>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.</div><div>Slowing down the release cycle would help ease some of the current burdens on the project, and in my opinion, <br></div><div>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.</div><div><br></div><div>Give it some thought and let me know what you all think. =]<br></div><div>- Emmet<br></div></div>