Hi, this question is directed to Joel, but I'd also love to hear from anyone else with relevant experience...

In the FogBUGZ FAQ I noticed that you provide the FogBUGZ source code to licensed users. I am wondering how this policy has turned out for your company. Can you discuss the business case for this choice? Has it been a major factor in customers' decisions to adopt FogBUGZ? Have you received many bug fixes or enhancements from customers?

As a consumer of software, I'd be very happy to see more vendors provide sources. (Note: I'm talking about traditional binary software companies providing their sources under a non-redistributable license, not Open Source(tm)). I've lost count of the times I've wanted to patch out an annoyance (e.g. an unnecessary confirmation dialog box) or add a minor feature (e.g. support for a new image file format) to a thousand-dollar-plus binary software product. Plus, I'd love the extra security of having sources in case the vender goes under.

Looking at the business case from a developer's perspective, I can imagine at least two possible drawbacks to providing sources. 1) You can't play nasty tricks like using obfuscated file formats that change with every upgrade. 2) You give competitors the opporunity to learn from, or even steal your code outright. Obviously the extent of this threat varies with the type of software; you might not care if someone appropriates your code for hash tables and linked lists, but e.g. a proprietary high-performance video codec would probably warrant more protection.

As an independent developer, I would very much like to provide sources to my customers, but I am particularly concerned about the threat of code theft. There have already been at least two documented instances of software companies appropriating Open Source code for their own binary products (in direct violation of the licenses). I certainly don't have the resources to wage a full-scale legal battle against a larger competitor. (and that's assuming I could even detect the code theft!)

-- Anonymous, June 22, 2001

Answers

Dan,

If you give your code away and people actually use it, and make a buck out of it, is that theft?

If they don't use it, then its probably not worth giving away.

As a developer I think that if people are giving code away and it is good quality code, why would'nt it be used? Who wants to reinvent the wheel?

If you dont want people to 'profit' from the code you write, don't give it away, simple.

Its not corporations that steal code, its the developers, like you and me who recognise good product. All developers under time pressure will adopt quality fast track solutions.

I give code away, but my motto is, give it away and forget about it, or don't give it away.

Cheers Tony McConnell

-- Anonymous, June 22, 2001

Hi Tony, thanks for your response. I admit I should have been more clear about my use of "theft" and my motivations as a software entrepreneur.

If a licensed customer takes code I've provided with my own product, and uses it on a totally unrelated project, I probably wouldn't care. The customer benefits from using the code, and my own revenue opportunities remain the same. However, if I take time to develop, say, highly optimized code for image processing, and then a competitor integrates my code into a similar product of their own, I'd be very upset.

I agree that in a strictly academic sense, this is a favorable outcome: two parties both derive benefit from a code base, the initial development cost of which is only incurred once. BUT, I would then be responsible for strengthening my competitor's product, and thus diminishing the potential return on my investment.

Perhaps the decision to provide sources with a software product rests on the balance between 'pro' (making the product more valuable to customers) and 'con' (potentially reducing the future return on the developer's investment).

I'll try two examples within this framework: A. Sun and Microsoft both provide sources to their OS kernels (with restrictions). They believe that the extra value of distributing sources (bug fixing, security auditing, etc) outweighs any advances that competitors might make by examining the code. B. My friend, who independently develops a sophisticated flight simulator product, is adamantly against distributing any source code. He believes that the extra value it would deliver to customers is small compared to the potential losses in revenue that would result if a competitor adopted his code.

Does my perspective make sense to you? It does feel strange to me that a fundamentally *technical* decision (whether or not to provide un-obfuscated source code) depends mostly on the current *business* position of the developer in his/her industry... If only things were simpler =)

-- Anonymous, June 22, 2001

A dealer of ours once came to me. His potential client was asking about the source code, like was it in escrow etc. The dealer was obviously keen on the sale. At first glance it seemed like a no- brainer, but the real issue was more complicated. Out of the analysis the following points were raised;

