When I write code, I am always trying to think in terms of reusability, and
not just for me.  Ideally, I want developers to be able to leverage my work
efficiently and with very little effort.

I have identified four levels of software reusability:

  1. No reusability.  The least interesting of all.  It’s
    typically a standalone application that was designed to serve a finite set
    of goals and not be extensible by anybody else but its creator.
     
  2. Binary reusability.  While the source is not available,
    binary reusability enables third parties to write extensions to the
    software.  Microsoft COM is the best example of such an approach, and
    it’s been tremendously successful.  For example, even though you don’t
    have access to Internet Explorer’s HTML renderer, you can still embed it in
    your applications and take advantage of all its power (Yahoo Messenger uses
    it but you would probably never tell).
     
  3. Plug-in reusability.  This is very similar to the binary
    approach mentioned above but with the difference that the operating system
    is not involved in the connection between the plug-in and the core
    architecture.  Eclipse is a good example of such an approach, which can
    also be used in the absence of the source.
     
  4. Source reusability.  The software is shipped with its entire
    source code, making it possible — in theory — for everyone to extend it at
    will.

From the least reusable to the most reusable, I would sort these approaches
as follows:

1 < 4 < 3 < 2

First of all, the fallacy that all it takes to make a software reusable is to
open-source it needs to die. You are truly deluded if you think developers will
try to understand your thousands of lines of code, and that’s a lesson that
Netscape and most projects on sourceforge have learned the hard way.

The reason why options 2 and 3 are the best way to make your software
reusable is simple:  instead of overwhelming the developers with your
entire code base, you are making an extra effort to identify parts of your
software that are truly reusable and you expose them in a readable way both in
terms of documentation (Javadoc and similar) and software patterns
(interfaces, factories and dependency injection mostly).

This is exactly what COM+IDL did with the resounding success that we know,
and more recently, Eclipse, with its terrific plug-in API based on OSGi.

While reading up on COM and Eclipse will be very useful if you intend to make
your code reusable, you can start with simpler tasks such as using your own
plug-in API yourself, inside your core product.  Start with the core
services and build on top of it while keeping in mind that in the future, other
developers than you might be writing similar code.

A good hint that you’re on the right track is to see a lot of interfaces in
your code (and consequently, it is strongly discouraged to use "new" on classes
that you intend to expose in your plug-in.

I’ll expand on these techniques in future entries.