Fog Creek Software
Discussion Board

Selling your source code

How do you feel about including the source code with your product? Of course, this would be most useful if the product is aimed at other software developers. I was thinking it might give customers a bit more confidence in purchasing a product from a small or unknown company if they know that, in the worse case scenario, they can support the product themselves.

It seems like something that makes the most sense as a feature of the "enterprise" or "pro" version of your product, if you have one.

Tuesday, March 9, 2004

Here's a rather old article about that:

I haven't yet found any reason to regret shipping FogBUGZ in source code form.

Joel Spolsky
Fog Creek Software
Tuesday, March 9, 2004

Have you ever encountered customers who may have been slightly distrustful of the small size of your company and thus insisted on having source code in case your company went under? 

This is a situation I'd encountered a few times at my old company.  Of course the problem was, such a thing was pointless because it wasn't like we had the time or the expertise to do anything meaningful with the code if the vendor actually did go under.

Tuesday, March 9, 2004

There's more than one way to supply source code.  It's all in the license and the sale.  A few examples:

- Source code available as part of a (more expensive) "enterprise license".

- Source code available in escrow (customer gets the source if your company folds).

- Source code available as read-only, i.e. customer is not permitted to modify it.

- Source code available as internally modifiable, customer can perform modifications but they must remain in-house.

- Source code available publically, anyone can download it and modify it.  You choose whether to accept modifications.

- Source code available publically, anyone can modify it.

The right approach for you depends on the type of product and its customers and your business model.

Should be working
Tuesday, March 9, 2004

I recommended our company buy FogBUGZ to replace Agstools' BugTrack ( Perl-based open-source available at: ), partly because FogBUGZ looks/is nicer (which is good when non-programmers have to use it), partly because BugTrack development seemed to have died down and partly because Joel was promising integration with Visual Source Safe and programmatic submission of bugs using e-mail and/or the scout. (all of which are cool)

Having the source code to FogBUGZ meant I got to fix a few bugs that prevented me from integrating FogBUGZ into our development process (minor stuff like fixing a few XHTML-related bugs), plus it also meant that we were no worse off than we were with BugTrack, whose source code we also had.

It also made it easier for me to create an ASP.NET interface to give our customers add, list and view access on a per-project basis, while keeping FogBUGZ itself on an internal server.  Our customers can't be assigned bugs (so I'm not trying to get around the licensing feature), but they do get to submit and track bugs with an interface that looks a lot like FogBUGZ itself. (in fact, the "add" form is relayed to FogBUGZ's built-in public submission page and they "edit" by sending e-mails through the built-in Dispatcho features)

Having access to the FogBUGZ source code meant I was able to reverse-engineer the look-and-feel a lot quicker and be done within a week.  We may end up entering a partnership with Fog Creek software to sell this as an add-on/extra to FogBUGZ in the future, who knows?!  :)

Tuesday, March 9, 2004

Woops, misread the post.  Maybe I'll RTFA more carefully next time. ;)

Wednesday, March 10, 2004

I, for one, would be interested in an add-on that did what Oli's does. 

Michael Dorfman
Wednesday, March 10, 2004

Yeah, I'll buy that add-on. It has been on my to-do list for some time, but it seems all my in-house projects get pushed back.

Friday, March 12, 2004

*  Recent Topics

*  Fog Creek Home