OSPOlogy Follow-up: 3rd Party Outbound OSPO

[anajsana]

Discuss with the community topics related to the upcoming OSPOlogy meeting:

📅 May, 11th 3rd Party Outbound OSPO: An extrospective approach to OSS

In this open space, people can:

• Ask questions prior to the meeting starts
• Share notes from the conversation
• *Make proposals for new initiatives that can help the OSPO Ecosystem
• Add useful links and resources related to the topic
• Connect with mentors involved in OSPOs and/or Open Source Management

[anajsana]

➡️ SECTION 1: OSPO News slides for the meeting are available here

➡️ SECTION 2: @jlprat presentation's available here. You can also download it as pdf.

📝 Also, people can download the pdf version.

[vielmetti]

This is an excellent presentation, which I really appreciate and which I will share internally with my OSPO.

[anajsana]

Awesome! FYI: The recorded version will be published tomorrow via the OSPOlogy youtube channel 🙂

[jlprat]

Thank you @vielmetti! Happy that you found it useful!

[winterrocks]

Q: how to select the projects to contribute? Any best practices? An organization is likely using thousands of OSS components, from which hundreds are likely crucial and the organization may have just 10 or even less it can concentrate on.

[jlprat]

That is a great question.
We have the Criticality Score but the do not take into account the "fragility" of the project. As in, how "possible it is that these projects might fail".
If we would have this "fragility score", then I would try sort the OSS components by this criteria and work on the top ones.
As we don't really have this scoring, I would say the best thing is to either use the criticality score or guesstimate what projects might be more crucial to the company's infrastructure.

[winterrocks]

"Fragility score" project could be something we could think of.
Earlier I was thinking that it would be nice to have an automated OSS project radar (kind of tech radar), but a fragility score may be even more useful.

[anajsana]

Q: Do you think that those orgs who are just doing inbound oss should at some point become outbound OSPOs too and don't be considered as siloed types, but as a journey? I see this type of OSPO the ideal persona where many inbound OSPOs might like to achieve in the long term? That is, ensure sustainability and secure the future os oss infrastructure.

[jlprat]

I can completely imagine some Inbound OSPO's transitioning to a more Outbound OSPOs, but in the end it depends on the team and company's capacity.
Also there are no pure Outbound OSPO's, any Outbound OSPO is also an Inbound as well up to some extent.
Our vision is that this subtype of OSPO's (Extrospective, or 3rd party Outbound) are a nice way to achieve long term sustainability of OSS projects.

[vielmetti]

Request for comment: If a project task is critical, time zones can be very relevant - especially if you have the opportunity to "follow the sun' and can get OSPO coverage in Americas / EMEA / Asia-Pacific, you can potentailly keep an issue in focus 24/7 for as long as necessary.

[jlprat]

Yes, ideally it would be good to have contributors in OSS projects in a "follow the sun" fashion. I can say this is most of the times aspirational. But being (as a team) in multiple time zones has its benefits and its disadvantages.

[winterrocks]

Q: If an OSS project is one of the crucial ones for the organization, but the project is toxic, how one can get the developers to contribute in these cases?

[jlprat]

I guess we need to ask ourselves a couple of questions as well, does it make sense to depend on this project on the first place? Sometimes the answer is yes, this project is crucial, then I guess it's matter of evaluating if this toxicity can be fixed. If this is not the case, then we can always think about joining other people (maybe other Extrospective OSPOs) in creating a fork without the toxicity.