Loading...
 

History: Constructive Cost Model COCOMO

Preview of version: 66

Constructive Cost Model (COCOMO)

WikiSuite is the most comprehensive and integrated Free/Libre/Open Source enterprise software suite, 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. And you are warmly invited to join!

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


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 Wiki CMS Groupware 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 Wiki CMS Groupware.
  • 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 :-)

Conclusions

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 114
View
Marc Laporte 113
View
Marc Laporte Adding an image for Tiki dependencies 112
View
Marc Laporte 111
View
Marc Laporte 110
View
Marc Laporte Tiki's direct dependencies bring it to over 100 million! 109
View
Marc Laporte 108
View
Marc Laporte Link to GitLab instead 107
View
Marc Laporte Adding Manticore Search 106
View
TSHITENG BENITO 105
View
TSHITENG BENITO 104
View
TSHITENG BENITO 103
View
Marc Laporte Elasticsearch is no longer Open Source 102
View
TSHITENG BENITO 101
View
Marc Laporte 100
View
Marc Laporte 99
View
Marc Laporte https://www.btb.termiumplus.gc.ca/tpv2guides/guides/wrtps/index-eng.html?lang=eng&lettr=indx_catlog_a&page=9IYDvHKNiH6Q.html#:~:text=In%20an%20English%20document%2C%20when,US%24%2025.99 98
View
Marc Laporte 97
View
Marc Laporte 96
View
Marc Laporte 95
View
Marc Laporte Update URL 94
View
Marc Laporte 93
View
Marc Laporte 92
View
Marc Laporte Update as of today. Cost for commit went up 1$ :-) 91
View
TSHITENG BENITO 90
View
TSHITENG BENITO 89
View
Marc Laporte @Benito: I intentionally picked 50 and not more. And I explained in detail why. When you make major changes like this, please ask me first. Also, you did not update the value of $142 million 88
View
Marc Laporte 87
View
TSHITENG BENITO 86
View
Marc Laporte Putting Webmin and Virtualmin side by side since they come together 85
View
Marc Laporte Given Cyrus is not in Virtualmin, removing for now (Dovecot is in Virtuamin) 84
View
Marc Laporte 83
View
TSHITENG BENITO 82
View
TSHITENG BENITO 81
View
TSHITENG BENITO 80
View
TSHITENG BENITO 79
View
TSHITENG BENITO 78
View
Marc Laporte 77
View
Marc Laporte 76
View
Marc Laporte 75
View
Marc Laporte Wrong widget 74
View
Marc Laporte Promoting Cyrus IMAP as a top level project even though it's pretty embedded in ClearOS. Why? Email handling is so important. It's at the same level as Openfire 73
View
Marc Laporte Reduce promotion of Kibana because although it works, we increasingly do dashboards in Tiki, with better integration 72
View
Marc Laporte 71
View
Marc Laporte 70
View
Marc Laporte [Rollback by marc.laporte to version 66] 69
View
Marc Laporte 68
View
Marc Laporte 67
View
Marc Laporte 66
View
Marc Laporte 65
View