The Pillars of Open Source Software (OSS) Infrastructure

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

fetemadi's picture

Well, you have decided to enter the realm of Open Source Software (OSS), and you have heard all sorts of stories about OSS conflict with proprietary software (also known as IP software – as in Intellectual Property – or closed software) and you do have proprietary software to protect, of course.  On the one hand legal wants to make sure all angles are covered, on the other hand engineering wants to get the product out at the earliest, and lets not forget corporate IT which is questioning how OSS fits in the corporate infrastructure, and so on.

Who are the players in this infrastructure implementation and maintenance?  They are the OSRB and OSEC members.

Open Source Review Board (OSRB): members from various organizations involved with OSS amongst them engineering, legal, marketing, field, testing, etc. This is the functional body of any and all OSS related activities from technical to legal.

Open Source Executive Committee (OSEC): The overseeing body consisting of the executive level of various organizations within the company.  These are the executives overseeing the OSS activities and periodically addressing any potential disagreement amongst the OSRM members that may have short or long term business ramifications.

Here is a recommendation for a functional OSS framework. 

First some points to consider:

  • the development environment is a mixture of OSS and proprietary code – call it a Hybrid Source Software (HSS) and,
  • various organizations are involved in management and use of the hybrid environment such as engineering, legal, corporate infrastructure (IT), product management, sales, customer support. 

Well, whatever OSS component is part of the product development process; there are similarities and differences between it and the good ol’ proprietary.  So how to deal with this hybrid engineering environment is the focus of this blog.

The infrastructure required to manage the HSS consists of six major components (or pillars):

  • Repository
  • Source Code Control System (SCCS)
  • Code Analyzer
  • Task Manager
  • Collaboration Tool
  • Workflow Manager       

One will find similarity in the use of some or all of these components with standard proprietary software and we shall discuss how they differ in an OSS framework:            

In the rest of the article we use the term component, package, module interchangeably for the OSS.

The Repository

This is, in my opinion, the central part of infrastructure.  It consists of not only technical characteristics definition of an OSS module or package but also such other information as certificate of ownership (COO).

COO is a set of information that must be provided by the “component owner” - usually a member of Development.  

What degree of granularity to use for the repository information shall be decided by OSRB, however Legal and Engineering are the two most influential parties in defining the information structure.

How to maintain this info:  flat file, spreadsheet, or RDBMS are possible choices.  OSRB can decide what the most suitable implementation choice is.  The more complex the use of OSS in HSS, the more suitable is a tool with a sophisticated reporting scheme.  

Some may suggest that a Bill of Material (BOM) provided in a package may suffice the requirements of the repository, but the BOM usually lacks the COO information and must be augmented accordingly.

The Source Code Control System (SCCS)

If one already has a SCCS, then it can be used to integrate/incorporate the open source packages into one’s development environment.

If one is using an OSS bundle from an established distributor (Debian, Redhat, Suse), then one must decide whether to stay with their labeling scheme or use its own.  If not using a distributor package, then one must keep track of release information of all packages in the repository DB and create a label to package the hybrid code into a baseline for further development.  A typical SCCS would be sufficient (RCS, CVS, ClearCase, Subversion).

The Code Analyzer

There was a time that using a very senior Linux/UNIX engineer to evaluate the origin of a code in HSS might have been an option to verify that no licensing violation had taken place. From the old UNIX days with BSD licensing (which was quite lenient) to today’s GPL 2 and 3, the need for a sophisticated code analyzer is no more apparent.  There are a number of companies that provide the OSS analysis tool (BlackDuck, Palamida, and Fossology).

The Task Manager

To manage the lifecycle of any OSS package integrated into the HSS development, one needs to use a task manager to manage the integration lifecycle of each individual OSS component.  Sometimes a revised bug maintenance system can pass as a task manager to monitor the OSS packages integration lifecycle or one can choose to use a more sophisticated commercial task management system.  Many software tracking systems are available for this use.

The Collaboration Tool

A Wiki type used to exchange of information amongst all involved with any and all OSS/HSS packages.  If the IT is emphatic in using SharePoint and Engineering is using Wiki, then how to collaborate amongst this varying collaboration environment can be challenging to resolve.

The Workflow Manager

The approval process of the use of varying components is captured through the use of a workflow manager.  It can be homegrown (and manual, although not recommended) or a commercial product.  The intent here is to establish a workflow diagram for OSRB and OSEC to follow and for all involved to be familiar with the steps required to use an OSS in their organization.  OSRB is in charge of developing and maintaining the workflow activities.  

Finally, I am not promoting any particular tool manufacturer for the OSS/HSS infrastructure.  Each organization must evaluate and use the tool best suited for them.  The bottom line is that these features must be present in some form for the OSS infrastructure to function properly.

In the follow up articles we shall delve into each one of the OSS Infrastructure components in more detail.

tbm's picture

Interesting posting. The

Interesting posting. The only thing I don't like is your use of the term "IP software" to refer to proprietary software. After all, open source software has IP rights (e.g. copyrights and trademarks) too.
fetemadi's picture

"IP" point taken ...

Good clarification re: IP and Open Source.  I will make a note that Open Source has IP as well and refrain from "detaching" the IPness from Open Source.

---
Fred Etemadieh, CISSP, P.E.
Open Source Strategy, Governance, Architecture