One of the biggest fears in a software company is that their source code could be leaked. All secrets revealed! All that trial-and-error and long hours with customers and careful planning… the results of that effort are now sitting on your competitor’s desktop, free for the taking.
Although we know it probably wouldn’t make a difference, investigating this fear turns out to be a valuable exercise
When you cringe thinking of your next open-source competitor having your source code as a starting point, what specifically comes to mind?
Surely not all your source code would help them. Some of our code is seriously bad news. I would wish this code on a competitor.
Besides that, a lot of our code is not interesting or can already be pilfered. The code that lays out our HTML? You can see that using “View Source.” Our method for moving data between Java objects and the back-end database? Who cares, everyone uses Hibernate. Our web-application architecture? Who cares, nowadays everyone should be using different architectures that were built from scratch to live in a DHTML/AJAX world.
So what would I actually worry about?
Here’s one. Our version control integration library is built from five years of hard-won experience in the field. There are so many corner-cases and combinations of configuration. It represents thousands of man-hours. We have thousands of unit and integration tests, most of which using data that came from the field. Our advanced integration is unique in the market and is used by every one of our customers, so giving up that insight to a competitor would hurt.
There are a few other things, mostly complex, optimized algorithms. But what’s amazing to me is that the overwhelming majority of our code could get leaked, and it wouldn’t help a competitor.
I’ll bet if you’re honest about your own project you’ll find the same.
Implications
1. We’re by far the #1 product in our market, even though almost none of our code is “secret sauce.” Maybe having “secret sauce” isn’t nearly as important as execution. Maybe your customers are interested in how you treat them and whether you’re implementing features they need, and not interested in how much work it took to write the code. Maybe it’s more important that you can get eyeballs to your website and that your website gets people to download, and not so important whether you have a patent on something.
2. We should leverage our uniqueness in marketing material. I just identified the parts of our code that make us unique and where our competitors are not likely to catch up quickly. “Secret sauce” in code can point the way to market differentiation.
3. We could be spending less time on the stuff that isn’t “secret sauce.” You have to be careful with this rule because it would be easy to say, for example, “Because the layout of our website is easily copied, we shouldn’t spend time coming up with a great layout.” Dead wrong!
Here’s a better example: We rolled our own web application framework because we felt it would give us a leg-up in certain ways. But in retrospect, the framework ultimately didn’t do anything that special, certainly nothing that a customer would care about. Before embarking on a large, time-consuming project that could be satisfied by a tool or library, consider whether you’re truly adding “secret sauce” that will give you a leg-up, or whether you just felt like reinventing the wheel.
4. Perhaps it would be useful to employ selective obfuscation. Whole-project obfuscation is at best a pain and at worst can create bugs in code that depends heavily on introspection and dynamic loading. And this exercise shows that it’s not that useful. But there are certain places where it is useful, and obfuscating a small number of well-understood classes is easy and relatively safe.