Construcción de la Matriz

Results of the analysis suggest that there is a positive relationship between the number of implemented FLOSS patterns and the size of a FLOSS project. The two smaller FLOSS projects Rack and Rake have implemented considerably less FLOSS patterns than the three larger FLOSS projects. This relationship seems to be saturated already in a FLOSS project of the size of Spree: Firefox implements about the same number of patterns as Spree, although it is an order of magnitude larger in terms of number of commits. The data itself also does not show causality in one or the other direction: Do FLOSS projects receive many commits if they implement many FLOSS patterns? Or do some FLOSS patterns emerge when a FLOSS project reaches some critical size? The FLOSS patterns itself suggest that both effects exist: Low Contribution Barriers and related FLOSS patterns specifically try to increase the number of contributions, while laborious FLOSS patterns like Preconfigured Build Environment are easier to implement for large FLOSS projects with more contributors. For a FLOSS pattern like Open Dialog, it may become more and more difficult to resist its implementation and seal the developers off from the public when the FLOSS project grows.

The three larger FLOSS projects implemented Bootstrap, and not implementing it is only feasible for small FLOSS projects like Rack and Rake. All analyzed FLOSS projects started with a Market Evaluation and all except Spree with a Credible Promise. These may be important patterns for successful FLOSS projects. The results show that successful FLOSS projects may start from scratch and do not need Donate Code to be successful.

The analyzed FLOSS projects with commercial intentions, Rails and Spree, favored Dual Product over Dual License to Sell Complements. However, these are just two data points and conclusions must be drawn with caution. Another licensing aspect is the choice between a Reciprocal License and a Permissive License. Whether one or the other helps with a FLOSS project to succeed has been the subject of research based on much larger data sets than only five

Table 3.6: Results of the evaluation for all FLOSS patterns and projects

FLOSS Pattern Firefox Rack Rails Spree Rake

Integrate FLOSS Assets

Bootstrap ! % ! ! %

Start a New Project from Scratch

Market Evaluation ! ! ! ! !

Credible Promise ! ! ! % !

Publish Closed Sources

Donate Code % % ! % %

Licensing

Dual License % % % % %

Reciprocal License ! % % % %

Permissive License % ! ! ! !

Approved Open Source License ! ! ! ! !

Architecture Bazaar Architecture % ! ! ! % Exposed Architecture % % ! ! % Sell Complements % % ! ! % Dual Product % % ! ! % Manage Complements ! ! ! ! %

Cultivate a User Community

Crowd of Bug Detectors ! % ! ! %

Support the Community ! % ! % %

Public Inspection % ! ! ! !

Frequent Releases ! % ! ! %

Parallel Development ! ! ! ! %

Central Information Platform ! % ! % !

Open Dialog ! ! ! ! %

Tools for New Developers

Low Contribution Barriers ! ! ! ! !

Preconfigured Build Environment ! ! ! ! %

Unit Tests for Contributors ! ! ! ! !

Low-hanging Fruit ! % % ! %

Empower the Most Suitable

Run a Tight Ship ! % % ! %

Maintainer Handover SS+ CS % % B

Pool Resources ! % ! % %

Single Maintainer % ! ! % !

Meritocracy ! % % % %

Number of implemented patterns 20 14 23 19 10 Number of commits 271 370 2108 54 125 15 691 1911

3.5 Discussion FLOSS projects [SAM06; CMP07; CF09; SSN09], and their results still contradict each other. No matter which of the two licenses a FLOSS project chooses, an Approved Open Source License seems to be an important success factor.

The results for the FLOSS patterns in the category Architecture do not give a clear picture. Bazaar Architecture and Sell Complements do not seem necessary for the success of the FLOSS projects, but are still common enough to be observed in the selected sample of FLOSS projects. An Exposed Architecture is presumably not necessary for smaller FLOSS projects like Rack and Rake, but helpful for larger FLOSS projects. For very large FLOSS projects like Firefox, implementing an Exposed Architecture is possibly difficult. Manage Complements encourages the contribution of add-ons. Add-ons may serve as an intermediate step for core contributions, lessening the difficulties to contribute to the core product. Add-on developers need to consider less dependencies to other components than developers of the core component. They still learn the core component’s API and therefore gain knowledge about its internal structure. Therefore, FLOSS projects gain a double benefit from Manage Complements.

