[prev in list] [next in list] [prev in thread] [next in thread] 

List:       calligra-devel
Subject:    Re: next release and release pace in general
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2013-02-12 8:22:07
Message-ID: 201302120922.07952.boud () valdyas ! org
[Download RAW message or body]

On Sunday 10 February 2013 Feb, Cyrille Berger Skott wrote:
> Hi,
> 
> Here is my opinion on release schedule. First, we have to go back and think 
> about why we do release ? And more important, to whom we do release ? For me, 
> it is obvious that we primarly release to bring improvements to our users, 
> everything else is and should be a side effect.
> 
> == Targeting users
> 
> Then we have to know our users, and the following is based uniquely on my 
> experience with talking with other people, technical, and non-technical, young 
> or older, if someone had a study on the subject, I would be very interested to 
> read it, but anyway, I would say there are two categories of users, those who 
> don't want any changes at all in the software they use and those who like to 
> see improvements. Personnaly, I think that when we release, we can safely 
> ignore the first group of users, there is no law that say that a user have to 
> upgrade, hence that group of users is well served by a fast or a slow release 
> cycle.
> 
> For the second group of users, it seems to me, that they appreciate 
> improvements, weather features or bug fixing, and would strongly dislike 
> disruptive changes (major UI overhaul and regressions). But to be honest, that 
> would be true for any release schedule length. To be honest, based on that, I 
> would even be suggesting monthly release, continuously bringing features and 
> bug fixing, but that would be a QA nightmare.

If we want to provide users with improvements, we need to have users in the first \
place. That's simply not the case, and in order to get more users, we have to be able \
to tell them what is available. The only moment we can do that is in with a release, \
because only releases get picked up by press and news sites.


> 
> == The competition
> 
> This assumptions about users appreciating continuous non-disruptive 
> improvements, that have led Google to release Chrome every six weeks, Firefox 
> is also now following that schedule. The Linux Kernel get a major release 
> every four weeks. If you look at web site and web applications, they get 
> continuous improvements that are silently rolled to users. This is the current 
> trend in the industry, release early and release often.

But those projects are not the competition. The competition is LibreOffice (just had \
their 4.0 release with lots of coverage and a very nice special website landing page \
for 4.0), MS Office, GIMP, MyPaint, Photoshop and so on. None of these projects are \
on continuous releases, and they all use their releases to generate publicity.

> 
> == Splash
> 
> I don't think release should be used for making a "splash", I fail to see the 
> benefit for our users, also, we would have to define what is a "splash", same 
> with defining important features: what is an important feature for someone is 
> completely unimportant for someone else, also, developers tend to vastly 
> overestimate the time it will take to complete a feature, which is the problem 
> with goal-oriented features, they keep dragging on, waiting for some features 
> to be finished.
> 
> So yes, our releases announcement looks like they don't contain so much. My 
> suggestion would be that once a year we write (rather collect) a small leaflet 
> with all the new features and improvements that have happen during the last 
> year, pretty much like Krita's leaflet (http://krita.org/aboutkrita26.pdf). 
> And then we send that to the press, along with a presskit, and I am rather 
> convinced that it will be much more efficient at attracting attention than 
> waiting for having sufficient features to do a release.


This is the point where I disagree most with you: if want to get more users and more \
developers we have to get publicity. And basically, apart from bad stuff happening \
like forks, releases are the only hook news sites and press acknowledge for writing \
about an application.

I think making a splash is actually the most important thing of a release. Just look \
at the amount of interest the 2.6 release has just generated for Krita.


> 
> == Reaching users
> 
> Fedora and Ubuntu are on a six months schedule with freeze early March and 
> early September. OpenSuse is on a 8 months schedule. However, rolling 
> distributions are getting increasingly popular, with Gentoo and ArchLinux, 
> Debian has started discussing it, Ubuntu is rumured to introduce it soon. Also 
> most distributions offers backport of the latest software.
> 
> And that is only Linux, but the hard truth is that if Calligra become 
> successful, most of its users will be Windows user, where we are not dependent 
> on distributions release schedule.
> 

That is not reaching users: it's making software available. It's perfectly possible \
to make our software available regularly and still reach basically no-one.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel


[prev in list] [next in list] [prev in thread] [next in thread]