Skip to end of metadata
Go to start of metadata

Considerations on Software Sharing Prerequisities 

1. Topics to be addressed in Software Sharing:

  • Language issues (see Guidelines for developing multi-lingual software)
  • TCO (Total Cost of Ownership) considerations: share or make?

"Share or make": the alternative is similar to the known "make or buy" with the difference due to the absence of direct costs of acquisition.
"Make" alternative has the following features:
•  Can be customized according to specific requirements 
•  Can transfer specialized domain knowledge already built into existing systems
•  Can exploit any established skill sets in custom software developement
•  More suited for division-wide or fragmented applications

 The following are the reasons against the use of custom-made software : 
•  Time taken for developing software in-house is typically very long 
•  Retention of the IT personnel is crucial and difficult, especially in public bodies
•  Co-ordination between departments / groups is very difficult and hence integration becomes a  problem 
•  Dependency on platform and people is very high 

The features for "Share" solution:
•  Field tested software 
•  Reinventing the wheel for the same application avoided 
•  Best suited for enterprise-wide applications 
•  Incorporates best global  processes 
•  Acts as a change agent for business process reengineering 

Among the criteria normally used to choose whether to make or buy, there is also the richness of the functionality of the software: in our case this parameter is much less important, since NSIS often have similar inputs, the same classifications and the same output, so that the functionality of the tools are often very similar. Furthermore, the recent efforts of standardization of statistical processes make statistical processes (and consequently the tools functionality) of different organizations even closer .

In shared package TCO, on the other hand, you must also consider the cost of adapting the tool to your organization, so it is important to be able to assess the "closeness" of source and destination organizations needs. Possible development of customizations can, if returned to the community, improve the degree of adaptability of the package shared.

  • Economic issues: pricing Free/Costly, Special prices for public bodies?
  • Legal issues (licensing):
  • Open? Free (as in freedom)?

There are two main definitions of "free" and "open source" software. Free software were first defined by Richard Stallman (Free Software Foundation) who defined the four freedoms that a free software must respect:
Freedom 0: The freedom to run the program for any purpose.
Freedom 1: The freedom to study how the program works, and change it to make it do what you wish.
Freedom 2: The freedom to redistribute copies so you can help your neighbor.
Freedom 3: The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.

"Open Source" is a similar definition that put the accent on the code openness, i.e. on the chance to read the source code of the program. The Open Source Initiative gave a definition of "open source software" that is based on ten criteria:
1. Free Redistribution
2. Source Code availability
3. Derived Works allowed
4. Integrity of The Author's Source Code
5. No Discrimination Against Persons or Groups
6. No Discrimination Against Fields of Endeavor
7. Distribution of License
8. License Must Not Be Specific to a Product
9. License Must Not Restrict Other Software
10. License Must Be Technology-Neutral

As everybody can see the two definitions are very similar and the two organisations agree in many cases in judging on licenses. Recently other acronyms like FOSS (Free Open Source Software) and FLOSS (Free Libre Open Source Software) were proposed, but we think that they did not add clearness to the issue.

On the contrary should be underlined that the word "free" is used in the sense of "freedom" and not "for zero price". Both FSF and OSI agree that a free-opensource software can be sold for money. Often when companies pay for free-open software they pay for services related to the software, like maintenance, updates, assistance and not for the license.

  • Which license (GPL/BSD/EUPL/...)?

On the contrary to what one might think, also open software licenses has its own licenses, only that, unlike the licenses of proprietary software, are licenses that guarantee rights rather than deny them.

Open licenses can be divided into two main groups: the copyleft licenses, and the more permissive ones. The term copyleft (a pun opposite to copyright) indicates that the user has the duty to release any changes to the software under the same license (GPL is therefore define "viral"). The most common copyleft license is FSF GPL (Generic Public License): first released in 1989, the second version GPLv2, released in 1991, is the most common opensource license. The recent released GPLv3 is usually reputed to be too  restrictive, so that many projects (e.g. Linux) did not adopt it.

The more common permissive licenses are BSD, originally used for the Berkeley Software Distribution (BSD) Unix in the University of California, and the Apache license, released by the Apache   Software Foundation, the organization that manages the most used web server in the world. These licenses have fewer restrictions compared to GPL, and allow the use of the source code for the development of proprietary software as well as free and  open source software.

  • Which agreement on future developments?

Methods to manage product strategy and roadmap

  • Is there a legal owner defining strategy?

