Ultra Large Scale crowdsourced system

© 2009 Andrés Leonardo Martínez Ortiz. Some rights are reserved. This document is distributed under the ”Attributions-ShareAlike 3.0” Creative Commons License available here.

The complexity of (software) systems used in complex organization such as Universities, SME’s, Public Administration and Enterprises are rising over and over. For the next twenty years these system are going to grow up to billion of lines of code. These very complex systems are known already as Ultra Large Scale Systems (ULS Systems) [1] and their development, maintenance and evolution is critical.

It seems clear that we do not follow a traticional approach to develop this kind of systems. It could say that the software development has not improved enough to get scale economy. It does not exist anything like a Moore’s law of software development. In term of “The mythical man-month” [2], we have not solved the intrinsic difficulties of software development process yet.

For many people OSS (crowdsourced systems of software development) is the unique way to afford the development of USL System. Indeed in a recently essay [3]  the authors write down “the future of crowdsourced system will be community-driven and decentralized“. They introduce de Metropolis Model and propose a new life cycle of software development to build crowdsourced system.

Alhtough I share their aims I am not totally agree with the proposed solution because before some problems have to be solved:

• Open teams. It is needed mechanism to collect the knowledge, foster their development (economically but not only) and distributed it taken into account economical, priority or whatever schema.
• Mashability or reusability. It is needed a technical and organizational interoperability. Also sharing code can erased the incentives, again not only economical, to develop software. And finally the reusability can conflict with “tech fashion” and with large life cycle of the software development.
• Conflicting unknowable requirements. From my point of view the main difficulty is to let no-technical requirement and to define how should live ones each others.
• Continuous evolution. It is clear that huge systems are never ending systems but perpetual beta should not be confused with un trusted solution. This is critical for the adoption of crowdsourced system in industrial solutions. In this case the solution should be based on a deep knowledge of the software and its features.
• Unstable resources. Once again, the authors talk about success cases but they do not explain how to get resources enough to produce system on time and with a set of prefixes features.
• Emergent behaviors. As the authors confirm “once the crowds are invited in, determinism is lost”. Clearly this is not a valid option in many situations. A consolidation process has to be defined to extract quality emergent pieces of software or features from no deterministic crowdsourced system to a more deterministic industrial-like environment.

From my point of view the authors fail using a positive approach (in sense of positive economic vs. normative economic [4]) that is able to explain “what is” but not how it can be build. Nowadays it is very difficult translate the experiences obtained from conventional communities to crowdsourced system able to afford ULS development. Besides the authors exclude of crowdsourced systems some critical parts such as architecture and let them under responsability of “experienced [and] motivated team …”.  Once again if these parts are themself ULS how can they be developed? There are still some open questions related with ULS crowdsourced systems:

• Can the industry wait to the results of good crowdsourced communities just happen?
• How can we drive these good results?
• How can gathered “industrial” crowds around projects of their interest?
• Can we reuse the traditional community model?

A lot of  open source projects without communities are known. A community is not built just releasing software with GPL. A ecosystem is needed. We already have the name  but we have to learn to build these open source ecosystem. Don’t forget that the tragegy of the commons is not solved yet. In other words which would be the reality of the software if people do not have economical incentives to develop it?.

Definitively, I think that the experience extracted from Mozilla or Apache communities are not good examples to apply to ULS crowdsourced system. It is the tragedy of long tail curve. These communities have a lot of beneficial features but we do not know exactly why and how do it again with new projects.

Unfortunately, the Metropolis model do not offers a realistic approach to build crowdsource system. The authors introduce a very generic indication about crowd management, two level requirements or architecture and some buzzwords more. Besides that, the existence of a “closed-knit, highly motivated [and] coordinated team” seems to be a back door where locate all uncovered issues. Another typical topic is “the passion” needed to program but what happens when nobody feels passion to a specific and critical piece of software. Again we do not wait just things happen.We have to define mechanism to get things happen.

In conclusion, the ULS systems probably cannot be afforded by a single (although huge) organization. It is need deep in organic organization of complex system but we do not wait to things just happen. We will provide a constructive solution taken into account what will be the future uses of the software systems.

References:

[1] Ultra Large Scale System: the software challenge of the future. Ed: Northrop L. Software Engineering Institute. Carnengie Mellon University.

[2] The mythical man-month. F. P. Brooks. 1975 Addison Wesley.

[3] The Metropolis Model. A new logic for the development of crowdsourced systems. Kazman R. and Chen H-M. Communications of ACM. Vol. 52, No. 7 July 2009.

[4] Positive Economics. Wikipedia July 3rd 2009.