Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Considerations on Software Sharing Prerequisities 

Panel

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
Panel

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

    Panel

    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)