The purpose of this page is to summarize the features characteristic for the already described examples of collaborative software development and to highlight the common aspects. As time progresses this page will be more and more evolve to an inventory of collaboration models and give insight to opportunities and constraints in future collaboration activities. The following paragraphs are the main attributes to consider when looking into collaboration projects.
Type of collaboration project.
Most projects are determined by the thing or things they produce and this is no different for collaboration projects. We see the following different types:
1.Software production (ESSnets from EU)
3.Architecture development (SDMX Reference Architecture by EUROSTAT, CORA by EssNet, etc.)
4.Standards development (HLG standards project)
5.Research (evaluations, applied research, methods etc. e.g. GIS by ISTAT)
Position in the GSBPM.
The Generic Statistical Business Process Model is establishing itself as a reliable tool for blueprinting the structure of the processes in the national and international statistical organizations and more and more organizations are adopting it for modeling their organization and production process (see Work Session on Statistical Metadata (Geneva, 10-12 March 2010)). Positioning the outcome of the project into the GSBPM will give a quick reference to its character and applicability in concrete situation. In summary, most of the known examples of collaboration projects consider the dissemination phase, some of them cover the data collection phase. The options are:
1.The project results are within the bounds of the GSBPM and can be positioned in one or more phases
2.Results can be placed in the GSBPM however not concretely in the currently defined phases.
3.The results fall outside the definition of the GSBPM.
License and licensing issues.
All projects have some form of tangible results and these results, be it standards, methodology, software or whatever need to be protected by some form of licence. An interesting analysis on this subject was published in the ESSnet Project CORA:http://joinup.ec.europa.eu/sites/default/files/CORA_deliverable4-1.pdf
Following licences are of interest:
1.GPL the Gnu Public Licence which in essence protect authors and users in the Open Source area.
2.EUPL the European Public Licence which is a localized version of the GPL in several languages. All software developed in EU collaboration projects is default under the EUPL
3.Creative commons, mainly in use for textual results.
4.Paid purchase or subscription model, the licence usually grants rights of usage and updates.(Blaise)
Third party licenses used
A vital question in reusing results is platform compatibility (Wintel/Linux/UNIX) and all the tools and utilities that normally goes with that platform and special licences needed. Will the former generally be unavoidable, the latter is to be avoided where possible. If the software or method needs a certain licence to be usable it can be an advantage to have alternatives, like several drivers for a number of database manufacturers etc.
Ownership and governance.
Where in-house custom made software and other types of project results most of the time have a clear owner, it is an issue in collaboration projects. Especially for the collaborative models that act as groups or consortia care has to be taken that responsibilities and ownership is clearly defined.
1.Community owned, no governance (this implies a lot of forking)
2.Copyright owned by the authoring agency but maintained by the community under governance of the owner
3.Copyright owned by the authoring agency and maintenance too but advised by a user community
4.Consortium owned and maintained where a contract between two or more partners defines the agreement.
5.Ownership and governance delegated to a governing body like UNECE
Where and how is the software (or other deliverable) available. Most of the time the collaborating partners act as suppliers. For the Open source projects the repository where the software is located (Source Forge or OSOR or Google Code or similar) is seen as the supplier. The delivery and availability of the products can be.
1.At one of the open source repositories like Joinup or github
2.At the authoring agency on request
3.Using a commercial reseller
4.From the website of an international institute like the UNECE
Development and initial funding.
In most of the considered cases the initial funding and the execution of the project were carried out in one organisations. Consortia that create something or built software are relatively rare in the statistical world. An exeption is the so called ESSnets were a number of collaborating countries of the EU work together in UE funded projects. Constructions with venture capital or loans etc. are non-existent in the official statistical world. Funding models are:
1.Single party, mostly the owner and author
2.Consortium with funding of participating agencies
3.Consortium with extra funding from external party like EU ESSnets or UNECE HLG projects
For tools and standards an active user community is great importance. In most cases it can safely be assumed that the more successful a tool is the larger and more active the user community will be. Normally the user community focusses on the use of the product e.g. tips and tricks and exchange of knowledge of the product. Possibilities are:
1.User community supported by authoring or governing agency
2.Independent user community
3.No user community
Sustaining (maintenance and further development).
The sustainability is the main problem of most collaborative and Open Source projects. Usually funds are obtained for the initial development, the software is successfully developed and then either released as open source or provided for usage free of charge for related (member) organizations. A typically successful Open Source project (like R or Octave, to mention a few) would accumulate a critical mass of developers who will actively contribute and provide means for maintenance, further development and support.
In the world of statistical software this is rarely the case since the "market" is limited. Therefore other mechanisms are needed for funding the maintenance and further development of tools released as open source. The possibilities are:
1.Initial developer is primary user and committed to sustenance
2.The licence is a paid licence and the fees are used for development
3.There is a multi-party agreement in place for long term sustenance
4.There is a developer community contributing in the case of open source
Support, Documentation and Training
Is most of the time closely related to sustenance although for the really successful software commercial entities also start to provide training and support for a fee. The following modalities have been observed:
1.The authoring agency or consortium is the supplier of support/documentation/training.
2.The delegated agency like UNECE or Eurostat is supplier
3.Commercial entities supply training/documentation/support for a fee
4.The user community has an information hub and/or forum where self-help is possible
Risks and Issues
1.Funding of the sustaining of open source and other free software projects is a potential problem caused by the indirect nature of the business case. However looking at several successfull open source projects like Apache, Android, openGL, MySQL, Hadoop, and more it is apparent that as soon as a group of active users exist it becomes a common interest to fund development and maintenance.
2.Building and educating a user community has proven to be difficult for projects in small markets and may require additional stimulus from NOS’s. There are real opportunities there since NSO's have deliberate policies unlike single consumers.
3.Third party licenses: For maximum reuse, the use of imbedded products that need to be licensed separately should be avoided or alterantives should be supported like giving an installation time choice between different supporting systems like many products do.Another way to mitigate these problems is by using open source alternatives like R, MySQL and others for which no licence is needed.
4.Adherence to the multi language support guidelines for software development of the UNECE is beneficial for projects that are meant to be used by more NSO’s.
5.Platform (in)dependence is important not only because of the different platforms already available like Windows, UNIX and LINUX but also as a means in protecting the investment in the tool. Possible solutions are architectural like the splitting the GUI and the command-line engine as is common in UNIX and LINUX environments or using platform independent languages like java-script, more solutions are coming available every day.