Early release or mature?

    What do mutt, mplayerand gzipbesides, it's high-quality open source projects? As a hint, I give a leading question: can you tell me exactly the month of the release of the next version of Debian Linux, before the official announcement on the website ?




    All these programs have one feature - a relatively long and unpredictable development and release cycle. Meanwhile, a predictable and relatively short release cycle , strictly on schedule , is becoming increasingly popular . Which development strategy is more advantageous and what are the conditions to achieve the transition to the optimal strategy? We will talk about this in this article.


    Releases more often, early


    This translates the famous thesis of Eric Raymond, author of The Cathedral and the Bazaar [1] . In this book, he compares the old Unix style of development with the cathedral, which is in stark contrast to how Linux is developed.


    I was shocked that this bazaar style works and works well. I not only participated in the development of individual projects, but also tried to understand why in the Linux world not only there is no disorder, but on the contrary it is moving forward at a speed that the cathedral builders can only envy .


    This philosophy perfectly characterizes the development of the Linux kernel itself, but many open source projects have not fully appreciated it and adhere to the ad-hoc release strategy . So we will call the project development strategy, in which a new version is rolled out when it is ready, when a certain set of features is embodied in the code and stabilized.


    This approach has significant drawbacks, often ad-hoc becomes long-term, as the first stable version of Mplayer-a .


     8414213 Oct 22  2006 MPlayer-1.0rc1.tar.bz2
          57 Oct 22  2006 MPlayer-1.0rc1.tar.bz2.md5
        3453 Oct 22  2006 MPlayer-1.0rc1.tar.bz2.torrent
     9338201 Oct  7  2007 MPlayer-1.0rc2.tar.bz2
          57 Oct  7  2007 MPlayer-1.0rc2.tar.bz2.md5
          65 Oct  7  2007 MPlayer-1.0rc2.tar.bz2.sha1
        3707 Oct 11  2007 MPlayer-1.0rc2.tar.bz2.torrent
     9650074 May 29  2010 MPlayer-1.0rc3.tar.bz2
         538 May 29  2010 MPlayer-1.0rc3.tar.bz2.asc
          57 May 29  2010 MPlayer-1.0rc3.tar.bz2.md5
          65 May 29  2010 MPlayer-1.0rc3.tar.bz2.sha1
    12134661 May 29  2010 MPlayer-1.0rc3.tar.gz
         538 May 29  2010 MPlayer-1.0rc3.tar.gz.asc
          56 May 29  2010 MPlayer-1.0rc3.tar.gz.md5
          64 May 29  2010 MPlayer-1.0rc3.tar.gz.sha1
    10351350 Jan 29  2011 MPlayer-1.0rc4.tar.bz2
         538 Jan 30  2011 MPlayer-1.0rc4.tar.bz2.asc
          57 Jan 29  2011 MPlayer-1.0rc4.tar.bz2.md5
          65 Jan 29  2011 MPlayer-1.0rc4.tar.bz2.sha1
    12979618 Jan 23  2011 MPlayer-1.0rc4.tar.gz
         538 Jan 30  2011 MPlayer-1.0rc4.tar.gz.asc
          56 Jan 29  2011 MPlayer-1.0rc4.tar.gz.md5
          64 Jan 29  2011 MPlayer-1.0rc4.tar.gz.sha1
    11202492 May  5  2013 MPlayer-1.1.1.tar.xz

    The popular layout platform Scribusrecently released version 1.4.6 , while 1.4.0. came out at the very beginning of 2012. When 1.5.0 comes out it is generally unknown. The mailer muttis the main working tool of the maintainer of the stable Linux branch of the GKH kernel. He stayed in version 1.5.X how many others get for the most difficult ones. And he even gzipstretched out 13 years, from 1993 to 2006, between versions 1.2.X and 1.3.X.




    At the same time, larger projects have long moved to the timeline, and as a rule, the interval between releases does not exceed six months. Here is a list of some major projects, time intervals and time for choosing a new project development strategy.




    Debian stands alone and is some hybrid combination of two strategies. As you can see, the Debian team still adheres to the schedule, but the development cycle is too long to take advantage of a strategy with a predictable production cycle. Quite often , the release date for a new version is delayed .


    Curious fact, in KDE Plasma 5 patches after the .0 versions are released on Thursdays , in the weeks of the Fibonacci sequence .


    Plasma .0 tags on Frameworks release Thursdays and release on following Tuesday. Beta tag / release on Thursday 2 weeks before. Bugfix tag / releases are on Tuesdays after .0 release in a Fibonacci sequence of weeks, 1, 1, 2, 3, 5 after initial.


    Let us now consider the reasons for the long-term construction of adherents of the ad-hoc strategy, the advantages of a predictable short production cycle and the possibility of changing the first to the second.


    Discipline matters


    When a team is waiting for a certain set of features to be included in the code and stabilize in order to release a new version, the following most often happens. At some point, they realize that adding all the desired innovations will not work, since many project enthusiasts have been working recently and have not encountered new concepts before. Then by force of will announce the estimated release date, which for everyone becomes a shock . This is followed by a flurry of patches and vanity, because many releases have not seen how many years and do not know how to do it.


    Whether it’s GitLab, the developers roll out a new version every month on the 22nd - like a Swiss watch. According to the founder and project manager Dmitry Zaporozhets, you do not have to wait until everything is perfect.

    At GitLab we believe you shouldn't wait for something to be perfect: Release what you have and do it on a schedule
    A predictable schedule and short release interval has the following advantages.


    • Maintainers no longer violently customize ordinary developers. The work is carried out in a business, but not an emergency mode. It’s like rushing headlong to take a departing train in the subway, you can after all wait for the next one.
    • Within a year, even new team members manage to get their hands on it, the release of the new version ceases to be a source of stress and surprises for them. In the case of GitLab, this period is many times shorter.
    • When the new version is delayed, the probability of fragmentation of the source code increases, some developers begin to fork the code, add their own ideas and focus on them in the future. A clear schedule and a short release interval for the next version removes such confusion and vacillations in the team.
    • The project continues to evolve . When a long-term project happens in an open source project, users, volunteers, and then developers, leave it. It is in this order, since with the departure of users from the project, its base is eroded. After all, how is the pyramid arranged? Always , a certain percentage of users not only use the program, but also help to develop it: some with bug reports, some with translations, some with beta tests, and some with patches. Without users, the project rots.
    • When the new version is still far away, it becomes more and more difficult to recruit beta testers, for them it is interesting, only in anticipation of the release of a stable version. With earlier releases, feedback between users and developers does not fade.
    • Upgrades are not so furious.
    • For users, as well as for distributors of open source software, it is easier to plan the transition to a new version of the program.

    Particularly favorable is the transition from ad-hoc strategy to the chart influenced GNOME. Here we should add a photo-toad, that is, Gimp-processing, paintings by Vasya Lozhkin “Life with a beard”, but unfortunately I can’t write the necessary words beautifully with an arch.


    An incredibly large-scale and complex set of open source projects OpenStackhas a six-month release cycle, however, initially new versions were released every three months.


    Release date            Release name
    Oct 21st, 2010          Austin
    Feb 3rd,  2011          Bexar
    Apr 15th, 2011          Cactus
    Sep 22nd, 2011          Diablo
    Apr 5th,  2012          Essex
    Sep 27th, 2012          Folsom
    Apr 4th,  2013          Grizzly
    Oct 17th, 2013          Havana
    Apr 17th, 2014          Icehouse

    Let's take a quick look at what the OpenStacknumbers mean .


    • Market size - $ 1.7 billion in 2016.
    • The project involves more than 500 companies.
    • Support for multiple platforms and architectures.
    • 17,020 community members
    • 100,000 code checks
    • 1,766,546 lines of code

    The highlight of this colossal undertaking is that the main participants compete with each other in the market , while collaborating on the project. HPE competes with Mirantis and Rackspace, IBM with Intel, VMWare with Cisco, RedHat with Canonical, but when it comes to OpenStack, everyone gets white and fluffy.




    Imagine for a moment how this project could develop, relying on a long development and release cycle. What if the release of the next version occurred as soon as a set of new features was ready, instead of sticking to predictable and clear timelines ? I think that in this case, the participants simply could not agree on anything, and the project would have stalled at an early stage.


    Qui bono?


    Does all of the above mean that for all projects, without exception, the transition from a ad-hocrelease strategy to a predictable schedule is a boon?


    The first thing that comes to mind is counter-examples. There are vimeither GNU Coreutils, which are rarely or not very predictably released, but which nonetheless are doing well with development and with a user base. The thing is that for successful open source projects there is no good reason to change the development strategy in order to pay tribute to new trends. This wisdom is known to all admins: works - do not touch .


    Similarly, there is no reason to switch from ad-hoc releases to predictable ones if there were just nothing commits. A critical mass of change must accumulate.


    Нет никакой линейной зависимости между упомянутыми двумя стратегиями и качеством кода, что было показано на примере FireFox. Согласно проведенному исследованию, до и после перехода на предсказуемый короткий цикл производства количество багов после выхода стабильной версии было практически одинаково.




    Важно четко понимать в каком пользовательском сегменте находится ваш продукт. Одно дело компилятор gcc, если выкатить его пораньше и сыроватым, программисты смогут напильниками довести его до ума. Совсем другое дело, веб сервер Apache, выпустить раньше времени стабильную версию — чревато.


    Резюмируя все вышесказанное. График предпочтительнее чем ad-hoc в тех случаях когда:


    • You are starting a large open source project with many developers and volunteers.
    • Your project has commercial value for software vendors or actively competes in the market with other programs,
    • your project runs out of steam, users and developers scatter due to a too long and unpredictable development and release cycle.
    • Your project is critical for partners like GNOME for Ubuntu, so upgrades must be consistent and time synchronized.

    Used materials


    1. Why and How Should Open Source Projects Adopt Time-Based Releases?
    2. Time-Based Release Management in Free and Open Source (FOSS) Projects
    3. Lessons learned from applying social network analysis on an industrial Free / Libre / Open Source Software ecosystem
    4. OpenStack Wiki Page



    Book in Russian translation . In the original, this phrase sounds: release often, release early .

    Also popular now: