Loading...
 

History: Constructive Cost Model COCOMO

Preview of version: 62

Constructive Cost Model (COCOMO)

WikiSuite is the most comprehensive and integrated Free/Libre/Open Source enterprise software suite ever developed, so you'd expect that it took a massive amount of work. But how much? As of 2019, WikiSuite's cost to develop is well over $US50 million.

Cost Model

Really? How is this calculated?

Yes, really: If you tried to re-code WikiSuite using proprietary models. Below are the reports for various WikiSuite components generated by Black Duck Open Hub. Here is one example: https://www.openhub.net/p/openfire/estimated_cost, and it has this note: "COCOMO is meant to include the design, specification drafting, reviewing and management overhead that goes along with producing quality software." More info:

How can it be free and who paid for this?

Like Wikipedia, GNU/Linux and Firefox, WikiSuite is the result of massive collaboration.

How do you arrive at "well over $US50 million"? Are you including the cost of GNU/Linux?

No. Just the Linux Kernel would cost billions to redevelop.

The WikiSuite-specific code (mostly ClearOS installers):

This is intentionally as small as possible since we focus on upstreaming code to the various Software Components.

The main software components:

Tiki Wiki CMS Groupware

Stats broken as of 2019-04-04


Openfire

Jitsi Meet

ClearOS

Syncthing


Over 9,500 commits

Optional components

Elasticsearch


Over 44,000 commits

Kibana

Kimchi


We won't count KVM as we consider it as part of GNU/Linux

FusionPBX

FreeSWITCH

Xibo

Isn't the figure exaggerated?

In some cases, it's actually underestimated. COCOMO counts the number of lines of code. But a project like Tiki has been in active development for over 16 years, and there have been over 68,000 code commits. This battle-tested code costs more to develop than a younger application that would have the same number of lines of code.

As of February 4, 2019, Tiki's cost of development is estimated at USD$14,744,047, and the latest revision is #68960, which represents about $214 per commit. Given the work that goes into software development, and since "COCOMO is meant to include the design, specification drafting, reviewing and management overhead that goes along with producing quality software.", the cost is clearly not overestimated. And that doesn't even count the 125 external dependencies. Think about it. Each dependency represents a distinct community / code base / bug tracker / etc.

Ok, but is this for plugins / duplicated functionality?

No. There is minimal feature overlap / code duplication in WikiSuite because our philosophy is to avoid it as per our component criteria model. While it's true that some of WikiSuite's components have apps (ClearOS) or plugins (Openfire), it's mostly a deployment mechanism, and there is no mess (community fragmentation, etc.) as described at: http://pluginproblems.com/

Given this huge value, isn't it a high cost to maintain the apps?

Many of the software components are 10 to 15 years old, so they are quite mature. Maintaining a mature app, even with it undergoing occasional revamps, is a tiny fraction of the effort of rewriting it. And now, each of the applications has a community / ecosystem that uses it and is highly motivated to maintain and develop it.

If another suite has more lines of code (and thus a higher dollar amount), does it make it better?

No. The goal is to have all desired features with minimal complexity, and a sufficient community to sustain it. Some other suites are focused on facilitating self-hosting of many apps, including apps with identical functionality, but WikiSuite is very opinionated about the apps that compose it. We believe supporting more than one application for the same need adds unnecessary complexity and fragmentation. We believe WikiSuite's model is the best way to have the most features, with the least complexity. Please see: http://pluginproblems.com/

Ok, but I am not going to use all the features

That is true of all feature-rich software. But the economics of software development don't make it feasible to build software exclusively tailored for one use case. Community Free / Libre / Open Source software will necessarily want to cater to a wider community and get more users and contributors.

But adding up these figures is way more than $50 million

Indeed. The total of the figures in the screenshot above is $142 million. But then

  • Someone could argue that such or such component is over-evaluated.
  • One of the projects could reduce the number of lines of code (ex.: after a refactor) and then, the figure would go down.
  • Someone could argue that the COCOMO formula is inappropriate.
  • In some projects, the dependencies could have been counted (which was not done in the case of Tiki).
  • Someone could say (for example) that FusionPBX is not well integrated in WikiSuite, and thus, it should not be counted.
  • Someone could say (for example) that FreeSWITCH is so popular (and integrated in many things) that it should be considered as an infrastructure component like GNU/Linux and not part of WikiSuite.
  • etc.


So if we go with $142 million, the figure can be fairly challenged as being exaggerated. And then, the narrative shifts to this topic (are we being honest with the numbers). This would be a distraction. We will never know the precise "cost to develop". It's an approximation to provide information on the scale/magnitude. Thus, the chosen strategy is to claim that WikiSuite's cost to develop is "well over US$50 million", which is really hard to discredit. And most humans are not that good with big numbers: $50 million is just as impressive as $142 million to most humans :-)

Conclusion

Even if we exclude dependencies (which is debatable), and not count all the components, we can see that the cost to develop is "well over US$50 million". This demonstrates the following:


History

Advanced
Information Version
Marc Laporte 64
View
Marc Laporte Fixed 63
View
Marc Laporte Add a section: But adding up these figures is way more than $50 million (a fair question) 62
View
Marc Laporte Changing because it's currently broken 61
View
M. Bilal Siddiq 60
View
M. Bilal Siddiq 59
View
Marc Laporte 58
View
Marc Laporte 57
View
Marc Laporte Thanks luci! 56
View
gary.cunningham-lee Fixed an error I introduced; changed large-figure format (to use comma). 55
View
gary.cunningham-lee Some edits for general readability, etc. 54
View
Marc Laporte 53
View
Marc Laporte 52
View
Marc Laporte 51
View
Marc Laporte 50
View
Marc Laporte 49
View
Marc Laporte 48
View
Marc Laporte 47
View
Marc Laporte 46
View
Marc Laporte 45
View
Marc Laporte 44
View
Marc Laporte 43
View
Marc Laporte 42
View
Marc Laporte 41
View
Marc Laporte 40
View
Marc Laporte Links are above 39
View
Marc Laporte 38
View
Marc Laporte 37
View
Marc Laporte 36
View
Marc Laporte 35
View
Marc Laporte 34
View
Marc Laporte 33
View
Marc Laporte Addressing reasonable questions 32
View
Marc Laporte 31
View
Marc Laporte 30
View
Marc Laporte 29
View
Marc Laporte 28
View
Marc Laporte 27
View
Marc Laporte 26
View
Marc Laporte 25
View
Marc Laporte 24
View
Marc Laporte 23
View
Marc Laporte 22
View
Marc Laporte 21
View
Marc Laporte 20
View
Marc Laporte 19
View
Marc Laporte 18
View
Marc Laporte 17
View
Marc Laporte 16
View
Marc Laporte 15
View