Docstoc

LibECBUFR Open Sourc

Document Sample
LibECBUFR Open Sourc Powered By Docstoc
					        LibECBUFR
            and an
Open-Source Development Model
                      Ahmed Mulla
Applications Directorate, Chief Information Officer Branch
                   Environment Canada

         National CIOB/MSC BUFR Workshop
                         CMC
                     11 June 2008
                       Scope
   Provide background on free and open source
    software
   Address some specific approaches for
    LibECBUFR
   Provide a basis for future possible discussions
    amongst stakeholders
           Acknowledgements
   Open Source Roadmap version 1.0 by Julie
    Couet and Nicole Bois, Environment Canada
    (March 2008)
   Resource Allocation in an Open-Source
    Environment version 1.1 by Yves Pelletier,
    Environment Canada (April 2008)
     Free and Open Source Software
                (FOSS)
   More than no cost software licenses with access
    to source code

   “Free” in the sense of libre (freedom)

   “Open Source” defined in terms of distribution
    license
         Free Software Foundation
              Four Freedoms
1.   The freedom to run the program, for any purpose
2.   The freedom to study how the program works, and adapt it
     to your needs. Access to the source code is a
     precondition for this.
3.   The freedom to redistribute copies so you can help your
     neighbour.
4.   The freedom to improve the program, and release your
     improvements to the public, so that the whole
     community benefits. Access to the source code is a
     precondition for this.
                        GPL
   GNU General Public License (GNU GPL or
    GPL) embodies the four freedoms
   Copyleft: uses copyright law to grants rights to
    other people, in a way that ensures the rights
    cannot subsequently be taken away
   The GPL does not require release of modified
    software for private use
       Open Source Initiative (OSI)
        Definition of Open Source
   OSI acts as a standards body maintaining a
    canonical definition of open source
   “Open source is a development method for
    software that harnesses the power of distributed
    peer review and transparency of process. The
    promise of open source is better quality, higher
    reliability, more flexibility, lower cost, and an
    end to predatory vendor lock-in.”
            Some Key Features
      of the Open Source Definition
   Free redistribution in whole or in part including
    source code
   Modifications & derivations allowed with
    original terms of distribution – viral license
   License applies identically to all users
   License not dependent on software being part of
    a larger distribution
   License cannot restrict other software
    Participation in a FOSS Project
   Legal commitments depend on depth of
    participation
   Roles:
     End-user
     Developer
     Contributor
     Licenser of derived works
     Licenser of original code to a FOSS project

   What role(s) might your organization have?
                    Roles and Motivations

     Role               Motivation                    Considerations
End-user        Access to software with      •Quality of FOSS
                no licensing costs           •Legal e.g. liability

Development     Customization with no        •Quality

                licensing costs              •Legal   e.g. mixing licenses
Contributor     •Recognitionof expertise     •Protection   of intellectual
to FOSS         •Promote sharing burden of   property
                support                      •Reputation

Licenser        •Recognitionof expertise     •Legalliability
of derived      •Promote sharing burden of   •Reputation
works           support
Licenser of    •Recognition of expertise     •Legal liability
original       •Promote sharing burden of    •Reputation
code to a FOSS support                       •Loss of control unless
 project       •Third party improvements     properly resourced
      FOSS and GoC Background
   The Treasury Board Secretariat is responsible for the
    GoC policy on open source software
   “… departments and agencies base their decisions to
    acquire, develop and use software (including Open
    Source Software) on their business needs and the
    principles set out in the government's Federated
    Architecture Program”
   StatsCan reports about one-half of organizations in the
    public sector reported using open source software in
    2007
       FOSS and GoC Background
LibECBUFR addresses key principles of TBS Federated
Architecture Program used to assess open source
software:
   Reducing complexity and enabling integration to the greatest extent possible;
   Respecting government security, confidentiality and privacy policies and laws;
   Choosing solutions which use commercially viable standards-based
    technologies; and
   Ensuring that the total cost of ownership for applications and technologies
    balance development, support, disaster recovery and retirement costs as well
    as those of flexibility, scalability and ease of use/support over the life cycle of
    the application or technology.
                         FOSS and EC
   METRo
       Road forecast application
       In operational use since 1999
       Distributed under GPL
       Hosted at Gna! (gna.org)

   Meteorological Product Exchanger (MetPx)
       For use in industrial/government weather forecast
        operations, for exchange of meteorological bulletins over
        TCP/IP
       Runs at CMC
       Distributed under GPL
       Hosted at SourceForge.net
Legal Aside on Crown Copyright
   Even in an open source project
    Crown retains copyright for fifty
    years
   Contrasts with US where
    government products are public
    domain
   Some have argued for elimination
    of Crown copyright but that’s
    another presentation…
      Open-Sourcing LibECBUFR
             within EC
   Given historic fragmenting of BUFR libraries
    within EC open source effort will be cautious
   Initially will be limited to EC stakeholders only
   EC stakeholders are divided across business
    lines and physically dispersed. This makes the
    open source development model
    particularly well suited to LibECBUFR
    Many benefits of open source will
      still apply on a limited scale
   Pooling & sharing of dispersed resources &
    expertise
   Elimination of duplication of effort
   Focus on incremental value-added development
   Transparent management (oxymoron?)
   De facto standardization e.g. of API
   Peer review
   Quality audits of source code
        You don’t get something for
                nothing…
   Successful open sourcing of LibECBUFR
    requires dedicated resources.

   Specific roles include:
     Project management
     Stakeholder co-ordination and requirements
      gathering
     Lead developer and architect
               Progress to Date
   The WES Board Software Management Board provides
    governance for all MSC applications within EC
   LibECBUFR has already been approved for use by the
    SMB
   A submission has been made to the SMB to “open-
    source” LibECBUFR within EC; approval is pending
   SMB approval provides substantial official and moral
    support
    Transition to True Open Source
   True open sourcing of LibECBUFR is under
    consideration by EC management
   EC partners should evaluate the value of participating
    in a potential LibECBUFR open source project
   Interested partners should contact Yves Pelletier or
    Nicole Bois (Manager of External Relations, National
    Prediction Operations)
   For the purposes of this workshop LibECBUFR is just
    a teaching aid
Thank you for your time

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:12
posted:3/11/2012
language:English
pages:20