Enterprise Software Fallacy #1: "Keeping code secret preserves competitive advantage"
This was once taken as proven fact, and it's still a core of many software company's money-making plans, even those which produce large and respected open source products. The theory goes that people will pay for those extra bits, but not if we make it completely free and accessible. When it was ubiquitous, that was true, because there were no good alternatives; open-source also-rans now fence it in, because 60% of the features at 100% discount (ops S&H not included) is an attractive price for the less important software.
In reality, the company doing (the majority of) the code development will always have a strong competitive advantage with that code. The only thing that can lose you that is to lose the people writing the code. Because the competitive advantage of features is not their existence, but the company's ability to capitalize on them in one form or another, and few people have the time to learn what your code can do better than you do.
Even if those people are outside your company, they're far more likely to ally themselves with you to gain yet more insight, than to attack you in the marketplace. To compete with you they would need to educate those they work with to at least your developers level of experience, and build a convincing market case that they're better at your code than you. It's an uphill battle with an entrenched incumbent, and there are only a few folks crazy enough to do those. What pretty much all those crazy folks have in common was a) they were working on an open source product, and b) that product's owner pissed them off, hard enough to goad them into that hopeless battle. This is a "hostile fork", and it's what scares C-level folks into the default fallacy.
But every hostile fork has a quieter, but just as deadly, closed-source alternative: "abandonware". If you piss off the folks who write your code bad enough to pick hopeless battles, one of the likely responses is going to be "well, fuck this job". And that has a bad way of cascading: as coders leave, their tasks get dumped on the remaining seniors and the poorly educated newbies, and the pressure usually increases. Since good coders are always in demand, the good coders can afford to be more easily offended, and will often be the first to flip the table, which only accelerates this whole process (as they're usually both well respected, and doing the difficult tasks others can't). And once the good parts of the team are out the door, the whole code-base starts to rot (a process which deserves its own article).
When this happens in the open source world, it can sometimes produce a true dangerous competitor: your former development team, forking their own code under a new banner. The MySQL "Baby Bells" (Drizzle, Percona, MariaDB), created in the wake of the Oracle-Sun-MySQL purchases, are fine examples. Non-compete agreements can be a band-aid, but most coders are wise enough not to sign long ones (and again, its the smart ones you care about). But this is true of closed source software, too: your angry team of ex-developers could decide to write a you-killer application from scratch, and if they're good they can do it in their spare time, as they wait out the non-compete clock doing consulting or short-term contracts. They might have a rougher time of it, but at the same time they're also not bound to your crappy legacy code.
An established code base is an advantage, to be sure. But the real advantage is in the understanding of what can be done with it, not in the raw lines of code (or compiled binaries). That knowledge lives in the heads of your employees (developers or otherwise), and the only way to keep it in the company is to retain employees. Communication and education can help on-board new people, but is no substitute for keeping good experience around. Keeping a strong team happy preserves competitive advantage, in ways that keeping code secret never will.
In reality, the company doing (the majority of) the code development will always have a strong competitive advantage with that code. The only thing that can lose you that is to lose the people writing the code. Because the competitive advantage of features is not their existence, but the company's ability to capitalize on them in one form or another, and few people have the time to learn what your code can do better than you do.
Even if those people are outside your company, they're far more likely to ally themselves with you to gain yet more insight, than to attack you in the marketplace. To compete with you they would need to educate those they work with to at least your developers level of experience, and build a convincing market case that they're better at your code than you. It's an uphill battle with an entrenched incumbent, and there are only a few folks crazy enough to do those. What pretty much all those crazy folks have in common was a) they were working on an open source product, and b) that product's owner pissed them off, hard enough to goad them into that hopeless battle. This is a "hostile fork", and it's what scares C-level folks into the default fallacy.
But every hostile fork has a quieter, but just as deadly, closed-source alternative: "abandonware". If you piss off the folks who write your code bad enough to pick hopeless battles, one of the likely responses is going to be "well, fuck this job". And that has a bad way of cascading: as coders leave, their tasks get dumped on the remaining seniors and the poorly educated newbies, and the pressure usually increases. Since good coders are always in demand, the good coders can afford to be more easily offended, and will often be the first to flip the table, which only accelerates this whole process (as they're usually both well respected, and doing the difficult tasks others can't). And once the good parts of the team are out the door, the whole code-base starts to rot (a process which deserves its own article).
When this happens in the open source world, it can sometimes produce a true dangerous competitor: your former development team, forking their own code under a new banner. The MySQL "Baby Bells" (Drizzle, Percona, MariaDB), created in the wake of the Oracle-Sun-MySQL purchases, are fine examples. Non-compete agreements can be a band-aid, but most coders are wise enough not to sign long ones (and again, its the smart ones you care about). But this is true of closed source software, too: your angry team of ex-developers could decide to write a you-killer application from scratch, and if they're good they can do it in their spare time, as they wait out the non-compete clock doing consulting or short-term contracts. They might have a rougher time of it, but at the same time they're also not bound to your crappy legacy code.
An established code base is an advantage, to be sure. But the real advantage is in the understanding of what can be done with it, not in the raw lines of code (or compiled binaries). That knowledge lives in the heads of your employees (developers or otherwise), and the only way to keep it in the company is to retain employees. Communication and education can help on-board new people, but is no substitute for keeping good experience around. Keeping a strong team happy preserves competitive advantage, in ways that keeping code secret never will.