Your Software Should be Open-Sourced
And you should do this for purely selfish reasons.
This post is a quick reality-check about how you are organizing the code in your application. Unless you are the rare bird who is actually writing an open-source package, chances are that you have modules scattered throughout your codebase that implement Critical Functionality™ that makes your software do the things that The Business needs. It’s all super-duper secret and heads would roll if a single line of source code were to leak. Right?
Well… probably not. Very probably most of your app is boilerplate junk, performing the mundane tasks of reading from a database here or making an HTTP request there. The vast majority of what management might consider to be TOP SECRET intellectual property is… yawn… just the regular boring old foundational plumbing and wires that connect any application. The knee-jerk reaction to keep all the code tightly veiled is akin to middle-schoolers in a locker room: being seen naked may be terrifying for an individual, but mostly everybody has got the same “boilerplate junk”.
For fun, let’s pretend we have snuck into a restricted building, like the Pentagon or the board room of a Fortune 500 company. What exactly about this place makes it “secret” or “proprietary”? If you woke up inside this place, how would you know it was in any way special? It would have the same light-switches and floorboards as any office building. We can imagine that there’s a filing cabinet with secret documents in the corner, but really, the rest of the place is probably pretty banal.
This is similar to how our codebase might best be organized — most of it is the workaday housing for that one special filing cabinet. And one way to help you think about where to put things inside your app is to imagine that you were going to release your company’s application as an open-source project. Yes, THAT app: the one upon which all the business depends. Chances are that things inside that app are a bit sloppy in the same way your living room is messy because you weren’t expecting company. If this repo were to be made public, what things would be critical to remove? Besides the “obvious” stuff like API keys and the like (which you should be storing securely elsewhere anyway), what things truly are proprietary?
When you start to prepare an application for open-sourcing, it tends to force the business-rules to the edges, and that’s a good thing. Maybe your application runs your highly-trained super-valuable algorithm against a bunch of data. So your cleanup process might mean that the algorithm gets pushed into that special corner of the room and instead of hard-coding it into the app, you allow the exact algorithm to be specified via configuration. Your refactored application just makes calls to a configured algorithm, and there’s nothing really proprietary about that scaffolding. You might even discover that that there is some ready-made software out there that you could plug your algorithm into.
Whether or not you actually make your application an open-source project is of course up to you: I am only suggesting this as a mental exercise that can help make your app more modular and testable and improve its organization. The benefit here is similar to what happens when you start rigorously testing your code: writing TESTABLE code can have a profound impact on how you structure it whether you actually test it or not. Likewise, the benefits to your application’s structure will be there regardless of whether or not you actually release your app as an open source project.
Happy open-sourcing!
