Open up that codebase!

Warning, I’m going to rant a bit here!

Dear Engineers, Developers, and everybody else who works with some form of git repositories in an enterprise context,

Can we please stop putting our codebase in private repositories by default? Sure, there are some codebases that contain ultra-sensitive IP or security related settings that might warrant remaining private. But in all likelihood, this is not your codebase. You might know this too, although it might not be comfortable to admit. It is indeed easier to argue for security and closing things off, rather than embedding security into your code, but this is probably not the problem.

Perhaps you’re afraid for the internal competition, or perhaps you’re afraid you will get penalized for the quality of your work as perceived by outsiders. If you’re trying to stay ahead of the internal competition by closing of your codebase, and thereby create some sort of moat, you probably should do a very good job at that because closedness is the exact trigger for teams to start competing, leading to more fencing and toxicity between teams. Rather, stay ahead of the curve by opening up and obtaining management-support to collude with your competitors instead! Sooner or later, every IT project, codebase, engineer, etc will have to face the ongoing pace of increase in productivity.

Perhaps you’re insecure about the quality of your work, and are certain that when perceived by outsiders this will reflect bad on you. And perhaps there are reasons why quality was less important for you. You simply had to deliver, and now you’re somewhat stuck with an MVP that slipped to production without the means to properly implement a safety net. Fair enough though. Maybe you can make this situation last a while, but here as well you’ll have to face the music at some point. And in this situation, it might be even worse, especially if you turned out to be a huge dependency for somebody else. It’s a matter of trust in the end, and over-selling the quality of your work in combination with a lack of transparency is a quick way to lose it.

So, reconsider to what extent your repository contains ultra-sensitive code and think about opening up that codebase. Invite people to criticise your work, as long as they provide constructive and actionable arguments. Work out those improvements and invest in making the code secure-by-design. You might even learn that your colleagues are not there to compete or criticize you, but honestly care about your work and are eager to help you. That way, transparency, openness and a little bit of humility probably will make you a better developer/engineer anad might even make you a better person.

What do you think? Am I jumping too quick to conclusions here, or do you agree?

Tom