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...

Debugging Tip #2 - P6Spy - A mini review...

Following the excellent comment I got earlier today to my last entry, I took a look at P6Spy - a tool for capturing jdbc information within your application... Looks solid and mature...

For those interested about how it works, it's a proxy pattern - it wrappers your (real) jdbc driver ... so when I call DriverManager.getConnection() it's calling P6Spy's getConnection (which in turn proxies this off to the real driver...) ... all of the sql classes are proxied (ResultSet, etc... ) allowing it to capture as much data as your little heart would desire...

Only caveat was that it didn't work with jdk 1.1.8 ... In fact I'm not sure if it works with anything less than 1.4.x ... but given that it needs to implement / wrapper all of the objects, and given changes in javax.sql.* set of classes as java has evolved you'd need an implementation of P6Spy for each major version (that you cared to support...) so... it's not unexpected that it requires 1.4.x ... Running the new Enterprise version of Fast BugTrack with 1.4.X JVM got everything working fine... Would be nice if they mentioned the required JVM's in the install / troubleshooting section of their docs - but I'm not complaining ;)

Just a note that using tools like these are handy not just for debugging your application, but can also help you identify inefficient SQL or potential bottlenecks that will allow you to optimize your application... The P6Spy log file was (obviously) much easier to read than raw packet data... easy to sort / filter / etc...

Debugging Tip #1 - Using tcpdump / windump to figure out what's going on...

We had a problem today...

A bit of background - we build the Fast Suite on JDK 1.1 ... We chose it, because after many many years, the jre's are rock solid, so our server will stay up for months, and the small size of the jre keeps our download size down...

In JDK 1.1 land, when you're using sql PreparedStatements, with logging turned on, there's no way to see what the actual sql is that is being sent to the database... So we're getting a funny error from Oracle on some of our inserts... How to figure out what's going on?

A couple of options pop to mind... Using a proxy server - having FBT talk to the proxy, and the proxy in turn talk to the database... Quick to setup, captures everything - could be protocol issues, and when I tried it (without trying too hard) it didn't work for the Oracle protocol... Moving to option 2...

Option 2 is to use a packet sniffer to capture traffic between FBT and Oracle... Took about 15 minutes to download and install the tool on my machine and successfully capture what I was looking for... What did I do?

1) I'm on a Windows machine, so I used windump (the windows version of tcpdump...)

2) I messed around with the options, and used the following to get what I was looking for:

windump -i 2 -X -s 500 -w out.out port 1521

-i 2 = interface 2 (try windump -D to list interfaces and try other numbers if this doesn't work...)
-X - capture raw data
-s 500 - grab 500 bytes / packet (you might need to make this bigger for big sql commands...)
-w out.out - write the data to a file called out.out
port 1521 - only capture data on port 1521...

3) Then use FBT and generate the error...

4) Stop windump...

5) Check out the newly created file "out.out" - it will be full of binary info - but will also have raw text of SQL... I was able to find all of the sql between my machine and Oracle ...

Just a note that windump / tcpdump is a handy tool for examining / debugging / reverse engineering any networky type app... Running it on an unswitched network will allow you to basically capture all of the traffic on the network, to diagnose network slowdowns, etc... You could also be very evil with this tool... The primary ways to avoid losing data to a tool like this is to be on a switched network, use secure communication such as ssh or ssl ...

Another handy tool (in the Unix world) for figuring out what a 3rdparty library is doing, solving IO problems, etc is strace ... Not only allowing you to see network IO, but all IO (including disk IO), and any other kernel level calls within your system - want to generate megs of logs in no time at all - you need not look past strace...

FIT released - enterprise version nearing completion...

Very busy the past few days...

We've just released our new Issue Tracking Software -- Alcea Fast IssueTrack ...

The "Enterprise" (database vs. flat file) version of our software engine is nearing completion - we're testing with as many databases as possible to ensure that we don't produce something that will require a tricky patch down the road for customers that start using the enterprise version right away...

We're also specing out a commandline interface for Alcea Fast BugTrack... Something that will use our existing SOAP interface - and that could be called by 3rd-party tools (say - to interface with a source code repository such as CVS, Visual Source Safe, etc... ) or by uber-geeks that don't want to go to the trouble of working in a visual environment...

Lots of stuff touched on in this post - perhaps will get time to go into more detail as time goes on... Going to try turn on comments and see if anything appears...

A bit about me...

Who is writing this? My name is Chris Justus, and I'm a geek who's been using computers since getting a Vic-20 back in 1982/83... I went to the University of Waterloo (Canada) from 1990-1995, and have been getting paid to program computers since 1991... I have several passions, beyond computers, including my family, business/marketing stuff, and various other interests and hobbies... But the focus of my blog is going to revolve around server-side stuff, the software development life cycle, and the trials and tribulations of creating and selling commercial off the shelf software - I'll also add my 2 cents about the IT industry, jobs, consulting, etc...

More to come as time allows...