Monday, May 31, 2004

Why you don't want my source code...

We develop a commercial bug tracking system, Alcea Fast BugTrack... We've been building and improving it over the past 3 years, and while we've always been very happy with it, it's grown to be a pretty full featured defect tracking system... Occasionally, we will come across someone wanting the source code when they buy our product... We've almost always refused and I'll outline why you don't want the source code for a commercial, well maintained system... This doesn't apply to open source systems, and it might not apply to all commercial systems, but it applies to many...


  1. Feature Drift / Upgrade pain... Once you get my source code, and start making changes, if you're not feeding those changes back to me (as an open source system would work), then as soon as I create a patch, new release, whatever, you're either: (a) stuck with the version you bought, or (b) going to go through patch fun / hell as you re-implement / fit your changes into the new code... In our case, we're release maintenance releases at least once a month, and major releases about every 9 months... So missing a year of upgrades will mean you'll miss lots of great new features...
  2. Supportability... It can be tricky enough to identify specific installation issues - change the code, and without knowing what changes you've made, you're almost impossible to support...
  3. Wasted development effort... You don't have enough to do that you want to start making code changes to a commercial system? We want to build the best system we can, we get tons of suggestions for improvements to the system, and we can implement a feature in a way that meets all of our customers needs... We have a dedicated development team that knows the code inside and out - we've been working with the code for 3 years...


The rebuttals to these arguments will talk about what happens if I go out of business (Alcea's been in business for 7 years, is self-sufficient / self-funded, and we're not going anywhere - but you can't take my word for it...) ... At best I would recommend putting the code in escrow...


A better way to customize my system is through the ways that we define - through a clearly defined web-service and/or hooks put in place to allow extensions to the system... Just as layers of code define interfaces between the layers, so systems of code can define interfaces between the systems...

3 Comments:

Anonymous Anonymous said...

Hey, cool! I can post without a blogger account.

Jed, it's your call whether or not you want to buy without the source code. Just like it's Chris's call not to distribute it. Not having done much SOAPy stuff I'm assuming there must be a javadoc equivalent that Chris is using to document his public API.

FB is a commercial offering. Properly documenting a public API should be the minimum standard if they are serious. No source needed for that.

The other test of course is how thier 1st and 2nd level support deals with any issues you find with the API its docs, and actual behaviour. The only way to measure that before buying is to find out what other customers have experienced, or try it out yourself (there is a trial version right?).

Just like any other commercial software offering.

Geoff

May 31, 2004 9:48 PM  
Anonymous Anonymous said...

When aimed at a technically-aware audience, source code can be a valuable support resource similar to documentation.

While you don't want people using the code to enhance their installation, the ability to read the code to puzzle out bugs or integration issues, along with then forwarding this detailed information back as a bug report, can be very useful.

May 31, 2004 10:21 PM  
Anonymous Anonymous said...

Jed,

>I don't mind what FB's policy is per se - I am not a
>customer - but a no-source policy does negatively
>affect (or a source-provided one does positevely
>affect) my usage decisions. That being said, if it
>came to a decision between a source provided suite
>more expensive and less able than a closed source
>competitor I would go with the latter.

Nothing wrong with taking that stance. I've been in that situation myself in other problem domains.

I'm just glad that there are enough players in this space that one has the option make these choices.

Geoff

June 01, 2004 11:38 AM  

Post a Comment

<< Home