Early release or sustained?

What is common between mutt , mplayer and gzip besides the fact that these are high-quality open source projects? As a hint, I give a leading question: can you accurately name 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. What 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

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

I was shocked that this market 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 confusion does not arise, but on the contrary, it moves 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 development strategy of the project, in which a new version is rolled out when ready, when a certain set of features is embodied in the code and stabilized.

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

  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 for Scribus recently released version 1.4.6 , while 1.4.0. It was released at the very beginning of 2012. When will 1.5.0 be released is generally unknown. The mutt is the main working tool of the maintainer of the stable Linux branch of the GKH kernel, stayed in version 1.5.X how many others get for the most serious. And even gzip extended 13 years, from 1993 to 2006, between versions 1.2.X and 1.3.X.

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

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

A curious fact is that in KDE Plasma 5 patches after versions .0 come out on Thursdays , in weeks of the Fibonacci sequence .

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

Now consider the reasons for the protracted ad-hoc adherents strategy, the advantages of a predictable short production cycle and the ability to change the first to the second.

Discipline matters

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

Whether it is GitLab, the developers are rolling out a new version every month on the 22nd of the day - like a Swiss watch. According to the founder and project manager, Dmitry Zaporozhets, one should not wait until everything is perfect.

It is not a problem.

The predictable schedule and short-term interval between releases has the following advantages.

• Maintainers are no longer violently pushing ordinary developers. Work is conducted in a business, but not emergency mode. It's like rushing headlong to get on the departing train in the subway, you can wait for the next one.
• During the year, even new team members have time to fill their hands, 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 several times shorter.
• When a new version is delayed, the likelihood of source code fragmentation increases, some developers begin to fork the code, add their own work and focus further on them. A clear schedule and a short release interval of the next version removes a similar confusion and vacillation in the team.
• The project continues to evolve . When an open-source project happens to be unfinished, users, volunteers, and then developers, leave it. It is in this order, as with the departure of users from the project, its base is eroded. After all, how is the pyramid? Always , a certain percentage of users not only use the program, but also help to develop it: who have bug reports, who translate, who do beta tests, and who do 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 early 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 the new version of the program.

Particularly favorable transition from ad-hoc strategy to the schedule influenced GNOME. I would like to add a photojab, that is, Gimp-processing, Vasya Lozhkin's “Life with a beard” picture, but unfortunately, I cannot write the right words with the arch.

An incredibly large-scale and complex open source project OpenStack has a semi-annual release cycle, but 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 OpenStack in numbers.

• Market size - 1.7 billion US dollars in 2016
• The project involves more than 500 companies.
• Support for different 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 , everything becomes 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 would occur as soon as a set of new features is ready, instead of sticking to predictable and clear timelines ? I think 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, switching from an ad-hoc release strategy to a predictable schedule is a blessing?

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

Likewise, there is no reason for switching from ad-hoc releases to predictable ones, if there were only a total of commits. There should be a critical mass of changes.

There is no linear relationship between these two strategies and the quality of the code , as was shown by the example of FireFox. According to the study , before and after the transition to the predictable short production cycle, the number of bugs after the release of the stable version was almost the same.

It is important to clearly understand which user segment your product is in. It's one thing the gcc compiler, if you roll it out early and damp, programmers will be able to bring it to the file with files. It is quite another thing, Apache web server, to release a stable version ahead of time - it is fraught.

Summarizing all the above . The schedule is preferable to ad-hoc in those cases when:

• 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 is running out of steam, users and developers are scattering because of a very long and unpredictable development and release cycle.
• Your project is critical for partners like GNOME for Ubuntu, so upgrades should be coordinated and synchronized in time.

Used materials

1. Why Open Source Projects Adopt Time-Based Releases?
2. Time-Based Releases (FOSS) Projects
3. Libre / Open Source Software ecosystem
4. Wiki page openstack

---

↑ The book is in Russian translation . In the original, this phrase sounds: release often, release early .