Subject: Re: Dwyer, FRB, Economics of Open Source
From: Frank Hecker <frank@collab.net>
Date: Sun, 28 May 2000 13:00:57 -0400

kmself@ix.netcom.com wrote:
> Modularity (or lack thereof) has been suggested as a failing (or at least
> significant obstacle) in the Mozilla project.

Note that Mozilla at present is pretty modular; almost all functionality
is invoked as components through the XPCOM mechanism. It is in fact true
that "Mozilla Classic" (i.e., the original code released by Netscape in
1998) was not very modular; this was in large part due to its originally
having been developed in an environment where modularity of design and
APIs for use by developers took a back seat to features and time to
market. When Mozilla moved from a closed source to an open source
environment then the needs of developers (as opposed to end users and
marketing people) became more paramount and the Mozilla code was
restructured (really, rewritten) to be more modular. I haven't yet read
Dwyer's paper, but I suspect this may be in agreement with his
arguments.

> Others [3] have suggested
> that the MozPL encourages poor program design by dividing software at the
> file boundary, which makes for clean law but dirty code.  Well defined
> application interfaces would be Don's preferred mode.

For what it's worth, I personally have not seen this effect of the MPL
(encouraging poor program design) in practice; I'd be interested in
whether Don Marti had actual evidence to show this or was simply
speculating. As noted above, any design flaws in Mozilla Classic is not
really evidence, since it predated the MPL itself.

On the opposite side, many people have commented that the most
reasonable way to add a proprietary extension to an MPLed program is to
put your proprietary code in separate files (per MPL requirements) and
then to call that code from the existing MPLed files via a defined API
(existing or new). If you can use existing public APIs in the MPLed code
or have your new API be adopted into the mainstream MPLed code then you
can avoid the "stupid tax" of having to continually reintegrate your
code into future versions of the MPLed code.

Based on this some might claim that the MPL actually promotes modular
design rather than the opposite. I won't make quite that strong a claim,
but I do think that the MPL (or any license for that matter) is not a
major factor in promoting poor design.

Frank
-- 
Frank Hecker            work: http://www.collab.net/
frank@collab.net        home: http://www.hecker.org/