Considering Open Source

See also CombiningOpenSourceAndXp.

Reading the first few books in the XP Series clarified so many thoughts in my head that I started keeping a journal of XP-related ideas (Justin's Extreme Journal). Here is an early entry:

Considering Open Source 7/13/01

Eric S. Raymond, in "The Magic Cauldron", identifies five "discriminators" that "push towards open source." If all five are satisfied, the software should be open; if none are satisfied, it is reasonable to stay closed. I would like us to consider, for each piece of our product, how each of these discriminators applies, and honestly consider OpenSource. And this is real open source, not the "not free for commercial user" kind or "the application is free but the platform is not." I want to identify components that satisfy the discriminators and that do not depend on components that do not. We should even aim to refactor our design to maximize the number of such components. Here are the discriminators:

A related issue is our use of OpenSource components maintained externally. While ExtremeProgramming does not take a position relative to open source, I think many of the practices, such as refactoring, encourage the adoption of open source components. If we can start off with mature code that already does what we need, that will always be better than writing new code ourselves. Refactoring goes a couple of ways here: on the one hand, we can refactor our code so as to create more opportunities to plug in open source components; and on the other hand, once we have adopted an open source component, we can further refactor our code to push extra features we have written into the scope of the open source component. In this way we will be making maximal use of open source components and at the same time making maximal contributions to those projects. Any code we push into the open source component should be donated back to the project which owns that component.

-- JustinSampson

Thinking about this now, I'm reconsidering EricRaymond's discriminators in the context of ExtremeProgramming... (Forgive me if this has all been discussed elsewhere. WikiWikiWeb is just so cool, it just feels natural to spill out some ideas from the top of my head. And by the way, I haven't worked on either an OpenSource team or an ExtremeProgramming team, but I have been inspired by ideas from both. These journal entries were part of my attempt to introduce OS and XP to my development team. So this is all ThinkingOutLoud without too much RealWorld evidence.)

This will usually be true for any enterprise software; Raymond mentions video games as a kind of system that does not have these requirements.

Here's an odd one. Correctness of design? Peer review? XP takes them to an extreme with UnitTests and PairProgramming.

The motivation of this one seems to be more of a client risk thing than a development thing. That is, if the software is critical to the client's business, the client should demand that the software be OpenSource in case the developer decides to stop supporting it.

Here he's referring to network protocols, mail servers, etc., things that are used everywhere and that can benefit from being used and debugged heavily. Raymond calls this the NetworkEffect.

This one is really pragmatic. If some module is not some central intellectual property, it might as well be OpenSource. It seems silly for everyone else to duplicate the effort.

So the way I look at it now, I don't expect OpenSource to really enhance software quality (a, b, c), but it totally makes sense for parts of a system which would really be duplicated by anyone who tackled the same problems (d, e).

Applications
An application as a whole doesn't generally make sense as OpenSource since it addresses a specific business need (UserStories). This is the driving part of any ExtremeProgramming project, and it's what the team is getting paid for.
Subsystems
A subsystem is characterized as (1) having significant internal implementation and (2) being isolated behind a stable interface. If a subsystem isn't being maintained as part of the application itself (e.g., a database), then (1) suggests significant investment which will be paid for somehow and (2) suggests that closed source is okay from the application developer's perspective, because an alternative implementation could be swapped in by adapting the interface.
Frameworks
A framework is a package which provides a surrounding structure for applications in some particular domain (Web portals, simulations, whatever). The central application classes will extend classes in the framework package to provide distinctive functionality. According to ExtremeProgramming, a framework should not be a starting point of development, but could very well be a product of refactoring that could happen to be reused across projects. This suggests that frameworks are appropriate for OpenSource.
Toolkits
A toolkit is a package whose classes provide lots of helpful functionality. Unlike a subsystem which should be isolated behind an interface, the classes of a toolkit will be used at a much finer granularity. Like a framework, a toolkit is the kind of thing that should emerge from application-driven development, but just might happen to be reusable. Since the application will be dependent on the toolkit at a finer granularity, it is less acceptable for such a package to be bought as a closed-source product.

So I'm saying for applications and subsystems, ClosedSource makes sense, and for frameworks and toolkits, OpenSource makes sense.

Now I have to go to sleep so I can read more WikiWiki tomorrow. :)

-- JustinSampson

CategoryOpenSource

EditText of this page (last edited August 30, 2004) or FindPage with title or text search