Not Invented Here?
"Not Invented Here", a clever phrase often used as a pejorative to indicate that somebody (usually due to ego?) would rather reinvent the wheel and write their own implementation than leverage an existing (and by implication, better) implementation. In this entry I try to shed some light on real technical reasons why "rolling your own" may be better than relying on somebody else's implementation.
First, let me state that I am in favor of leveraging existing work whenever possible. It is often more economical to purchase tools than to build your own. It is sometimes more economical to purchase tools than use open source equivilents. It is sometimes wiser to use open source implementations than either purchasing or writing your own. Each circumstance and situation is different, there isn't one right answer for every situation.
Also, the opinions expressed below are from an API designer's perspective, not from an application developer's perspective. Some of the same principles can be applied, but it should be noted that an application developer's needs and goals are fundamentally different from those of an API designer.
I also want to go on the record and say that similar competing implementations are not always a bad thing. I agree with Romain's statement on his java.net blog:
First, creating a new and similar to another Open Source project is not reinventing the wheel. No matter how close two projects can be they'll never be exactly the same and they won't match the same requirements and goals from a user's perspective and from developers point of view. Don't think of wheels, but of tires. There are a lot of different sorts of car tires nowaday because they all suit a particular need. Every winter in France we change the tires on my dad's car to put snow tires. Why don't we complain about that and demand good tires for both steep and snowy roads as well as dry and hot freeways? Because that's not what you really want, you want a set of tires very good at one thing instead of clumsy at many purpose.
The problem with developing API's that rely on some third party project is that if the third party project decides to grow in a different direction, or modify components or APIs in a way that doess't harmonize with your own APIs, you end up having a huge mess. You end up having to fork their project (assuming that their project has a license compatible with your own). Even if they are doing fine but you have bugfixes/feature requests that go unanswered, you have to fork the project. Or when their release schedule is incompatible with your own, you end up delaying your own product or forking theirs.
This problem doesn't usually occur as an application developer, or even developing massive APIs that are internal to an organization, but happens when you are developing APIs for the general community. Also, it cannot be forgotten that portions of SwingLabs are candidates for inclusion in future versions of the JDK. As such, we need to a) have proper copyright ownership so that Sun can change the license to the standard java license and b) rewrite anything that is from a third party project anyway before it could be included in the JDK (unless we got the rights to all of their source code and liked it. Either way, it''s going to be a fork).
I can say this much, we are very interested in providing developers the best solutions possible for writing rich client apps. We're not interested in having our own personal implementation "win" (assuming there was such a thing), but rather in having the entire community win. Part of this will require many judgement calls, and where the SwingLabs team's judgement differs from another team's judgement, we'll get differences. Since SwingLabs is LGPL, there's a lot of safety in using SwingLabs -- there is no vendor lock in. And, those portions of SwingLabs that we want to move into the JDK may be part of a formal JSR as well, so everyone has a chance to have their voice heard.
Hopefully this helps present some of the trickier issues involved in using third party components/libraries, the forces and factors at work on us, and express our desire to work with the community to provide the best solution in one place, and in a way that may be accessible to all of the java community in the future.
My personal opinion is that sometimes you're better off using existing code, sometimes you're better off buying existing code, and sometimes you're better off writing your own. Which is best for a given situation is a judgement call. And hey, let's ease up a bit on the "Not Invented Here" accusations.*
[*] While this blog was inspired by zander's use of this phrase in my last blog's comments, it is in no way intended as a rebuttle or slight. Sometimes this accusation is a worthy one, and I cannot comment on whether his use of it was accurate or not. This question has been posed to me several times over the last year, so I thought now was a good time to post my opinion.