This year at FINOS we are focusing on one of FINOS' key existing projects: Open Source Readiness. This is FINOS' term for helping the finance industry "do open source properly". 

Open Source Maturity - ISPO versus OSPO

As organizations consider their strategic journey into Open Source Software, they address many of the areas we have been noting in our blog, such as

• Governance
• License Management
• Business Value 
• Security Considerations
• Training and Certification

All of these areas are foundational to Open Source readiness and developing your Open Source Program Office (OSPO). However, organizations may still be considering - or even hesitating - the big “leap” into contributing and maintaining Free and Open Source Software (FOSS), but still want to benefit from open collaboration and consensus developed features and capabilities. In that situation, all of these areas still apply for InnerSource - and the InnerSource Program Office (ISPO).

As we have learned through our 2022 State of Open Source in Finance Report and member surveys, many organizations, especially large ones, recognize the value in collaboration and development of software development, in lieu of additional commercial, proprietary licenses. However, we note that it can be a big cultural jump to embark on open participation and contribution to FOSS projects, even if for all other reasons they have formal policies and procedures for developing software that’s appropriate for public release. The ISPO model, and InnerSource, allows organizations to still capitalize on internal collaboration and develop software for their own business value.

The question then becomes do we need an OSPO and an ISPO? Is the ISPO always part of the OSPO, or should they be separate? Several of our members of the Linux Foundation have offered valuable feedback based on their experience:

• “ …we have both an OSPO and an ISPO, which are completely separate organizations. But other companies do their InnerSource activities within their OSPO”
• “A case for being in one: the OSPO might already be in a good position to operate both (services to engineering groups across the organization).... A case for being separate: depending on your needs you might have the ISPO aligned with dev tools or Agile coaches since they might be closer to the mechanical or coordination parts of InnerSource, while the OSPO could be aligned with enterprise architecture or governance functions.”
• “If InnerSource is seen as part of OSPO governance, then there are a couple things I think you should look at closely:
• Is the OSPO staffed appropriately to support InnerSource, or is it in the bucket with several others "Oh, can you also do this for us?" work?
• Is the InnerSource program where it needs to be in the organization to support the program's goals?
• Is the InnerSource program high enough in the organization that it's seen as important to leadership?”

As we further evolve the Open Source Maturity Model (OSMM), the concepts of ISPOs and OSPOs and how they relate will be a great area for further exploration.

Author: Jim St. Clair

Interested in this FINOS open source project, or any of our other projects? Click the link below to see how to get involved in the FINOS Community.