(Re-)using OSS

From Earth Science Information Partners (ESIP)
Revision as of 15:31, January 4, 2012 by Jesse Roberts (Joroberts) (talk | contribs) (Created page with "<big>Realizing the Benefit of (Re-) using Open Source Software</big> :'''Time:''' 2:00-3:30 :'''Location:''' Mt. Vernon :'''Convener:''' Chris Mattmann ==Action Items== ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Realizing the Benefit of (Re-) using Open Source Software

Time: 2:00-3:30
Location: Mt. Vernon
Convener: Chris Mattmann

Action Items

  • Communicating and Publicizing NASA’s OSS efforts
    • NASA Open Source Agreement license - NOSA
      • Do we need yet another license? Which one do we pick?
  • Public dollars funding non-OSS projects?
    • How do we navigate the legal morass of subcontracting and third-party hardware/software reliance?
  • Agency rules may stifle OSS development
    • New Technology reports, on-the-clock vs off-the-clock OSS development
    • Budgetary rules
    • Budget, reporting, long-term support requirements
    • Cultural change needed, toolchain retooling


Key Topics

  • Areas for Open Source within NASA/Earth Science Data Systems
  • Data flow from instruments to end-users and archival centers
    • Where should OSS be, where should it be produced?
    • What license is best? Custom? NASA OSS? Existing BSD, GPL, etc?
      • Redistribution, attribution, IP, commercial use, etc.
      • Ownership of original code vs submissions
        • Who’s dollar supported the code development?
        • What employer/employee contracts might impact release of code?
        • Uncovering (potential) patent infringements or marks, mitigating exposure
        • Free, in-house use only, commercial or export-controlled/classified?
      • Who can claim ownership?
        • Hardware owners, developers, contributors, etc
  • What kind of OSS?
    • In-house developed, non-supported, vendor-supported, non-OSS commercial software with OSS parts, some combo?
    • What are your support requirements? Can you navigate poor code or documentation? What support can you afford?
      • Risk-cost-benefit analysis needed
      • Is there an active community supporting your software?
        • If so, is it an oligarchy or a meritocracy?
        • What mechanism connects end-users with code developers?
      • How do I support the software?
        • Not just code submission - documentation, bug reports, feature requests, review of features, support within the community for novice users, etc. Even just adopting and promoting it!
  • What ecosystem will your OSS project live under?
    • What are the ecosystem rules? (Apache Maturity Model, eg.)
    • Will you control your own ecosystem?
    • Testing? Documentation? Patches and Bugfixes?


Contributions

  • Chris Mattmann
  • Robert Downs