---

1. The Importance of Bazaar "Effective Size"

Implicit in some of Eric Raymond's description of a successful Bazaar development method, is the notion of the bazaar being "large-enough" to find bugs quickly, or "self-sustaining." While his writing seems to imply that size does affect success, this is not stated or discussed directly.

I hold that size is very important, and discuss reasons for this view.

Comments on bazaar size as a precondition
Raymond speaks of preconditions for a successful bazaar. I asked about the size of the developer pool (who will start the bazaar) as a precondition, since this was not mentioned.
His "off the top of his head" comment was:

"....thinking in terms of a hard minimum number of participants is misleading. Fetchmail and Linux have huge numbers of beta testers *now*, but they obviously both had very few at the beginning.

What both projects did have was a handful of enthusiasts and a plausible promise. The promise was partly technical (this code will be wonderful with a little effort) and sociological (if you join our gang, you'll have as much fun as we're having). So what's necessary for a bazaar to develop is that it be credible that the full-blown bazaar will exist!"

Implicit in these and other comments is that there is some minimum number of participants in order to have a successful bazaar. How many is "too small" to successfully apply bazaar development concepts?

Raymond does not define "bazaar" in a concrete way which would allow defining a "size measurement." I define three size measurements for bazaars: "total size" and "effective size", and "effective power."

The "total size" of a bazaar:


The sum total of the number of individual participants.



The "effective size" of a bazaar:


The total of the number of participants motivated and able to contribute the results of individual effort (modifications, enhancements) or provide feedback to the bazaar for a specific activity. Appropriate unit for effective size are "participants".






The "effective power" of a bazaar:

The effective size multiplied by the average (per-participant) contribution (hours per unit time) Appropriate units for effective power are participant-hours per week. This could also be defined as the integral of contribution to a specific activity over all participants.

"Specific activity" is very important to effective size. Bazaars may have very large effective sizes for some activities and not others. For example, a bazaar with a size of 5000 may only have an effective size of 5 (or even less than 1) for an unpopular activity such as documentation or regression testing. This may be due to lack of motivation or inability to contribute. (Many bazaar efforts are volunteer efforts.)

Effective power is a function of effective size AND the activity level of the participants. It is possible to have one participant contribute more or less than another. One highly active participant may contribute as much work per week as 5 or 10 less active ones combined. Bazaars with more highly motivated and active individuals have larger effective powers.

Types of bazaar participants
In order to try to count the participants for discussing the size of a bazaar, I break the participants into three main types/profiles based on their reason for participating and level of involvement. An individual person may move between different profiles over time, or even play roles in multiple profiles simultaneously.

• "The need-driven consumer" This participant is using the product solely because it fulfills a need or goal. They may not be a programmer. They may be uninterested or incapable of locating code responsible for defective behavior.
  
  
• "The user-developer" Raymond uses the term "co-developer" This participant is capable and interested in advancing the product, contributing code, comments, discussion, etc. as well as being an active user of the product. Motivation may be to "have fun", "learn", "make a contribution", or even get something that fulfills a need of use.
  
  
• "The core developer" A participant who is actively supporting and advancing the product. May be willing to work on development because it is necessary, even if it is hard, unpleasant, and/or has little personal utility. May be a strong advocate, promoting the product, helping new users, etc.
  

Observations on effective size and power

• Activities are completed in the time dictated by the task, methods used, and the effective power. Improved methods can compensate for lower effective power.
  
  
• If the required effective size for an activity is not realized, then that activity will not be completed, regardless of effective power or size for other activities.
  
  
• Because there is often an implicit deadline for completion, some activities can require a minimum effective power in addition to minimum effective size. (In many bazaars, the deadline is set by external competing products, market perception of delay, or other factors. It is not
  always acceptable that product evolution in a bazaar takes an infinite amount of time.)
  
  
• Some activities are sequential. The "effective size" for a sequence is the minimum of the effective sizes of each individual step.[1]This observation has profound implications for debugging by testing, as is discussed in the next topic.
  
  
• In order for a series of activities to be completed, the effective size must be realized and the effective power at each step must be large enough to complete the task in the required time.
  
  
• Attempting an activity which will fail is a waste of resources.
  
  
• Willingness of new participation is strongly a function of the activities the bazaar is able to complete. If a large number of activities fail, then the bazaar participants will start losing interest, bicker and argue further reducing the effective size and diluting effective power. With reduced effective size it even less likely that there will be completed activities, and the bazaar may wither and die.
  

---

[1] (April 2001). David Isecke pointed out that this statement can be confusing, because "effective size" is defined to measure the bazaar, not the requirements of each step. The next bulleted item states it more clearly.

---

Next 2. Debugging by testing dramatically lowers effective size
Up to: Some Implications of Bazaar Size