We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

OSPOs: Key Lever for Open Source Sustainability

00:00

Formale Metadaten

Titel
OSPOs: Key Lever for Open Source Sustainability
Serientitel
Anzahl der Teile
38
Autor
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Enabling continuity in executive support, funding, software development practices, and OSS project prioritization. Within organizations, Open Source Program Office’s role can include setting code use, distribution, selection, auditing, and other policies, as well as training developers, ensuring legal compliance, or promoting and building community engagement. OSPOs bring many benefits to both, the open source ecosystem and organizations in equal parts, yet sometimes, the path to follow is unclear. During this session, Ana will share a set of actionable tips based on the TODO community learnings that any organization can implement to start building their Minimal Viable OSPOs, as well as ways to overcome the ongoing challenges ( culture, tooling, process, and continuity). This talk welcomes any open source professional, CTO, or executives willing to catalyze their organization's open source operations and become better citizens in the open source development community.
31
Open SourceObjekt <Kategorie>ComputeranimationVorlesung/Konferenz
Open SourceInstantiierungEinsMomentenproblemMultiplikationsoperatorAdressraumVorlesung/Konferenz
Open SourceVektorrechnungMagnetkarteKette <Mathematik>DistributionenraumSystemplattformVektorpotenzialProjektive EbeneOpen SourceMagnetkarteForcingDefault
SondierungProjektive EbeneCodeOpen SourceService providerComputeranimation
ProgrammSoftwareOpen SourceOpen SourceSoftwareOrtsoperatorSoftwareentwicklungExogene VariableExistenzsatzProgrammierumgebungComputeranimation
Open SourceDifferenteTelekommunikationDifferenteSoftwarewartungNichtlinearer OperatorOpen SourceSelbst organisierendes SystemOrdnung <Mathematik>Projektive EbeneStochastische AbhängigkeitMessage-PassingSkalarproduktTelekommunikationGeradeComputeranimation
ProgrammFitnessfunktionOpen SourceOffice-PaketUnternehmensarchitekturSoftwareentwicklungDifferente
MehrwertnetzVirtuelle RealitätSelbst organisierendes SystemOpen SourceCodeDistributionenraumTermProzess <Informatik>EntscheidungstheorieMaß <Mathematik>SoftwarewartungDatenverwaltungSoftwareschwachstelleComputersicherheitOperations ResearchKollaboration <Informatik>Innerer PunktElektronisches ForumMusterspracheKontextbezogenes SystemInformationSoftwareEndliche ModelltheorieOpen SourceFormation <Mathematik>Rechter WinkelOrdnung <Mathematik>Strategisches SpielDynamisches SystemPunktMathematikEinsExogene VariableProjektive EbeneUnordnungSelbst organisierendes SystemTermProzess <Informatik>DifferenteNichtlinearer OperatorAdressraumMultiplikationsoperatorDatensatzt-TestBitMAPImplementierungMusterspracheGemeinsamer SpeicherZellularer AutomatSoftwareInnerer PunktCodeTwitter <Softwareplattform>ComputersicherheitFokalpunktSoftwarewartungOffene MengeRahmenproblemComputeranimationFlussdiagramm
Selbst organisierendes SystemFunktion <Mathematik>FokalpunktDatentransferStochastische AbhängigkeitDesintegration <Mathematik>Message-PassingExplosion <Stochastik>Prozess <Informatik>Eigentliche AbbildungStrategisches SpielEinflussgrößePhasenumwandlungOpen SourceDifferenteComputersicherheitFunktionalTermGarbentheorieRückkopplungTelekommunikationSelbst organisierendes SystemTemplateKollaboration <Informatik>WhiteboardProgrammierumgebungDatentransferFokalpunktMultiplikationsoperatorOffene MengeUmwandlungsenthalpieGemeinsamer SpeicherProjektive EbeneSchreib-Lese-KopfFlächeninhaltMessage-PassingOffice-PaketMAPPunktCASE <Informatik>InstantiierungIntegralRechter WinkelGrenzschichtablösungElektronischer ProgrammführerDiagrammComputeranimation
FokalpunktDatentransferStochastische AbhängigkeitDesintegration <Mathematik>Message-PassingExplosion <Stochastik>Selbst organisierendes SystemOpen SourceCMM <Software Engineering>Formale SpracheAnalysisÄhnlichkeitsgeometrieDatenverwaltungEreignishorizontProgrammOffene MengeSoftwareentwicklerMailing-ListeMaßerweiterungMetrisches SystemElektronischer ProgrammführerVollständiger VerbandUnordnungGruppenkeimInnerer PunktOpen SourceGruppenoperationDatenstrukturElektronischer ProgrammführerVerschlingungAnalytische MengeProjektive EbeneMetrisches SystemInnerer PunktAdressraumUnordnungEinflussgrößeAnalysisE-MailOffene MengeDatentransferTermOrdnung <Mathematik>CASE <Informatik>Exogene VariableSelbst organisierendes SystemDifferenteOffice-PaketUmwandlungsenthalpiePerspektiveSoftwareentwicklungDivisionFormale SpracheSchlussregelRechenschieberInklusion <Mathematik>Information EngineeringDatenanalyseMereologiesinc-FunktionHilfesystemDatenverwaltungKette <Mathematik>GrenzschichtablösungSoftwareentwicklerMultiplikationsoperatorWinkelRechter WinkelThreadComputeranimationDiagrammXML
Open SourceMultiplikationsoperatorVorlesung/KonferenzComputeranimation
Transkript: Englisch(automatisch erzeugt)
Yeah, so thank you everyone that is attending to my talk. Today's topic, what I'm trying to, oh, it's not working. OK, now it's working.
Today's objectives, or what I'm aiming for this talk, is to first give some examples of ways organizations are currently addressing open source sustainability, then deep dive more into the role of OSPOs and how they are or how they can support
open source sustainability. There are some community learnings and best practices. And finally, if we have time, spend some moments for Q&A and maybe an open discussion. Where are your thoughts on that? So let's get started. So how organizations can address open source sustainability.
I guess this is not a new topic for many of you here. There are many different ways. The most common ones that organizations usually start addressing open source sustainability, that is not the main one. Oh, OK.
It's providing funding. There are great initiatives that has been happening within organizations. For instance, I think it was last year, PIR was somewhere else, but they started the
Participy Contributor's FOSS Fund to maintain independent projects. Also, this comes from Indeed Contributor's Fund that they released many, many years ago. They already have a book on investing in open source defaults contributor fund that is addressing
all these challenges and how they implemented these contributor funds for organizations. And there are other great initiatives, like the GitHub sponsors. And those are already being used by organizations such as Stripe. I think Wolfgang also mentioned about the GitHub sponsor
in his talk with Mercedes. So there are many ways organizations can start providing funding. But that is not all. They can also provide contributor contributions coming from these employees or internal teams within the organizations and infrastructure
to help those open source projects. A fun fact that we discovered in the last TOSPO survey for last year, 65% of organizations that frequently contributed code upstream have formally structured a NOSPO. We will deep dive more into that.
But another way that organizations can help out with this open source sustainability is integrating open source within the organizations and adopting open source best practices. This way they don't harm the environment, the open source systems,
and they know really how to contribute in a healthy way. One of the other insights we found out is the 80% of respondents say their organization's program has a positive impact on software best practices for those organizations that had the OSPO.
So in a nutshell, there are different ways organizations can have open source sustainability. These are some examples, there are many more. But it's true that there is already, there is also a complex ecosystem happening and going on. It's not just a direct straight line.
There are maintainers, contributors, independent projects, foundations, umbrella projects. So different open source actors, different ways to operate, different communications channels. And sometimes the message is not well transmitted. Even the organization doesn't get to hear the message
for many of those open source actors. So if this works, if, no. Okay, so.
So with the OSPO, the OSPO can be doing many different things, but at the end of the day, I like to call, to say that the OSPO cleans up the mess and the organization and connects the dots, puts everything into order, clean up the staff,
organize and make sure that the message is transmitted in both ways. So now we're gonna get deep dive more into OSPOs and how they can be helped to address this open source sustainability. But before continue some important considerations.
Know OSPOs are alike. So your OSPO is not my OSPO and this is not like a, yeah, this is how use will be implemented on OSPO. Well, we've seen OSPOs in the public sector works different at OSPO and the enterprises and so on. So don't take that as a standard way,
but as a different practices to maybe get inspired and implement and adapt to your needs. OSPOs can vary in sector, region and organizational side. And some of them might call it differently. Like we have seen many of them call it open source office
because program, well, it doesn't fit in their organizational values. And that's totally fine. And I will say that even in this conference, we've seen the term OSPO popping up many times as an entity.
As this design place is like a center of competency of open source operation. But in my today's talk, I want to give a different perspective and see if this clarifies a bit the things and start thinking about OSPOs as a role.
Cause there are many different roles that can happen within the OSPO. It's more like an umbrella term. And this can take this different responsibilities on implementing the strategies, the policies, the processes and put this order into all chaos
on open source efforts. And not only that, but also making sure that the organization has the right tool and processes and education and knowledge to start giving back to open source and beyond. And the OSPO can take many different,
the OSPO walls can take many different skills or responsibilities. The first one we can find is the enabler. So this is basically focused on educating the different teams in the organization and helping to navigate all the cultural process
and tool changes that are required for the organizations to shift from the open source dynamic. Now, sometimes it's quite, might be quite hard for some organizations, more easy for others, but at some point there's need some kind of
change in the mindset and the OSPO, there are some OSPO walls that can help on that. There's also the concealer. So this is more about, well, how can I, how can I? So what are the licensing issues? Where are the open source trends?
How should I be contributing code? Which open source projects? Which open source projects should I be contributing? And so on. So it's more about giving advice to the organization on how to operate in open source.
And of course, all this cannot work without motivation and advocacy. So of course we have the advocate role. So this OSPO role is more focused on motivating the different teams, not only the engineering team
on why open source matters, why it's important and why it benefits and why they will like to contribute back to the different projects and communities or even start ones. And the most important one for my, for this target list,
I will call it the environmentalist. So this is a role of more focus on addressing issues around open source security, like how to build more secure software, how to better maintain those open source projects
and how to address project health. So everything related with code review, with security management, with long-term maintenance and even funding or contributions. So these source proposals can ensure that the project remains healthy and benefits both
the organization, but also the open source community. And well, it's kind of clear that whether you have an OSPO or not, OSPO seems to be a good thing to have.
But sometimes it's not just about that. I've heard a lot of people in the community asking, well, yes, I understand the OSPO is important, but where should I start? Is it like, if I care about open source,
should I just start the OSPO or what? Where do open source and OSPO converge? To answer that, the organization need a previous assessment and start asking certain questions on,
well, what are we doing with open source? What does open source means to us? Because establishing the OSPO might not be the starting point for all the open source operations. And I've seen also this path in all the different tasks
from different sources, but it's about first thinking of where is my organization at in the open source journey. Like, are we using, are we actually contributing? Where and how are we contributing? Where and how are we using?
Where do we want to get, even though we are just using? Do we want, are we planning to have some kind of leadership and how are we gonna do that? So these kind of questions, when answering these kind of questions, the organizations will be assessing certain topics.
The first one should be culture. And when I'm saying this, because we are saying OSPO's popping everywhere, but the organizations might be more mature in open source or less mature in open source. And this is really relies on the culture,
asking questions such as, well, at the first point, is there actually a culture of sharing and collaborating in my organization? My organization, some organizations might have that, but others might don't. And also, are already open source actors within the organizations working in open source?
And how are they doing that? Or are they releasing open source? Are they don't? A great place to start might be inner source commons and thinking about adopting inner source principles. They have a great source that is called
the inner source patterns to implement inner source principles depending on different scenarios within the organization. Also another interesting topic will be to start asking about the level of knowledge and understanding
on open source that is happening within the organization. So are they understanding the benefits and the risk of open source? Are they familiar with open source licensing? Are they familiar with upstream contributions or not?
Another thing about the usage of open source software or OpenWorks, are they using open source in the organization? Where are they using open source or OpenWorks? And if those projects, if this usage of open source,
are they're being implemented in critical wide frames or in critical workflows within the organizations or not? Another thing, tools and processes. Are they processes and tools in place to actually contribute to open source?
Do they need to implement new ones to make that happen? And overall, it's all about addressing the gaps. The gaps that what the organization is on that starting point and what do they need
to start operating in open source dynamics in a good way. And once the organization have considered that and has been assessing this open source readiness, there might be one to take the next level and say,
well, let's start an OSPO or let's start think about implementing open source from office roles to start creating this public phase that will organize all in one place and will direct to the right people and communicate with them,
communicate the, sorry, no. And try to communicate the organization's message and the open source ecosystem measures and the different open source players. Because yes, in the long term, it might be more powerful.
Like when everything is organized with various processes and a strategy in place, it's less likely that the open source fails in the long term instead of doing open source ad hoc. But of course, we need to be very careful
because even though OSPOs are great thing to implement, it's becoming very trendy. And with trendy things, what happens is that, well, many organizations might say, let's implement an OSPO because everyone
is implementing an OSPO and they are not thinking of, well, how should we be implemented the OSPO? So here are some basic anti-patterns of an OSPO. So for instance, establishing the OSPO without proper alignment with the organizational goals. Well, maybe it starts well, but it probably will fail
because the organization is not gonna get value of OSPOs and of what they are doing. Maybe they don't know what they're doing. Treating the OSPOs as separate silo. That's why this communication, internal communication, not only with the open source ecosystem,
but also with the end organization is important. Treating the OSPO as legal or compliance function only. We get it. We know that there is a lot of dependencies and security risks, and this is really crucial. And many OSPOs was formed from the compliance section
or area, but if you only get stuck into that, the OSPO is not gonna be evolving. It's also time to take some step back and think about the cultural, the open source culture that is being infused in the organization
and the contributions and how they are addressing open source sustainability if they want the OSPO to evolve. And last but not least, viewing the OSPOs as a one size fits all solution. That it's really related with the OSPOs, not my OSPO. We cannot create a board template to build an OSPO
because every organizations might be different. And the previous questions I was sharing, it's a clear example of, well, depending on how they respond, the OSPO is gonna be operating different. So not handling correctly open source
in the organizations can harm the open source environment and same supply to not handling correctly in OSPO. So even though we don't have the answer for everything and there is no board template to build an OSPO,
I wanted to also spend some time in this talk to share some community learnings and best practices that I've been hearing from the Tudo community that it's an OSPO community of practice. And they've been sharing this world through guides,
through webinars, through open source projects and more, and enhances this public knowledge and collaboration on how they started the OSPO, how they are operating in OSPO, what are the challenges they are facing. And they're sharing this everything in the public because it's important for all the OSPOs to learn
and to also share their specific scenarios, specific challenges. The first point is, as I was mentioning, assess open source readiness before even starting the OSPO,
before thinking about anything else. Well, do I really need the OSPO? What is my level of engagement with open source in general? Because maybe there might be small companies, they are not even barely using open source. And in that case, well, maybe the OSPO
is not the solution. But if you start to assess these questions and you realize like, wow, I never imagined how much open source are we using, or even I wasn't expected that amount of engagement or people so motivated to contribute.
Well, that might be another story. Also assess OSPO readiness. So it's not just about, well, yeah, we know organization is really engaged in open source. How can we manage that in a better way? So what are the challenges, your opportunities of implementing the OSPO?
Because of course, OSPO, they have roles. You need to hire certain people. It's gonna cost you money. And it's important that the organization is aware of that. And also what do they need the OSPO to start working?
So what are the resources and the support that they need and make possible to provide those. The third point, focus on transmission knowledge. This is quite related with the,
not the OSPO working in a siloed team. So in the past years, I've seen many OSPOs that have started and then in one or two years they died. And the main reason was because they were siloed. They were just like an entity
and they were not transmitting the value of open source in all the areas of the organization. So there are different ways to transmit this value. So for instance, as an OSPO role, you need to report to the supervisor.
So what does my supervisor expects from the OSPO and from open source? What do they want? What do they want to hear? But also maybe I'm collaborating with all the teams, with legal team, marketing team, engineering team, what does open source means to them? How can I motivate them to contribute, not only technical contributions,
but not technical contributions? What does those teams find valuable? And maybe I'm the head of the OSPO and I need to manage all the people like maybe within the team or as contractors, whatever,
but what are they doing? What's my team doing? And how can I better manage that? And not only that, there's a fourth transmission knowledge that will be with this open source ecosystem, with these open source players.
And for that, an important question might be, well, what is the method of integration? Like how can I build these communications channels? How can I hear their feedback and how can I transmit the feedback from my organization?
And I think inclusive knowledge transmission is key and there are different ways of doing that. Most of that can come in the way of measuring because data, it's a global language. I will explain in my next slide. But since data is a global language,
it can speak different languages within the organization and outside. So through measuring the OSPO and the different OSPO roles can help to transmit this knowledge and this value.
This is not mine. This comes from one of the brainstorm ideas we did in another group to work on an OSPO book project and the people can of course take a look at that. And it was one of the emails threads that happened when we were discussing about this topic
on the transmission knowledge, in case you're interested. And as I was saying, data is a global language. So in order to have this transmission of knowledge, it might help to start thinking on including data science roles or data analysis roles
within the OSPO. This is a topic that we talk about in the last chaos OSPO working group, metrics working group and I thought it was really interesting like how some OSPOs were already starting to have certain roles related to think of data hygiene,
open source analysis or open source data engineering to put order into all this mess. And the last one, it's important to look at sustainability from both angles. So we've been discussing a lot on how OSPO roles
can address open source sustainability to help open source communities as well as the organizations. So that is a really important part, but also you need to think of how to make OSPOs sustainable
itself or OSPO roles sustainable itself within the organization. So this open source public person or group of people doesn't die in the long term.
And to end up with, here are some takeaways from my talk. The first one, it's basically more a question. So do open source actors know how to contact in your organization? If you ask this question, do you know that? Who is this public person?
Well, OSPOs are usually responsible of that, of being this public person where the open source ecosystem can contact them and also the organizations to ask them for certain advice on open source. Also think about fostering self-discovery
and by self-discovery, I'm not meaning on the person, but in the organization. It's important to understand how the organization operates, how the organization is addressing open source. What does open source means for the organization? And if they are completely lost on that,
how can I educate them to understand open source and start integrating open source in their day-to-day activities? And finally, think about open source transmission knowledge because it's not, of course it's important to think
about how to structure the OSPO, where the OSPOs will be reporting to and so on. But at the end of the day, if you want to maintain open source in the organization, it's more about how this person or this group of people
can transmit the value of open source and across different people that might be tech or they might not be tech and they might be speaking different language and they might be having different motivators. So it's a great responsibility and that's all.
So if you want to learn more of this community learnings that I've been sharing, these are some from the Tutu group. There are many other communities that of course are serving great value on how to contribute to open source projects,
upstream contributions, but well, this is what I've been involved at. So that's why I'm sharing the Tutu guides on how to create an open source program and so on. There is an OSPO 101 free course to getting started with an OSPO. There is a white paper on deep dive into open source program offices
that explains well the different structures of an OSPO, more focused on a corporate perspective, but well can help to get inspired in other sectors. And also we have OSPOlogy. It's not just webinars things,
but we try to invite people that are helping the OSPO community to talk about specific topics around open source program offices, sustainability, how they are being structured, initiatives they're developing and so on. And we are having these panel discussions every month.
And we are also having working groups. Right now the active working groups are divided into a working group that is working on the next OSPO guide. The OSPO guide that is based on open source, employee open source engagement, like how employees can contribute in a healthy way
to open source projects. There's also another working group on education to extend this OSPO 101 free course. And there is the OSPO metrics working group that is under chaos. That is another open source project focused on community health analytics
that is called the OSPO metrics working group. And well, if you scan that, it's just a link to the two dislike channel because everyone is welcome and you can join the community and say hi.
So saying that, just short story about myself. I'm Ana Jimenez Santa Maria. I was formerly working at Vitardia, that is a software development analytics firm. And there I gain a lot of knowledge on working with OSPOs and inner source organizations
from the metrics side and how to address value and measure open source health of the projects. I'm currently the OSPO program manager at Todo Group that it's a group of practitioners advocating and educating through OSPOs across organizations.
Three years ago is now, I always say I recently finished my master's in data science but no, it's been now three years. And I'm involved in other open source communities such as well as apology, chaos, inner source commons,
several collective and open chain. And that is my first one in case you want to follow me. And if we have time that I don't know, we do have time. So I would love to hear any questions you have and also make an open discussion on whatever you want to address during this talk.
Thank you. Thank you very much. Thank you.