Why Bürokratt chose the model of open development

For us, open development means being completely public regarding to pretty much everything.

Majandus- ja Kommunikatsiooniministeerium
Digiriik
4 min readDec 7, 2022

--

Open development vs open-source software development

First things first.

You can read about open-source software development from Wikipedia, but at the time of publishing this article, Wikipedia does not yet have a page to cover open development. So this is kind of an uncharted territory yet.

For us, open development means being completely public regarding to pretty much everything. True, we don’t publish our contracts with partners, etc, but you can find everything else from here.

https://github.com/buerokratt

Adopting open development

Bürokratt fully adopted open development in May 2022 and hasn’t looked back since. Ca 6+ months later, consists of 22 public projects, most of which are in status of initial thoughts, drafts, or work in process. The first ever of such projects can be found from here.

We are still making our first steps

We are still experimenting, looking for the best practices and fine-graining our processes, but the big picture is there. Everything starts with public draft projects, adding initial thoughts to mark the key elements of user stories and acceptance criterias to be, moving on to fine-tuning them, and then, finally, getting it done by ourselves or with the help of our partners.

Everything always in public with 0 internal project management tools, code repositories, etc.

There’s nothing special about the process, just doing it in front of everyone.

Discrete learning is not the key

I once heard Priit Raspel, a legendary IT-guru in Estonia, saying that he asks his students not to practice discrete learning. Simple, right, but really the foundation of open development as well. If you’re stuck on something, let everyone know of it so they could resolve it. Not to help you out as a person but by knowing that the money is there to pick it up.

When you scale it to a level of large projects, the effect is imminent. And for the business owner, this is where the value lies in — less time-consuming onboarding because of discrete learning, which, in the end, the business owner always pays for.

Lessons learned

I guess the best way to describe the positive effects of open development is collateral benefits. We don’t have a strict guideline to follow, except the demand to do everything publicly. Some key aspects will definitely be agreed upon and published at some point, but we are not there yet.

Still, one of the major effects so far is a lot less pointless meetings. When you have agreed to first ask your minor questions as GitHub comments and only have a meeting if it’s absolutely necessary, the result is getting almost no minor questions at all. The effect of this to your daily calendar is massive.

There’s also a major shift in mindset of everyone involved. Knowing that whatever you do, even if you change it right away, will be visible as git history until the end of times, changes what you do. And this results in higher quality.

And of course, if you feel like someone is just trolling you and this discussion is leading nowhere, just ask them to ask the same thing as part of a public discussion. In most cases, such discussions end there.

Finally, faster onboarding. We have a lot to improve regarding to that and we are working on it, but this is what we are aiming for. We want everyone to always have a near real-time overview of everything related to Bürokratt, be it business- or technical-wise.

But getting there takes time. The most common question to us by partners can be re-phrased as “Yes, fully open development, got it, but we’ll be actually doing things in private and just reflecting the output to public, right?”. No.

Call for action

If any of this makes you curious, be it on a business or technical level, contact us via buerokratt@ria.ee or any of the team members directly and let’s have a chat.

Next — separating business decisions from technical ones

In our next article, we cover the practice of completely separating business decisions from technical ones. Many say it’s the only way to go, others see it as a bad trip. We have adopted it and know what to think of it.

Rainer Türner
Bürokratt architect
Information System Authority of Estonia

--

--