Free for all

What would happen if tomorrow we made freely available all the source code to Code Collaborator?

Can you imagine Intuit releasing the source code to Quickbooks? Or EA Sports handing out the code to NHL 2008? Even cool companies like 37signals go so far as to encrypt their hard drives against theft of code.

Most software companies would consider such a thing contrary to everything they hold dear. But sometimes it's worth challenging assumptions.

Why not?
So what are the specific reasons to not publish our source code? What are we afraid of?

Well this should be easy...

Competitors catch up to us quickly because they can easily copy everything we've figured out how to do: Cool AJAX/DHTML techniques that they don't have; Super-smart file-differencing algorithm; Interfacing with 7 version control systems while handling all the corner cases.

We show them the way, they catch up, and suddenly we're neck-and-neck instead of keeping our lead in awesome features.

Support becomes impossible as customers make arbitrary changes to the code. They could change anything -- from benign things like CSS styles to introducing a subtle bug in application logic. It's hard enough to track down problems in the field without "all the code" being a variable!

Besides supporting bugs, you know we're going to get source-level support questions. Yeah you can say "we don't do that," but it's going to happen and it's hard to turn people away.

Potential customers scared away after seeing the state of your code. You laugh, but it's a valid concern. Much of our code is well-documented and well-tested. But some isn't. Some is downright embarrassing. You never know what someone else's impression might be.

Yeah, but not so much. Apparently all these fears are unfounded.

Here's my disconnect: There are small companies just like us who publish all the source code to their software, and none of these concerns are a problem for them.

Take for example the issue-trackers JIRA (Atlassian) and Fogbugz (Fogcreek). Both are in an insanely crowded space with fierce competition ranging from open-source to small-company closed source to big-company software/services.

And yet, both are popular even with the fear of competitors stealing secret sauce. Both are highly profitable, not buried under a mountain of technical support. Both have ugly pockets of code, but I've never even once heard anyone mention that as a downside, not online, not in the field, and certainly not as a reason to choose a different product.

So what's the explanation?

Ummm, just because?
All the following are theories. I honestly don't know the answer.

To me the biggest upset is in the assumption that competition automatically gets tougher. Here's some possible reasons why it doesn't:

1. Writing an algorithm is just the start. So let's say a new competitor steals our awesome, optimized, unique AJAX/DHTML code for real-time, context-sensitive chat. So now we're even? Well it doesn't matter until a potential customer is checking them out, which means executing on marketing and advertisement. And it doesn't matter if during the trial we give the customer a personal demo and responsive tech support while the competitor asks him to post a question on a forum. And it doesn't matter if all they can claim is that they're "the same." All else being equal, most people will go for the incumbent, proven, most popular tool, which is us.

2. Competitors need to differentiate. Even if you could be just like another product, you don't want to be. Sure you might pick up some ideas for algorithms here and there, but that's not enough by itself to sway potential customers.

3. Developers like doing things their own way. Every good developer I know wants to write code herself. Yeah you might pick up some ideas but your first reaction to almost any code is that you could write it better, organize it better, document it better, make it more flexible, whatever.

4. Most code is not reusable. Almost all our code depends on assumptions, design, and other code that is relatively unique to our product. Sure we have some utility classes that could be copied and reused, but those are the kinds of things that are easy to unit-test-to-hell which means it's not hard to reproduce it even without our source code.

5. Serious companies don't steal. Any serious competitor will have internal rules about stealing code, even if it's an open-source project. Once again, little tricks here and there could sneak in, but not wholesale copies of libraries. A serious competitor has too much to lose -- revenue, customers, possible future upside -- and if that comes out it's all over.

The other two items are easier to understand. Support can be kept in check:

1. Most people won't change the code.

2. Limit support on source code changes. Your customers will understand that you cannot provide unlimited support on that front, so you can just pick and choose how much time to spend helping someone. It's no worse than a competitor who is closed-source.

3. Include a "source changes" report in tech support reports. We have things like verbose logs, config files, and diagnostic pages, so just add something that tells tech support what, if anything, has been changed by the customer. If something has been changed and you cannot reproduce the issue, you can now reasonably deny tech support unless they can reproduce with a clean installation.

So... are you going to do it?

Nope. :-)