Fog Creek Software
Discussion Board

Source Code When Using 3rd Party Tools?

When you decide to use a 3rd-party tool or SDK in your application (such as Joel just did), do you always purchase the source code, so you're not completely out of luck if you come across a bug you need fixed RIGHT NOW, or if the vendor goes out of business?

Just curious about what others think. Our policy is that we ALWAYS require source code, just for the reasons outlined above.

Thursday, March 27, 2003

I've worked with people who absolutely, positively insist that all 3rd party utilities must come with sourcecode for end-of-the-world scenarios. Total number of times said coworkers EVER modified said source code, or even realistically used it to find or fix a bug? Zero. Ziltch. Nada. We were always too busy with bugs in our own code to learn all of the domain knowledge for something like image code. Personally I believe that many of the doomsdayish demands for sourcecode are props afront a political statement about open source.

If for some reason the image components that Joel uses goes out of business in the future, he could (with a relatively small amount of work presuming the components are blackboxed well enough) switch to a competing set of components. There are plenty of options even when using closed source.

Dennis Forbes
Thursday, March 27, 2003

I wouldn't ALWAYS require source code, but it would depend on the likelihood and impact of any potential bug.

For example, I don't require the source code to the OS the app runs on, or the compiler used to build the app.

If I integrate with office via COM then I can't get the source code but can still be affected by bugs outside of my control.

If the 3rd party tool is auxiliary to the main functionality (e.g. a simple email component) then requiring source code may restrict your options too much and/or push the cost of the component too high.

Fixing bugs in a 3rd party library would have to be a path of last resort as it leaves you responsible for maintain a codebase you weren't interested in writing in the first place.

Rob Walker
Thursday, March 27, 2003

I can't count the number of times I have looked into an open source library's source code to try to figure out how to work around or fix a bug.  I've even looked at Sun's Java JVM source code in order to work around bugs. 

If you can't get the sourcecode, though, I reccomend that you write thin wrappers around the libraries so that you can swap in a competing product if the one ypu've purchased doesn't work or the company goes out of business. 

Colin Evans
Thursday, March 27, 2003

I've occasionally found it useful to look at source code and see what something does.

Modifying source code in a 3rd-party component or app would be risky if I were relying on it in a production environment. Also, when you commit to using a modified version of someone else's product, you risk forfeiting your upgrade path when new versions of that software come out.

Beth Linker
Thursday, March 27, 2003

There are several problems to beware of in insisting on source code.

The first is that a lot of companies won't release source without an enormous payment (because it represents their company's capital). You might be forced to use a second rate tool from a company that doesn't care instead of a first rate tool from a company that does.

The problem with fixing bugs yourself is that you are setting yourself up for a maintenence nightmare. Every time you upgrade you are going to have to reapply your fixes. And if you change the behaviour significantly you are starting to diverge your version from the suppliers. Be very sure you want to get into this, or you might find yourself both paying the supplier for the tool and maintaining it yourself.

If you are mainly concerned with 'end of the world' scenarios, your best bet is to try to get 'source in escrow'. Here the company deposits its souce code with a third party, who will make it available to you under certain circumstances (such as the company going bankrupt). You will have to work out a legal agreement, but it shouldn't be much more complicated than a non-disclosure agreement.

We've found that on thw whole it is better to set up a good enough relationship with the supplier that they fix things quickly for us. If they can't it may be because their source code is so awful that nobody could fix it anyway.

Good luck.

David Clayworth
Thursday, March 27, 2003

The maintenance doesn't go into lib fixes.  It goes into the workarounds you use.  Having source helps me write better (= less ugly) workarounds.

Thursday, March 27, 2003

I've been going through this exact situation. In every case so far, I've opted to go without the source code, because demos were available that I could thoroughly test to ensure it did what we needed it to. I would really only want the source if it was _close_ to what we wanted, but not exactly, so I could modify it to make it what we wanted.

Brad (
Thursday, March 27, 2003

It depends on the company and their reputation. Leadtools, for example, has been around forever and their image code has been the defacto standard for years and years....

Joel Spolsky
Thursday, March 27, 2003

Seriously, I know this is off-topic and everything, but what's with mentioning Leadtools twenty times?

You can do better, really.

Thursday, March 27, 2003

Leadtools was interesting (I used it some while ago)  - it fell over, more than a little bit, during the development process. Do anything at all wrong and over it went (not fun in VB on Windows 95).

Once you'd worked out how to do what you want in the order that didn't cause it to fall over it was practically bombproof can't recall ever having an issue with a delivered app. And you could make it do most things.

I was, at the time, seriously unimpressed with cost and one or two other issues... haven't looked at it since - but I think one would pretty much have to if I wanted to image manipulation again.

Thursday, March 27, 2003

Thanks for all of the great feedback.  Specifically, we're looking for a datagrid for our .NET Windows Forms application.

We've used the datagrid that comes with the Framework, but we're about to go into a second phase which requires functionality like grouping rows, showing summary information for the grouped rows in the header row.

What makes this challenging is that we have _very_ specific requirements in terms of how we want it to work, so we are skeptical that we'll find something out there that will work _exactly_ the way we want it.

So far, the Xceed grid is the closest to what we want--supports grouping, and supports the Windows Forms control classes (which we rely on heavily for our own custom controls.)  Anyone have any experience with this component?

Thursday, March 27, 2003

As a general rule, I always require source code. Part of this is because my platform of choice, Delphi, doesn't support backward binary compatibility with newer versions of the compiler. When I have the source, I can recompile in any version and be good to go. The Delphi community is unique in that there are VERY FEW companies that do not provide source either by default or for a very small fee. Indeed, Unlimited Intelligence Limited (my company, at, ships source will all our Delphi components (and .NET components, when they become available, will probably be no different).

As for a datagrid for Windows Forms, I'd suggest you look at They were among the first to the .NET party as far as components go.

Tim Sullivan
Thursday, March 27, 2003 is a good place to look for stuff like that. They usually have a pretty complete list of commercially available components.

Brad (
Thursday, March 27, 2003

Presumably Joel mentioned Leadtools because that's what he's been using lately in the context of this topic. Give the guy a break!

John Topley
Friday, March 28, 2003

I find the most useful thing about having source code is the increase in your ability to debug. Often you will get a situation where you're code crashes inside a library due to something you have done, or failed to do, but without being able to trace into the code it is considerably harder to track the route cause.

Mr Jack
Friday, March 28, 2003

Tim: We evaluated, and purchased, the devexpress grid about 1.5 years ago.  The fundamental problem: we derive all of our own control classes for text box, combobox etc.

You can't just stick a .NET control into their grid as an editor; you have to implement a big honkin' interface and register the editors in the global assembly cache. (Some of this is a little hazy--it was about 12 months ago.)

Anyhow, the bottom line is that we abandoned that grid (after spending quite a bit of cash on it) because of the lack of support for plugging in the .NET controls.

Or perhaps I'm missing something, and/or they've enhanced their grid since we looked at it?  Anyone else have experience with the devexpress grid?

Friday, March 28, 2003

*  Recent Topics

*  Fog Creek Home