4. Other Factors which erode effective size

Mib Software
High Reuse Software
Development and Consulting
We extend and customize
reusable and open software.

Some Implications of Bazaar Size

Third Draft. Aug 11, 1998
Copyright 1997-1998, Forrest J. Cavalier, III Mib Software
All rights reserved. Comments welcome!

4. Other Factors which erode effective size

There are activities and natural progression which tend to erode the "effective working size" of the bazaar over time. Some of these are also discussed in the sections on debugging. (See
the erosion factors discussed at 2.1 Factors affecting defect "installation")

Erosion due to not integrating some modifications

Incorporating defect fixes
Incorporating modifications which are defect fixes is generally not hard to decide, or hard to approve. The advertisement generally includes details on the fix, why it was necessary, and the fix itself. As long as the fix is not defective, defect fixes are generally included in the "current" and next "stable" release without question.

Incorporating enhancements
Unlike defect fixes, enhancements present a problem because there will be disagreement over what enhancements to incorporate.

("A") not every stakeholder (anyone with an interest in the product) is going to have a
compelling interest to include every available enhancement.
("B") It is very likely that some stakeholders will have objections to including
some of the available enhancements on the basis of:
- not trustworthy (contains defects)
- not compatible with other enhancements, (interferes)
- other unacceptable tradeoffs (incompatible with previous operation, files,etc)

Absence of disagreements is almost never met in practice. Once basic needs are met by the product, there are very few enhancements which will be useful to all stakeholders. (This nearly ensures "a") And "b" is nearly ensured by the simple fact that every modification has the tradeoff of "code bloat" and "creeping featurism." (In other words, there is more code to maintain, which is unacceptable to some stakeholders)

The presence the two conditions for any individual modification means that a choice must be made, and not all enhancements will appear in the next release.

If a subset of customers who depend on a modification are unsuccessful in getting that modification in the next "base", then they can stick with the existing base, (missing out on future upgrades) or they can "fork" and create a separate tree (it is open code, after all.)

This will split the bazaar into two pieces. Although it may be possible to have some modifications which are applicable in both bazaars, most modifications will apply to one or the other. Generally the split is not even, and the ones who depart are in a very small bazaar. Even so, the main bazaar is weakened by the loss of talented "artisan-vendors."

Maintaining the strength of the bazaar (preventing fragmentation) while advancing the product by incorporating enhancements is a very big challenge to successful bazaar product development. This is the task of the project leader, and why having one people will trust and follow is crucial.

Interestingly enough, if the code is not open, this split is not an option. The dissenters are "stuck" because they can't leave to create their own alternative.

Up to: Some Implications of Bazaar Size