Who is the owner? The first one? The group? Do we need an owner?

  • Non-OSS re-usable software

Re-usable/sharable software is not limited to OSS although this catgory certainly represents an important part of it. For example public domain software, freeware or software subject to particular license agreement excluding them from the OSS familymay also represent opportunities.

  • Governance of shared software:
  • Developers guidelines
  • Support
    • who? legal owner/community
    • where? local/remote/web
    • paid/free? community/company?
    • Initial/following? long term?
    • bug fixing
  • Recovery of existing data/system:
    • Porting or upgrading the existing data and processes / rules
    • Important usage of standards for data migration
  • Training:
    • documentation (language)
    • training course availability - location
  • Platform dependency: prerequisites, evolution. Which platform? Operating System / Data Base Management System / Application server / Programming Languages / other middle-ware. Related licenses to take into account, Virtualization?
  • Estimated lifetime: similar to statistical process ones (5-10 years
  • Accessibility of configuration parameters and scripts: how to adapt the software to local needs

2. Hypothesis: Business Process Model is a prerequisite for Sharing?

Between Statistical Institutions: GSBPM + SDMX + CORA/CORE - other experiences:

  • Automotive : AUTOSAR (http://www.autosar.org/) (AUTomotive Open System ARchitecture) is an open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers and tool developers
  • Computational Biology: Software Sharing Policy (http://www.iscb.org/iscb-policy-statements/software_sharing) approved by  ISCB (International Society for Computational Biology) in 2008
  • Education: "Open Source Collaboration: Guidelines and Report of the Licensing and Policy for Software Sharing in Higher Education" (http://www.educause.edu/Resources/OpenSourceCollaborationinHighe/180613 ) (EDUCAUSE groups more than 2.000 educational institutions from all over the world)
  • Construction industries: The Associated General Contractors of America uses standards that will allow sharing of data and key information between different construction programs - agcXML  (very similar to SDMX, but licensed)  Software Sharing Standards could save Construction Industry $15.8 Billion

    3. Software Engineering principles from which follows the need of re-use
     

  • DRY - Don't Repeat Yourself (or Duplication is Evil (DIE): Every piece of knowledge must have a single, unambiguous, authoritative representation within a system
  • NIH - Not Invented Here: culture that avoids using or buying already existing products or knowledge because of their external origins
  • Reinventing the wheel : duplicate a basic method that has already previously been created or optimized by others
  • SSOT - Single Source Of Truth: practice of structuring information models and schemata, such that every data element is stored exactly once (e.g. in no more than a single row of a single table)
  • YAGNI- You Aint Gonna Need It: refers tot the practice of putting in all kind of functionality for future use. research has indicated that almost none of these options is ever used.

Add experiences from the paper "Enabling technologies and constraints for software sharing in large astronomy projects" (see attached pdf)
 

  • No labels

1 Comment

  1. Hi Carlo,

    this looks good so far. I would suggest adding the following under 'Advantages of Software Sharing':

    • Savings in time and money in re-using or adapting an existing technical solution to meet another organisations processing requirements.
    • Sharing new features developed by one of the collaborating parties by the other partner(s) at minimal cost.
    • The use of common shared systems can promote and enable the use of statistical standards, both in structure and content. As an example, SIS components widely use the Statistical Data and Metadata Exchange (SDMX) standard as inputs and outputs.
    • Using the same software platform for statistical data management makes the exchange of data and metadata easier between organisations and can facilitate the production of joint data collection or dissemination exercises between organisations.
    • Collaboration between organisations in this way sends a very positive message to stakeholders that we, as publically funded bodies, are making our best efforts to efficiently use resources by working together and not duplicating effort in re-inventing the wheel.

    We could also perhaps include something about functional requirements - if the shared/free option meets more than 80% of requirements (but not 100%) it is still a better option than developing from scratch.

    Regarding governance we (OECD) had long discusisons about how to manage this with our collaboration partners. Despite the clear advantages of having organisations collaborate on projects to share software, such joint ventures can result in the increased complexity of project management depending on the role of the various partner organizations. We reviewed how partnerships with other organizations could best be managed and explored the different options ranging from the most complex (consortium of development partners) to the most simple (single agency coordinating development activity and distributing code) along with all the options in between (cooperation agreements).

    Collaboration is now based on a collaboration community approach with the OECD coordinating development and prioritising new features. The agreement is based on a standard Memorandum of Understanding.

    Best regards

    Trevor