Remarkably, implementation of the FLOSS patterns in the category Cultivate a User Commu- nity seems to depend on the size of the FLOSS project: For each FLOSS pattern except Public Inspection and Central Information Platform, it is possible to define a threshold for the number of commits such that all analyzed FLOSS projects beyond this threshold implement the pattern. Table 3.7 is a rearranged extract of Table 3.6 to illustrate this relationship: Is is observable that the! symbols have the arrangement of a stair.

Table 3.7: Results for the FLOSS patterns of Cultivate a User Community ordered by number of commits and supposed pattern threshold

FLOSS Pattern Rake Rack Spree Rails Firefox

Support the Community % % % ! !

Crowd of Bug Detectors % % ! ! !

Frequent Releases % % ! ! !

Parallel Development % ! ! ! !

Open Dialog % ! ! ! !

Number of commits 1911 2108 15 691 54 125 271 370

The FLOSS patterns shown in Table 3.7 seem to be key ingredients to grow the community of a FLOSS project and benefit from this community. The threshold for Support the Community seems to be higher than for Crowd of Bug Detectors and Frequent Releases, while it seems lower for Parallel Development and Open Dialog. However, while these data give reliable support for the existence of a relationship between the FLOSS patterns in the class Cultivate a user Community and project size, the specific order suggested by Table 3.7 may be only a peculiarity of the sampled FLOSS projects and is not reliable.

All analyzed FLOSS projects except Firefox implement Public Inspection. Firefox has end users as target audience, while the other analyzed FLOSS projects target software developers, specifically Ruby developers. There are two reasons why FLOSS projects for end user applications

do not use Public Inspection while FLOSS projects for software developers do. First, only software developers have the expertise to understand the metrics of a Public Inspection, so most users of Firefox would not benefit from it. Second, the Ruby FLOSS projects except Rake are frameworks and libraries, so their users interface with the code of the components they use. Rake users also have to write Ruby code. Thus, the code must have a high quality. Public Inspection lets the users evaluate the code quality and so software developers know whether they are using a component with high code quality. Users of applications like Firefox interface only with the GUI or command line and therefore need usable applications instead of applications with high code quality. Of course, usability and code quality may be connected, but high code quality does not ensure usability. Thus, Public Inspection seems to be important for FLOSS projects developing libraries and frameworks, but not for those developing end user applications.

Central Information Platform seems not to have a strong influence on the success of a FLOSS project. However, the two FLOSS projects without Central Information Platform still implemented parts of it, so maybe the current form of Central Information Platform or its verification criteria do not yet capture the invariant of the FLOSS pattern.

The FLOSS patterns in Tools for New Developers and especially Low Contribution Barriers seem to be crucial for the success of FLOSS projects, as they are universally implemented by the analyzed FLOSS projects. Rake may not need a Preconfigured Build Environment, as it is small and the build is not so difficult even without the Preconfigured Build Environment. Low-hanging Fruit is an exception in this category, as only two FLOSS projects in the sample implemented it.

The analyzed FLOSS projects employ a diverse mixture of power models and all of them have been shown to work. Rails and Spree Sell Complements and use it to finance development. Running a FLOSS project with volunteers or with the support of a foundation seems to work as well. Remarkably, only the three FLOSS projects without commercial support, Firefox, Rack, and Rake, had multiple Maintainer Handovers, some of which were complicated. Firefox as the only FLOSS project backed by a Foundation also had an especially high number of Maintainer Handovers, but they all went smoothly. However, the evaluation comprises too few FLOSS projects to decide whether these observations are general rules or only coincidences in the selected sample of FLOSS projects.