Should an InnerSource Program fall within OSPOs?

[anajsana]

This topic was discussed at OSPOCon Europe during the OSPO Roundtable sessions. I'd love to see more testimonials or thoughts about this idea from other folks working at OSPOs (or thinking about building one) 👍

[jsmanrique]

Very good question indeed. Of course, both topics are related, but there are also big differences in how organizations face open source and innersource.

First, what goals does the organization wants to achieve with open source and innersource?

If the goals are related to having a more collaborative software development culture, fostering the sense of "community", or retaining talent (AKA "knowledge"), definitely both "innersource" and "open source" strategies could be aligned and managed by the same "office".

But they must keep in mind that both approaches (open source and innersource) have different scopes, different requirements, different needs to work. How you manage expectations about them is key to ensure success. One recommendation I've heard a lot is that "innersource" is a good "first step" into "open source". And I agree with that, but "open source" is already happening in organizations, so perhaps whatever is already being done on "open source" in an organization, is also a good "first step" into "innersource" :-D

Just my humble opinion or thoughts.

[LawrenceHecht]

So, OSPOs can be a good 1st step towards the innovation that InnerSource can provide?

[sicot-f]

Open-Source is more public and there is more at stake. I used to think that InnerSource was kind of a mandatory step to improve the code quality and increase developers maturity to this way of working before going open-source to avoid reputation backfire. But The 5 top myths about inner source changed my mind.

In this Microsoft Build 2020 video, Martin Woodward shows how Microsoft actually improves their internal software development practices when engaging with open-source communities. In doing so, you are working with people who have different deadlines and priorities, work in different timezones, have different culture background and communication style... which is also the case in a big company like Microsoft. Contributing to open-source actually helped them implement innersource.

So I agree with @jsmanrique : it's not one, then the other. It can work both ways. It depends on the teams' maturity levels and company size I guess.

[byjrack]

Feels like any team asking that question needs to confirm what their goals of the IS program are and how success will be measured.
And if your OSPO is chasing compliance or legal challenges than the IS strategy can get buried.

I would also suggest make sure that that contributor mindset is already a well understood pattern internally. If teams stop at reuse of internal works through a portal or discovery taxonomy, but have no desire to break down silos or promote the dialog between teams it can really turn off associates from the program in the long term.

Having a coherent strategy around collaborative development may need your to align to reporting structure, but you will need to be intentional about that structure to match your personal goals.

[rrrutledge]

I think they're peers/siblings. It makes sense to think about them in the same part of company collaboration strategy, but you don't necessarily have one that is contained within another.

[rrrutledge]

They're both ways to foster engineering collaboration and reuse via code. There are other mediums of collaboration as well - getting engineers to speak to one another and to write for one another. Oftentimes these simpler activities can facilitate and prepare coding together. They are all mediums for people not in the same organization to work together, and we want to make it easy to do both inside and outside the company. Thinking about it along those two dimensions produces these six program areas that make sense to think about holistically as part of your company collaboration strategy.

	Speak	Write	Code
Internal	Tech Talks	Internal Blog	InnerSource
External	Conference Talks	External Blog	Open Source

[DuaneOBrien]

I think we've framed the question the wrong way, and I'd challenge us to think this one the same way we think about where to put an OSPO.

When the OSPO lives in Legal, the OSPO will be informed and constrained by Legal's goals. When the OSPO lives in Marketing, the OSPO will be informed and constrained by Marketing's goals. When the OSPO lives in the CTO's office, the OSPO will be informed and constrained by the CTO's goals.

When an InnerSource Program lives in an OSPO, one of two things is probably true:

• The InnerSource Program is informed and constrained by the OSPO's Goals
• The OSPO is now something bigger than an OSPO and should be called something else

Broadly, I think in most cases it makes sense for the Open Source Program and the InnerSource program to roll up to the same person. But hesitate to say an InnerSource program belongs in an OSPO - I think that's leads to a dilution of purpose for both programs. If your organization is large enough to care about both, staff them independently. If it's not, then be explicit about the expectations and scope of the person running both programs, so that they can deliver effectively.