The Republic of Bulgaria has a problem: When the government needs a piece of software, or a new website, they get on the phone to a software company that makes a custom solution, created based on the current needs. The result is often an expensive, buggy mess, that is painful to maintain, hard to modify when the needs change, and it usually has more security holes than there are craters in your average Swizz cheese. Soon, the software is abandoned, and often replaced with new and even more expensive software that has exactly the same problems as the abandoned piece of poppycock.

So, are Bulgarian software companies particularly crappy? Probably not. This is not a problem that is unique to Bulgaria. I’ve seen the same thing happening here in Norway, and I can’t imagine that those are the only two countries that struggle with low quality code finding its way into government software solutions. Those involved in project management often believe that a more fine-grained level of control solves the problem of expensive and failed projects. This, in turn, usually leads to more bureaucracy, more reporting, more meetings, more documentation, and a lot less time for making high quality, maintainable code. The time to market increases dramatically, and the projects deliver even less value for the end user at a higher cost than before.

Now Bulgaria has decided to try an unorthodox approach in the pursuit of great software and websites: Every custom line of code that’s made for the government has to be open sourced.

This is a great idea, at least in theory. Open source means that Bulgarian tax payers can see what they are actually paying for. This will only be something a negligible percentage of the Bulgarian tax payers will actually do, but everyone still has the option to have a look at the code.

That the code is available for everyone who wish to look at it might increase the code’s quality and maintainability: Many developers will man up and have a second look at their code when they know their work might be scrutinized. That said, pull requests and code reviews should be part of any professional developer’s average workday, no matter if they are working with open or closed source software. On top of this, software developers aren’t a superior breed of humans. As with any profession, you have bad software developers, as well, people who will - either because they don’t know any better, or they simply don’t give a shit - create low quality code. So open sourcing a project doesn’t necessarily mean that the code will get better.

Another related potentially positive side effect of open source might be that bugs and security vulnerabilities that somehow goes unnoticed can be spotted, and ultimately fixed by 3^rd party developers who look at the code. Many users of open source software, myself included, feel safer knowing that what we use is open source, because we can freely look at the code. The problem is that most of us assume that someone else is doing the job and making sure the code isn’t bug ridden. The fact, however, is that very few people actually check the code. A prime example of this false sense of security is Heartbleed. From Wikipedia:

Heartbleed is a security bug disclosed in April 2014 in the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol.

A postmortem code review of OpenSSL showed that the Heartbleed bug had been present since 2011, and it has been speculated that the NSA might had been abusing the bug to eavesdrop on encrypted internet data for over two years before the code-whoopsie was discovered and fixed. What if a similar bug finds its way into an important government website that expose sensitive data about a country’s citizens? That the code is available as open source doesn’t mean that only the good guys will look at it to find bugs, it’s perhaps more likely that the code will become a viable target for black hat hackers looking for security holes to exploit.

Related to this topic is the much higher demand open source puts on the developers in terms of what they put in the code repository and their commit messages. In closed source projects, passwords, private keys and sensitive configurations too often finds its way into the code repository. While it’s seldom a fatal error as long as the repository is private, it can quickly turn into a catastrophe if the code is open source. What if your private encryption keys are committed to the repository? Or the administration password for your production database? Neither of these should be in a closed source repository either, but if they accidentally end up there, the level of trouble you’re in is far from the kind of mess you might have to deal with in an open source project. Black hats are already taking advantage of people committing code they shouldn’t to public repositories by scanning them for secrets.

One of the greatest benefits of open source software is the opportunity for other developers to include, modify and re-use the code in their own projects - given that the code’s license allows it, of course. But for the code to be of any real value for other developers, some form of documentation is necessary. The code itself can often be good enough, but some higher level documentation, at least of the code’s general purpose and public APIs can be very useful and saves a lot of time for the developer who want to take advantage of the open source code. This sort of documentation (usually) doesn’t write itself, but it shouldn’t be a massive cost associated with getting it done compared to in a closed source project, where basic public API documentation should also exist.

Is open source a silver bullet? Will open sourcing their code solve the Bulgarian government’s software problems? Far from it. Open source code can be just as crappy its closed source sibling. Open source is no guarantee for high quality, maintainable software that quickly delivers end user value. But going open source might have some positive side effects for the Bulgarian government, as discussed above. I hope more governments, and organizations, take note of what the Bulgarians, follow their progress, try to learn from whatever mistakes the Bulgarians do as they learn how to do open source in a way that delivers value for them, and use that knowledge to create their own, successful open source policies.

And I’d also like to wish Bulgaria the best of luck with their endeavor: Please don’t screw this up, I’d like to use you as a success story.