I’ve just started working at GitLab, and I’m bowled over completely by the kindness and talent of the people I’m meeting. On my second day, I met with Dmitriy Zaporozhets, founder of the software project GitLab and co-founder of my company, GitLab, Inc. We spoke about the release date: it’s same day, each month, always. What is this madness? I wasn’t used to things being released ON TIME and deadlines not shifting. I discovered this monthly release date is at the heart of working at GitLab.
“At GitLab we believe you shouldn’t wait for something to be perfect: Release what you have and do it on a schedule,” said Dmitriy.
GitLab comes out the 22nd of every month, no matter what, no delays, no exceptions. This schedule creates a pace of active development, crucial for open source projects. The predictability builds trust for users and helps them plan better. Most importantly, this approach reduces stress and increases individual and team satisfaction-- because you actually shipped something.
Shifting deadlines? Stop.
Dmitriy explained the philosophy behind the monthly release schedule.
“People expect things to be finished and perfect to meet a deadline,” Dmitriy said. Yet, no matter how you improve the estimation and planning process it seems there are always unfinished tasks as a deadline approaches. To resolve this, the most typical response is to move the deadline instead of changing the objectives.
“Constant delays in release dates creates disappointment, because you don’t see the result of your work being used,” Dmitriy said this negatively affects motivation, creates confusion and erodes trust.
There is an alternative. Instead: move remaining tasks to later releases, and don’t move the deadline. This approach is unusual, but not unique; for example it is used in Ubuntu. They release every 6 months. It’s a time-based release, not a feature-driven release.
There are many advantages.
- There are advantages for users. They know there is a fixed release date which for which they can prepare and plan.
- It gives open source projects a leading edge which increases adoption and participation. Predictable, frequent releases are crucial for open source projects: People don’t want to help and contribute on a project which is dead or stalled.
- There are also advantages for the core developers. It promotes working with passion in periods of intense activity then celebration and relaxation.
Recently, Michael Walsh of Enovate Design posted a review of GitLab. He mentioned the release date as a benefit, and I asked him how it affects his own work. He said it wasn't so much that it affected his own work.
"I like the regularity of monthly releases (the 22nd is a date I look forward to!) and it's a routine now to check the release blog post. The monthly releases certainly focuses my attention on GitLab more compared with other services that have no/little consistency to the timing of their releases." see comment in context
He knows when it's coming out, and it's nice to think that it's a day he looks forward to.
How does a time-based release promote quality?
A feature drive release process works well for SaaS services. When a feature is ready you don't need to wait for a specific date to release a certain feature. On the other hand, if you're working on distributed software, users need to be prepared for a release. Having personally experienced long and delayed open source releases as both a user and community member, I'm convinced of this. Time based releases, with strict deadlines, could work best for open source projects especially.
Time-based release cycles promote discipline, emphasize quality, and increase motivation.
Dmitriy had a good metaphor, he compared it to going to the gym. It’s better to get to the gym for part of your training plan, instead of skipping it because you don’t have time to do the entire thing. It promotes discipline.
Knowing that each month you will release ‘no matter what’ forces you to focus on high-priority tasks. If you come to a stage where it’s clear certain features are not making it into this release, these tasks get deferred. Sometimes you may find that these tasks were not as important as you thought, or new insights come from the release and you change the features.
You can’t separate the software from the process and people developing it. Managing energy and motivation is very important. A predictable release schedule has huge effects on motivation.
He described a friend of his, a designer, who was feeling demotivated in her job. She would constantly experience deadlines pushed out further and further, and the products of her work remained unused or unseen. This is discouraging. It’s this kind of experience that pushes people to leave their jobs. Shifting deadlines results in a complete lack of satisfaction, and no chance to celebrate or rest.
Dmitriy explained that yes, sometimes people working on GitLab will work longer hours in the rush to release. “We build something we use ourselves, and this means developers are working to get features in before the release date so they can enjoy the features sooner. This can be an intense period,” he said. But it’s followed by a rest period and celebration. “I believe this approach emphasizes relaxing more and working less,” Dmitriy said. People can work with passion and play with passion.
A personal desire for quality
Dmitriy Zaprozhets started GitLab in 2011. Like the start of many open source projects, he was scratching his own itch; but he was also motivated by quality. I think many developers who participate in open source projects can relate to his experience.
“Previously, I worked as a developer on a small team for a consulting agency. I jumped from project to project. It seems like you get the list of the tasks completed, but then you’re just assigned another list of tasks. There is a flat line of work with spikes in activity in reaction to unplanned crises,” Dmitriy said.
“I was motivated by quality. I think quality matters everywhere, but that quality isn’t always appreciated. There’s a difference between software quality and code quality. The application functionality depends on the software quality: features, reliability and speed, which clients can experience. The code quality itself is something they can’t see or appreciate. Because of that it gets deprioritized,” he said. I think many developers can relate to that experience. You can be put in a situation of doing low-quality work that you’re not necessarily happy with.
“In those teams, it’s typically the leaders who set the pace and level of motivation and quality,” he said, and hinted that you might not always be motivated by those leaders. In response to this, “Many people who work in consulting companies have side personal projects or collaborate on open source projects to get that experience of quality.”
I laughed when he said this. “Is this how GitLab started?” I asked.
“Yes,” Dmitriy said and smiled.
He wanted GitLab to be a place where he could focus on quality. Like many others who are inspired to build open source, he wanted to attract others to participate. He wanted his software to get released, he wanted it to be used. For him, the choice was obvious. A time-based release cycle and a monthly cadence of releases was the only way to fulfill this. It would be the way he could ensure that the people he attracted to the project were inspired, motivated, and delighted.
The debate is on.
Is a time-based release cycle the best option for all open source projects?
I imagined if a feature-driven release cycle held a debate about Quality with a time-based release cycle, that the feature-driven cycle could lead the argument by saying “We’re holding out for perfection!” In rebuttal, the time-based cycle could argue that their approach leads to a more vibrant, active, development community and ultimately a higher quality product. And besides that, it SHIPS.
While a feature-drive release cycle can allow SaaS services to get to market with new features really fast, it can stall and stymie distributed software and especially open source projects. From the release of the long-awaited Drupal 8.0 the open source CMS is moving to a predictable release schedule, with predictable dates. Scheduled minor releases (8.1.0, 8.2.0) will be released every six months. The challenge for that project will be to resist shifting deadlines and instead, shift objectives.
I’m curious what the GitLab users think about time-based or feature-driven releases, specifically for open source projects. I’d love to hear if you have experience of both, how it affects your motivation and the quality of work.
Next: How we manage releases for GitLab
Next week, in a follow-up to this post, Dmitriy will share specifics about how the GitLab team manage our releases, along with some tools and examples to coordinate work among a team. Subscribe to our newsletter which includes links to our latest blog posts.
