I’ve been having some real problems with FireBug recently – essentially it has made itself utterly useless. Why? Well when I set a breakpoint within FireBug and that breakpoint is reached, the code window does not scroll to the breakpoint. I then have to drag the scroll bar down to the breakpoint, then when I press F10 to perform a step over, the code window resets itself to the top. As you can imagine this get rather annoying after a while, especially with large JavaScript files.
As a result of these misgivings I have found myself using the IE8 developer tools – which are actually quite good, though FireBug, when working, is better.
Luckily the project that I’m working on is not exactly critical, though the quicker I get finished it the better. However, if I was working on something that was going to generate me $$$$$$, I’d hope to god that I wouldn’t have to waste so much time with the debugger. With this in mind, and with the mindset of “You are a dumb ass if you fail to utilise open-source software” prevalent in our industry, it raises the question as to the limits of open-source software.
If the software that you are developing is largely based on open-source/free software, and this software sells for hundreds of thousands do you really want to be using libraries that have no real service-level agreement? For example, let’s assume that your software sells for $200,000. Then it’s safe to say that your customers will be expecting some pretty good service for that kind of money. Suppose a bug is found in some third-party open-source library that is used in your product. So you have two options: 1) you ask the community to fix the bug or 2) you fix the bug yourself. Are any of these really a satisfactory solution? I don’t think so.
Consider option 1. Suppose that the project stagnates or your bug is just not an issue for the community, then it may take some time to get this bug fixed (or they may not fix it at all). But you need this bug fixed yesterday! People tell you “Oh there is always someone in the community willing to help”. Nonsense. There are no guarantees and this is exactly what a professional organisation needs. A bank, telecom company, utilities company and so on are not going to give a shit that you can’t get it fixed soon, they will just move their business elsewhere. This is the reality of the situation, and if you are moving a core part of your business out to open-source software and charging a small fortune for your software, I’m pretty sure this is going to come back and bite you. Open-source software proponents can scream until they are blue in the face that this will not happen, but it might, and that’s all that matters.
So if option 1 cannot save you then your left with option 2. Well first, it’s easy to say that you just get the source and edit it yourself, but the fact of the matter is that it takes quite some time to be comfortable with a large code base. In particular, to be comfortable with the fact that making changes in one place doesn’t cause problems elsewhere. OK, unit tests help, but there are no guarantees. Maybe you could be involved in the maintanence of the open-source software on a regular basis to ensure that your team has built up a familiarity with the code. Maybe even developing new features etc. That sounds like a great idea. Until your competitor comes along and uses all these lovely features that you have so kindly developed for them! Then how much of a fool do you look.
The fact of the matter is that if you write the code, then you have more control over it, and this eliminates any dependencies you may have on outside parties. The more you charge for your software, the tighter your service level agreements are, and the more third-party libraries define the uniqueness of your product, the more important this becomes.
This is not to say that we should all go out and write our own compilers, IDEs, and various other things. It’s just a matter about being sensible about what you use.