A) It's not enough to have the source code. For example we use a programming language called Clarion (www.softvelocity.com). We also make use of a number of 3rd party components. Sending the source code to the client was useless. They would also need a copy of the current compiler, plus a copy of all the current 3rd party tools AT THAT POINT. (The reason is obvious - assume I gave you source to say a VB 3 program. What's the risk of being able to collect a working copy of VB3 + assorted components today? What chance of that source compiling in the latest VB?) Cost of this would be around $4000 at that time.

B) The system we are selling is fairly big. About 500 000 lines of code. Which means nothing from the computer's point of view - but a fair bit from a programmer's point of view. Any takers for tweaking a 500 000 line system? Ok - simple changes are brainless - but what about fiddling with the low-level winsock handler, or the computation engine, etc..? Assume you're the independant contractor tasked with this job - how much would you charge ?

C) What about support? Obviously the dealers support the system. What if the client made a change to the system. How would the dealer know? Assume the dealer knows that the client tweaks the software. Would you want to support a "customised" version? Especially if the person doing the customising isn't a genius?

D) What about upgrades. How does one practically merge "customisations" with future version releases? What if I upgraded my compiler and/or 3rd party components?

The bottom line was that the client could spend a lot of money if they wanted to - but it would be completely useless to them in the long run. Basically the "off the shelf" price for the system was around $9000. The cost of doing anything useful with the source code would have been zillions more.

For a "simple" task, like a video codec, perhaps it's a possibility, but for whole systems I don't think you get anywhere.

Example 1: Lets say the whole of Ms Office was available in source code. Would you want to support customised versions? Would you like to create customised versions? How many customisations would you tolerate? What if one of the "bright programmers" customised the file format....then moved on to another job?

Example 2: Lets say you write an application for Linux. I email you for support. Ah - I'm running Redhat 6.2 (or Corel, Caldera et al - with Gnome, KDE et al) and your application won't print properly. And yes I did tweak the kernel a bit (I'm _sure_ it's not related...) and yes I did "optimize" the printing engine (I print a lot...) - but hey I'm pretty sure it's your program that doesn't work... And yes I live on the other side of the country. And (to be honest) I did fix a few "bugs" in your code... What are you going to say?

If you ask me, the only people really interested in my source code are my competitors. Put another way - they're the only ones who would benefit from what it would cost...

Just my 2 cents worth of course - sorry for rambling on...

Bruce Johnson - CapeSoft

-- Anonymous, June 27, 2001

Well, you have to wonder in what ways opening up your code makes strategic sense. I've happened upon companies I wouldn't have visited before, because they have open-sourced products. I in fact make it a general policy not to use closed products within systems I ship, because the source adds a value that counts for a great deal. It goes a long way as far as documentation when the docs are vague (as they inevitably are in some places), and in a company like Joel's, he uses it to gain footholds with his consultancy. Selling software does scale up well, but again it is likely a bad idea to make blanket statements like, "All my software will be open," or "All of it will be closed!"

And plus, those who look at your code to see how you implement something will be much more loyal to you. Not many people will do this for any given piece of software, but it does often happen.

-- Anonymous, July 18, 2001

Bruce is right. Customers want support. Competitors want code. You might think the only exception is if your customers are software developers. Then they might want code. But that's b/c they are competitors, too.

If you are really smart you might let your customers take your code, though, b/c that will generate more support. They'll screw it up and then you'll be the only guy who can save them.

-- Anonymous, July 19, 2001

Instead of providing source, a way to let them "patch out an annoyance (e.g. an unnecessary confirmation dialog box) or add a minor feature (e.g. support for a new image file format)" is to physically structure your product (e.g. several one or DLLs instead of one monolithic EXE) and publish their interfaces.

Take a version control system for example: ship its work-engine as a compiled binary with a defined API; ships its GUI as a VB or HTML thing with source code; this lets them tweak the GUI (if they want to), add stuff to the GUI (file import from some other format), while protecting the intellectual property that you really care about.

-- Anonymous, September 06, 2001