Open-source software exists in many of the standard software categories, particularly those focused on the server side. Obviously we have operating systems; web servers; mail (SMTP, POP, IMAP), news (NNTP), and DNS servers; programming languages (the ``glue'' for dynamic content on the Web); databases; networking code of all kinds. On the desktop you have text editors like Emacs, Nedit, and Jove; windowing systems like Gnome and KDE; web browsers like Mozilla; and screen savers, calculators, checkbook programs, PIMs, mail clients, image tools -- the list goes on. While not every category has category-killers like Apache or Bind, there are probably very few commercial niches that don't have at least the beginnings of a decent open source alternative available. This is much less true for the Win32 platform than for the Unix or Mac platforms, primarily because the open-source culture has not adopted the Win32 platform as ``open'' enough to really build upon.
There is a compelling argument for taking advantage of whatever momentum an existing open-source package has in a category that overlaps with your potential offering, by contributing your additional code or enhancements to the existing project and then aiming for a return in the form of higher-quality code overall, marketing lead generation, or common platform establishment. In evaluating whether this is an acceptable strategy, one needs to look at licensing terms:
Satisfying developers is probably the biggest challenge to the open-source development model, one which no amount of technology or even money can really address. Each developer has to feel like they are making a positive contribution to the project, that their concerns are being addressed, their comments on architecture and design questions acknowledged and respected, and their code efforts rewarded with integration into the distribution or a really good reason why not.
People mistakenly say ``open-source software works because the whole Internet becomes your R&D and QA departments!'' In fact, the amount of talented programmer effort available for a given set of tasks is usually limited. Thus, it is usually to everyone's interests if parallel development efforts are not undertaken simply because of semantic disputes between developers. On the other hand, evolution works best when alternatives compete for resources, so it's not a bad thing to have two competing solutions in the same niche if there's enough talent pool for critical mass -- some real innovation may be tried in one that wasn't considered in the other.
There is strong evidence for competition as a healthy trait in the SMTP server space. For a long time, Eric Allman's ``Sendmail'' program was the standard SMTP daemon every OS shipped with. There were other open-source competitors that came up, like Smail or Zmailer, but the first to really crack the usage base was Dan Bernstein's Qmail package. When Qmail came on the scene, Sendmail was 20 years old, and had started to show its age; it was also not designed for the Internet of the late 90s, where buffer overflows and denial of service attacks are as common as rainfall in Seattle. Qmail was a radical break in many ways -- program design, administration, even in its definition of what good ``network behavior'' for an SMTP server is. It was an evolution that would have been exceedingly unlikely to have been made within Allman's Sendmail package. Not because Allman and his team weren't good programmers or because there weren't motivated third-party contributors; it's just that sometimes a radical departure is needed to really try something new and see if it works. For similar reasons, IBM funded the development of Weiste Venema's ``SecureMailer'' SMTP daemon, which as of this writing also appears to be likely to become rather popular. The SMTP daemon space is well-defined enough and important enough that it can support multiple open-source projects; time will tell which will survive.
Next: Bootstrapping Up: Nature Abhors
a Vacuum