InnerSource and OSPOs: Institutionalizing Open Source Culture Change
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 39 | |
| Autor | ||
| Mitwirkende | ||
| 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 | 10.5446/67238 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSS Backstage 20228 / 39
2
9
11
15
26
30
36
37
00:00
Open SourceOrdnung <Mathematik>DatenverwaltungProgrammierumgebungWeb SiteRechter WinkelKollaboration <Informatik>Projektive EbeneGüte der AnpassungSoftwaretestOpen SourceÄhnlichkeitsgeometrieGruppenoperationUnternehmensarchitekturPatch <Software>Offene MengeDifferenz <Mathematik>MultiplikationsoperatorHyperbelverfahrenInnerer PunktMetrisches SystemAnalytische MengeApplett-TestSoftwareProzess <Informatik>Office-PaketTransformation <Mathematik>ProgrammierungBitSelbst organisierendes SystemSoftwarewartungKontextbezogenes SystemPhysikalisches SystemBestimmtheitsmaßTwitter <Softwareplattform>TermSchnittmengeKontinuierliche IntegrationGrundraumTouchscreenSoftwareentwicklerMathematikEntscheidungstheorieUnrundheitPuffer <Netzplantechnik>QuellcodeProgrammfehlerDiagonale <Geometrie>DatenflussPunktMereologieBesprechung/Interview
08:11
TermProgrammierungMultiplikationsoperatorGarbentheorieIntegralSoftwareentwicklerAggregatzustandOpen SourceGruppenoperationDifferenteKollaboration <Informatik>Offene MengeMAPSondierungBeobachtungsstudieUnternehmensarchitekturEndliche ModelltheorieMereologieSoundverarbeitungKontextbezogenes SystemBasis <Mathematik>MusterspracheVollständiger VerbandFeuchteleitungBenutzerschnittstellenverwaltungssystemt-TestProgrammierumgebungRegulärer GraphSystemaufrufEntscheidungstheorieTwitter <Softwareplattform>BitCMM <Software Engineering>Selbst organisierendes SystemRechter WinkelPunktGoogolInnerer PunktOffice-PaketObjekt <Kategorie>QuellcodeMixed RealityInteraktives FernsehenGrundraumBesprechung/Interview
16:18
Selbst organisierendes SystemDifferenteOpen SourceKontextbezogenes SystemProjektive EbeneAuswahlaxiomEinfache GenauigkeitPunktFunktionalRechter WinkelMusterspracheProgrammfehlerCodeEndliche ModelltheorieInnerer PunktFormation <Mathematik>MinimalgradSpieltheorieNebenbedingungRegulator <Mathematik>Transformation <Mathematik>Elektronisches ForumSoftwareentwicklerTermNichtlinearer OperatorAutomatische HandlungsplanungProgrammierungVerkehrsinformationImplementierungMultiplikationsoperatorStreaming <Kommunikationstechnik>Physikalisches SystemFeuchteleitungKollaboration <Informatik>Offene MengeMAPNP-hartes ProblemHilfesystemInterrupt <Informatik>SchedulingMereologieMathematikQuellcodeExplosion <Stochastik>Besprechung/Interview
24:24
RechenwerkSoftwareentwicklerSelbst organisierendes SystemRelativitätstheorieWärmeleitfähigkeitInstantiierungUnordnungCodierungInklusion <Mathematik>Quick-SortDifferenteMAPProjektive EbeneOpen SourceInnerer PunktMetropolitan area networkMereologieUmsetzung <Informatik>BitOrtsoperatorPunktKollaboration <Informatik>Kontextbezogenes SystemTermRegulator <Mathematik>Inverser LimesGruppenoperationSichtenkonzeptSpannweite <Stochastik>Message-PassingElektronischer ProgrammführerMustersprachePhysikalischer EffektAusnahmebehandlungRechter WinkelNormalvektorSystemplattformBesprechung/Interview
32:31
ComputerarchitekturMereologieSchlussregelAbgeschlossene MengeFokalpunktMAPHinterlegungsverfahren <Kryptologie>RichtungGruppenoperationKollaboration <Informatik>ProgrammierungPortscannerMathematikSelbst organisierendes SystemInterface <Schaltung>Gemeinsamer SpeicherOpen SourceDifferenteFormale SpracheMinkowski-MetrikFeuchteleitungCodeCodierungDigitalisierungZahlenbereichOrdnung <Mathematik>DokumentenserverApp <Programm>ForcingPerspektiveComputersicherheitProzess <Informatik>Innerer PunktSoftwareentwicklerEin-AusgabeDatenstrukturElement <Gruppentheorie>TermBridge <Kommunikationstechnik>Office-PaketFirewallLesen <Datenverarbeitung>Mobiles InternetNeuroinformatikPackprogrammOffene MengeQuick-SortBenutzeroberflächeComputersimulationBetrag <Mathematik>DatensatzBenutzerfreundlichkeitBesprechung/Interview
38:17
YouTubeSoftwareentwicklerInnerer PunktVerzweigendes ProgrammElektronischer ProgrammführerMultiplikationsoperatorVerschlingungWärmeübergangSystemaufrufKontextbezogenes SystemProjektive EbeneOffice-PaketAdditionCodeSoftwareOpen SourceProgrammierungInstantiierungSelbst organisierendes SystemHilfesystemWeb-SeiteUmwandlungsenthalpieComputerarchitekturFormale GrammatikProzess <Informatik>EinsMailing-ListeE-MailGoogolPatch <Software>SichtenkonzeptQuellcodeGemeinsamer SpeicherCMM <Software Engineering>Güte der AnpassungBenutzerbeteiligungBesprechung/Interview
44:46
Open SourceComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:05
So, hello everyone and welcome to our panel session on Inner Source and OSPO's institutionalizing open source culture change. I'm delighted to be here with you today on this very special day in Ireland. So hello from Dublin, Ireland and happy St. Patrick's Day. It's the reason that
00:20
afraid we can't be with you there live, me anyway, but we're still delighted to be here and now I will distract you for the entire session by wearing special St. Patrick's Day offers, but we'll go with that. We'll go with that. I'm wishing you happy St. Patrick's Day. So my name is... Oh, go on John. I feel very excited that I also don't get my special...
00:44
It's okay. We'll improvise, but I just... We'll start today by doing a quick round of intro. So my name is Claire Dillon. I am the executive director in Inner Source Commons. I'm a member of the Open Source Program Office, which is a network for folks who are interested in
01:03
creating open source program offices in the public sector and universities and governments and things like that. And I will pass it over or in fact down to John. John Mark, would you like to introduce yourself? Hi. Yes, I am John Mark Walker. I run the open source program office at Fannie Mae and I've been involved in open source things for over 20 years
01:23
now. So yay. Sorry, let me pass it down to the... On my screen is to the diagonal left. I'm going over to Isabelle. Hi, I'm Isabelle. I'm open source strategist at Overpace. I'm also president of the Inner Source Commons and I've been involved with open source,
01:44
I believe since I left university back in 2003, 2004 maybe. When did you become a member of the Apache Software Foundation, which essentially taught me how to do open source right. And I will pass it on to Ana. Thank you. I'm Ana. I'm the to-do program manager.
02:06
There's a program manager at Todo that is an open group of organizations mostly based in the enterprise sector that runs open source program offices or similar open source initiatives for the past 12 years now, I will say. And I've been involved in open source from the last years.
02:29
My mentors from my former company that was Viteria, that is a software development and analytics firm. And from there, I learned a lot of inner source of open source program offices
02:42
and open source metrics and keep learning. Thank you, Ana. Thank you everyone. And thank you for joining us here today. We do have a fifth member of our panel, Tim Willoughby, who unfortunately couldn't be with us for this part, but we will be magically inserting his contribution at a later point in time. So he will be coming and joining our discussion later.
03:04
But for now, let's kick off with the first question of the day. And that is really why? Why Inner Source? Why Inner Source as a step on an open source journey? So would anyone like to take that first? We can break up the flow here. So would anyone like to go first?
03:20
I mean, I have lots of opinions, but yeah. Go on, get started, John. Let's hear why it is. So first of all, I have to talk about how I was very skeptical about the whole inner source thing. Like when it first appeared from Tim O'Reilly's brain, I don't know, some 20 years ago, I thought it was bogus and needed because of course everyone's gonna be doing open
03:41
source software. So why do we need this inner source thing? And then like over the years, I started actually working with bigger companies that have these challenges around collaboration. They have challenges around modernization and they've been doing all these agile transformations and DevOps transformations. And they're discovering that they don't have the
04:02
ability to easily collaborate with the external world. And so over the years, I've come around to the idea that inner source is actually essential to making the open source ecosystem work because in most of these companies, they simply don't have the process. Like they've been
04:21
told their entire lives that open source is dangerous, open source is risky. And so they just don't have the processes and they don't have the clearance to be able to collaborate easily externally. And so a lot of it comes down to how do we train and enable engineers to think like open source maintainers or contributors, but in an internal context.
04:44
And I feel like once we break that barrier and get a bit more people who are proficient at open source style collaboration, it becomes a much easier leap to go from that to external contribution and even like maintainership and launching new projects. It's really about
05:04
building out that set of tools and skills so that they're more comfortable in those environments. Brilliant. Thank you, John Mark. Isabel, you obviously are very involved in inner source commons as well. Are you seeing a similar set of trends in terms of the folks that you know of that have been implementing inner source formally through OSPOs?
05:24
So I see similar trends, but something that I would like to take a step back actually. When I introduced myself, I told you that I came to open source like in 2003 and 2004. So that was for me very early. It was right out of university. So out of university,
05:41
I learned how to do this asynchronous collaboration, like having everything transparent, having everything searchable. And back in the early 2000s, it also meant that you have continuous integration. You have very good test coverage, at least in the project where I started. So I came to my first employer and I saw people only on site. They were agile and stuff,
06:06
but they didn't have continuous integration back then. To me that all of that felt very natural. So I've always been taking concepts from the open source world and bringing that into my own employer, into my own teams. And it really came down to a talk that I listened
06:23
to at my very first ApacheCon. I believe it was in 2008 maybe. It was from Bertrand de la Quetas on asynchronous collaboration and asynchronous decision-making. And that was where it really clicked on me how valuable this could be inside an organization, inside
06:44
a corporation. And I've started working in open source, but then in order to make a living, I always was working in non-open source companies. And what I realized is that there is a gap between those two work environments. In open source, very early on,
07:02
we knew how to submit patches. And I met senior engineers who didn't even know how to do a diff and how to create a patch and how to read it. So just a little story for that. We had Berlin Basworth, which is a conference on big data in Berlin in one year. And we did a Hadoop
07:22
hackathon after that. So we had a bunch of engineers in the room, maybe 10 people, starting from students up to senior engineers. And we did a quick poll of topics that people might want to work on. And then we decided that people only had time for one topic really.
07:41
And they had to vote on which was the most important topic. And the most important topic really was for everyone to learn how to make a patch. So we went to the Apache Hadoop back tracker and they had something like fix a Java dog issue. So the first thing those engineers had to figure out is where do you get the source code? How do you check it out? Because
08:02
it was a different system from what they were using at work. They had to figure out where to go for the issue tracker and where to submit the patch, because that also was different from regular work environment. And that is why when I first heard about InnoSource and about the idea of InnoSource, it was totally obvious that for someone who grows up in open source,
08:25
all of these things are very natural and very easy. But if you've grown up in a corporate environment, even the simplest and easiest things that we do on a daily basis, they are very hard. And if you are a senior engineer, even if you're a student coming out of university,
08:41
it's very hard to ask those questions because you have to admit that you do not know that seemingly simple stuff. And you have to ask it in public and you have to ask it somewhere where it's archived and visible for everyone, including your boss and including your future boss. So this seems like a very low barrier. You can just go to mailing list and ask,
09:05
but at some point it amounts to a very high barrier. And that is why I believe that InnoSource can create a certain knowledge of how we work, a certain understanding of how we work, but also reducing this barrier of entry of asking all of these questions publicly, because you can see
09:23
internally how well that works. And that's why I believe InnoSource can be a first step towards open source. And that's also something that I observed at my employer where people started to understand several concepts in the InnoSource context, but then it was very easy
09:44
for them to understand those same concepts in the open source world. We have several patterns phrased in InnoSource terms, but at the very beginning I found myself often telling them, hey, that's how we do it in open source. But now a couple of years later, I see myself
10:03
telling people, hey, that's how we do it in InnoSource. It's no different in open source. It's just public. And that's where it clicks with people. Interesting. That's amazing as well. I think you're dead right. And to add a little bit into that, we did a survey with the InnoSource Commons community there recently. And it's
10:23
interesting to me that actually there's a lot of folks that are interested in InnoSource purely as this idea of how to make collaboration happen, which actually has this potential to bring even more people ready to do open source, even if they weren't originally on that path to do open
10:40
source. So it's not like a conscious decision to get ready for it, but it actually brings them there, which has the potential to hit a hell of a lot more people, which is really, really great. So Anna, I'll come to you now. You're working with the To-Do group. So you know a lot of people in OSPOs. So what are your thoughts in terms of why they are looking at InnoSource or what have you seen? So first of all, I totally agree with what Mark and Isabel
11:05
said. Indeed, I think everything is around developer education. And a lot of the earlier state OSPOs are focusing on that, on the legal side, but also on evangelizing the
11:23
correct open source usage and how to interact with open source. But all that is about developer education on how to use open source. If you translate it to InnoSource, it has a lot of developer education, internal developer education. It's a really big section within InnoSource.
11:48
Maybe that's more for how to integrate open collaboration within teams. But as Isabel was saying, translate it to, well, that's the same, but call it open source and start thinking about
12:05
how to engage in open source. And that's the switch that maybe some teams can see. I've also seen, Claire, you were mentioning about the survey of InnoSource. So at To-Do,
12:23
we have an OSPO survey. And from the last year, there was a question that asked about what is the main objective, the main goal of your OSPO. And I don't remember if it was the first one or the second one most mentioned it, that was building an open source culture within the
12:46
enterprise. So it was like, yeah, that's InnoSource. And that was also, we developed there is a model out there from the recent survey and study we did with all the open source from
13:02
OfficeFox. And there you can see the different stages. And if you take a look at it, just say the basis of those stages, those maturity model is about educating developers. And also, when I interact in the community with the To-Do community in meetings and calls and so on,
13:26
I always heard, how can we build policies to let developers like my internal developers learn about open source? And how can we teach developers and are there any policies to teach
13:41
developers? But everything needs first of all, within the organization. And then once you have all this, yeah, once you have evangelized this ecosystem of collaboration and open source, then yeah, then it's time to move to outbound, like starting to contribute outbound,
14:04
and then you think about open source. But also, there are a lot of organizations that in a public way, they are saying that they have an OSPO and an ISPO or within the OSPO, they have an InnoSource because they are complimentary at some part. So as I said,
14:21
totally agree. Oh, sorry, John Mark, go ahead. I have a follow up for Ana. So on that survey, is there a trend as far as open source programs that are leading their InnoSource programs as well? Like, do you have data on that or has it been separate? Because open source programs initially, like there were the Googles, and I think some people tried too hard to be Google
14:43
from the outset, not realizing that there were different challenges that companies have that, you know, aren't Google. And I think that InnoSource, open source, conjoining didn't really start to happen until recently. And I was wondering if your data showed that. So there is no specific question about that. We are working on the 2022 survey. So probably
15:06
that might be something to take into account or try to create a question about that because it's taking a lot of importance nowadays. Yeah, I bet. We'll definitely take that as an action. I'll add in that we did, as part of the survey as
15:23
well from the InnoSource Commons, we did look at who was building formal programs. And I think there were over 40% of people, I think over 40% of people had already got a formal program. And I think another 20% were planning to put one in place. And what we found is that the vast majority of these formal programs are being seated in an OSPO or in fact, are being
15:45
officially called an ISPO, which is an InnoSource program office, but very typically quite aligned with an OSPO that's already there, similar skills. And yeah, and I just want to point out, I think, you know, the comment Anna made as well about the open source culture.
16:00
And in fact, what Isabelle had been talking about in the context of the kind of patterns and practices for what makes people effective. Like, isn't that so wonderful because so many people, you know, in my experience anyway, when you're, certainly when you're introducing them to open source, they still think it's maybe just the license, right? I'm just going to make my code available and that's it, right? That now I'm doing open source. But to really
16:25
make that effective at an organizational level, you have to have, you know, collaborative practices in place and people willing and able and ready and wanting to collaborate in that open way. And that's so hard. Like we're, we're not designed to do that with our silos and our, you know, ownership cultures and things like that. So in, in,
16:45
in, in corporate organizations often. So there are, there are system barriers in place that sometimes stop that. And then you see OSPOs and InnoSource helping to break those down so that it puts people in a better place. Yeah, I did not appreciate the challenges that these teams face until I saw it firsthand. I had to
17:04
experience the pain before I realized it wasn't as easy as well. Just, you know, collaborate like they do in open source. What's so hard about that? And the fact is like most teams at internal, you know, organizations are not, they are totally siloed and their work streams
17:20
are not planned the way that we're used to seeing in open source communities. They, they don't have autonomous teams that can do what they need to do. There are so many layers of things that they'll need to request. And so it's, it's not as simple as, you know, we'll just, you know, apply these principles internally and you're done. It's, there's a whole method
17:42
of working. And unfortunately, a lot of these companies have also rolled out, you know, agile and DevOps programs, but they haven't quite gone far enough. And so what they've ended up doing is the agile implementations end up being essentially a reinforcement of their previous siloed operations and DevOps basically amounts to, well, let's, let's do some CICD
18:02
automated tooling, which is great. I mean, I totally advocating for that, but there's an additional organizational step that needs to be made that I feel like is just now coming to bear fruit because of the kind of inner sources emerge as kind of like the third leg of the, you know, transformation stool is where I'd like to.
18:24
No, that's great. And so maybe, maybe we'll build on that, John Mark. So to think about, you know, I suppose are typically this institutionalizing of open source. So they're, they're dealing actually in my experience with the two things of, you know, helping individuals and teams do it better in the organization, but they're also dealing with those systemic blockers
18:43
you were talking about, like the organizational constraints and getting over compliance issues and, you know, regulation to some degree as well. So they're kind of playing both, both parts of, of that, that game. And so maybe we'll just go into, you know, what is it that an OSPO does, you know, in the context of inner source rollout? Like what, what are we seeing their
19:04
function in that journey being, so maybe Isabel, maybe I'll come to you first for, to get us kickstart on that. So, so it depends on which organization you start in, but some things that I've seen when working closely with engineers who don't have a lot of
19:20
open source experience is that you first have to disentangle that there is a difference between using open source downstream, contributing to open source upstream and just publishing stuff as open source. Because if you go to an organization and to your engineer would say, think about when coming to them and telling them open source, Oh, great. I'm going to publish stuff on GitHub. Yeah. No. How, what are the reasons, what are the, the criteria for choosing
19:49
a certain technology? If the same, if there are two technologies pulling the same requirement, which criteria are you using to choose one open source pro project with the author? Is it just
20:01
tech reasons? Or do you also look at stuff like governance at stuff like, is there a single point of failure in the project, et cetera? So this is like the first step where you need to do some kind of education. And, and one would assume actually that the, you know, that oftentimes the kind of risk appetite and the criteria for that choice
20:22
may be different depending on the organization and even depending on the context of the code that's been used. Right. So, so it's probably the OSPO is important in, in, in that path as well, right. In terms of, but also for inner source code as well in, in the same way, right. That, that you're, you know, so, so, so all of this is very in organization dependent and contextual, I guess. I mean, we often even have an inner
20:44
source pattern, pattern, which is called, um, explosive governance, um, governance models, where you, where if you have an inner source project internally, you teach people that they should make it explicit, whether they want to keep that
21:01
project themselves or, and only make it available to others so that others can submit feature requests and bug reports like they were before, or as they can open it to pull requests, which means that they have to make time within their team to mentor pull requests that are coming in, or they have a truly shared, um, code, um, code base between
21:26
different organizations and teams within that corporation, which means that they also have to make roadmap planning and stuff publicly available within the organization for that project, for everyone who participates. And if you think about it, that's the same
21:41
things that you have an open source and having that internally life, like those three steps helps engineers think about open source projects differently. They suddenly see the same patterns there where you have projects as that are foundation owned projects that are owned by single entities, like single corporation, single vendors, or single
22:02
individuals, or that you have the open source project, which is completely controlled, where you don't get a lot of help and where you just can submit a feature request if you want something changed. And some things that inner source can help as well is, um, not only thinking about this, um, downstream versus I publish something, but also thinking more about,
22:26
I unblock myself and instead of waiting for this feature request to be worked on, I submit a pull request myself, and that makes it easier to participate externally. And it also starts teams off easier because what I've observed in agile teams that want to participate in open
22:43
source is that they have a hard time scheduling and planning the works that they do on the patch or on the pull request. Because obviously the open source project is not on the same sprint as yourself and they are on a completely different schedule. And by using that same
23:03
working model internally, it already helps to establish, um, some best practices to deal with interruptions. So, so just having the OSPO there to be able to, to gather those best practices that are, that aren't very specific to the organization and then share them out in the
23:23
education role that Anna was talking about, which is some of it may be generic, but some of it may be again, very specific to the culture and the context of the organization. That's an important role. So Anna, you mentioned you, you covered education as being one of the important things as well before. Um, is there anything else that's emerging as, you know,
23:42
in terms of what, uh, an ISPO or, or an OSPO does with respect to, to inner source in your experience? Uh, well, in fact, when you were talking about this topic, I just realized that there is in the OSPO forum, we have someone ask about this, like, Hey, we are building
24:01
internal policies on how to teach developers, which projects they should be using. And there were a lot of people that started to say like, yeah, well, what we do at blah, blah, blah is this, but then another company says a different thing. And it's because as Isabelle say, it's,
24:21
it, uh, it's depending on, um, the sector they come from the culture they have and so on. But again, it's, it's great to see at least a place where, uh, people can share experiences. So, and say, Oh, this might fit for my specific pace. Uh, this, this might not feed and so on.
24:44
Um, so I will say that this is, uh, this is, um, a challenge right now in, in the OSPO verse, I will say the exact, exact same thing. Thanks Anna. And how about you, John Mark, this, did that actually prompt any more thoughts? Yeah, because that got me thinking about like, you know, cultural differences and the need for,
25:05
you know, diversity, inclusion and belonging. Like not, you know, back in the day when open source first started, we were like, Oh, well, it's all open. Everyone contribute, everyone's equal. Uh, except for realize, you know, later on that it became a way to, um, uh, internalize and reproduce kind of like, you know, societal, uh, you know,
25:23
um, issues around, you know, racism and sexism, uh, and that sort of thing. And so I'm curious when it comes to implementing these things internally, how are you addressing, you know, cultural differences depending on, you know, the, the backgrounds of the folks that you want to
25:40
participate in inner source. And I guess the main question is, you know, are you noticing that like, you know, certain, you know, it's easier for, uh, you know, a white man to participate as opposed to, you know, other people that you would want to, um, to be a part of it is, you know, how are you like, uh, uh, adjusting for that? Cause it's, it's something that, you know,
26:03
because we're so new, we haven't really addressed, but I'm very keen to make sure that we're, um, you know, on the, on the right path there. I'm curious what the other panelists think. I'll come back to the other panelists, but I just want to add in that on my journey to, you know, around the open source and inner source ecosystems, one of the things that has been, I think, um, a really great learning for me is the emphasis that both communities
26:26
push on being very explicit about the principles behind codes of conduct, the principles of behavior and the codes of conduct. That's not something that I've seen so explicitly defined before. Um, and you know, knowing the great work that's happening in, for example, the chaos
26:42
community in the open source world, where they're looking at how to, you know, uh, encourage diverse contributions and, and, and support that. And thinking about how the whole thing about inner source is to take those best practices and bring them to a much wider group of, you know, people within an organization. I don't necessarily have the answers for you
27:04
directly, but, um, what I do know is that that practice, that kind of ongoing practice of taking these great ideas and that, that are, that are, have been born from, um, you know, the open source community where, where anything goes, right? There's no,
27:20
there's no official compliance or regulation around, you know, these communities working together. It's not like there's an organizational construct that somehow limits or constrains behavior. So when you get it right there, and then you bring it into an organization, it can only be much more powerful in terms of adding on layers to what might already be there in a constrained organizational context. And so I, I think that the kinds of guidelines that
27:45
were described earlier in terms of, um, you know, how you contribute to a, to a, to a project, how you make it clear, how you onboard into a project, how you make it welcoming and the kind of like, we, we have many platforms about tanking people and how you show gratitude. And these
28:03
are things that make it a more welcoming experience for everyone to contribute outside their normal kind of, you know, scope of, of, of development per se, which I think can only lead to a more diverse and inclusive, um, uh, kind of organizational general, but I, but I'll pass it on. That's
28:23
my own personal beliefs on the matter. Anyone else got a point of view on that DNI aspect? So I have two, two to three points. Um, first of all, I think an open source it's by it being very open and transparent. This helps, um, spot the issues where you have issues.
28:46
Um, the other thing is also that there is a difference and there is a right range, um, of how these issues are being addressed or how they are being seen, depending on which project you look at. So, um, something that helped me a lot at my employer was to have a certain
29:08
understanding where people would be welcome if they contributed and with that knowledge to guide people towards projects where they would be welcome as their first contributions and not
29:21
being pushed back. But I also see a certain level of cross pollination as open source projects, typically aren't in some, they aren't in the white. So people participating there each work at corporations. And what I see is that policies that you have in corporations that work there
29:42
somehow make their way into the open source project and the other way around. And I do, I do know that we do have challenges, but I still have a hope, uh, especially when looking at something like chaos or at other initiatives that at least we are addressing these
30:00
issues. Thank you as well, Anna, you were going to say, yeah, I wanted to add that, um, there is also, um, certain roles, uh, in open source communities and that I also think there exists an inner source that facilitates this, like tries to drive all this documentation,
30:21
codes of conduct. That's all those are for instance, the Deborah's developer relational developer evangelists. Well, and that depends on, on the organization you talk at, but the Deborah's in open source tries to facilitate and to welcome all these contributors. And I've,
30:40
I've heard about internal Deborah's like people that are within inner source that are Deborah's, but to facilitate this collaboration within their enterprise. So I've seen that. I think that investing in this kind of roles and positions is super helpful to, to take this.
31:01
That's a really good point. Investing in the facilitators is a very good tried and true method. Really cool. Great. Well, listen, folks, this has been an amazing conversation. We are unfortunately coming to the end of our bit and it's always too short, but I'm very happy to remind everyone who's listening today that there's actually a followup talk with Anna
31:24
and happening tomorrow. That's a Friday, the 18th, where she will be talking about demystifying OSPOs and what inner source can bring to emerging open source practices. So if you, if you haven't gotten enough inner source yet, you can come back again tomorrow and hear some more. And I will put in a plug for inner source comments that if anyone wants to
31:44
learn more about it, please do come join us at inner source comments.org. And we would love to see you there and to help join in this conversation to bring it all forward. You'll find all of us there. So, so among, in other places as well, but, but I do hope that you will join us now. We will, at this point, go for a quick little session with Tim Willoughby
32:06
to get his point of view, but from all our panelists in this part of the talk, I just want to say a huge thank you. Thank you, Isabel. Thank you, Anna. Thank you, John Mark. It's been a great conversation and thanks to all of the rest of you for listening here today.
32:20
And once again, happy St. Patrick's day. And thank you Claire, Dionne as well. Thank you. See you all again soon. Bye. Bye. Thank you. Bye. Hello again. Here we have a bonus part of our panel session. I'm delighted to introduce Tim Willoughby, who's joining us here from our Garda Síochána, which is Ireland's police
32:42
and security force. I really wanted to get Tim's input to this because I know Tim is involved in some inner source. He couldn't be with us for the original panel recording. So we are using the magic of technology to insert him in after the fact. But Tim, give us a quick overview about your own experiences with inner source and what you've been up to.
33:01
Yeah, thanks very much Claire. And I suppose first is obviously happy St. Patrick's day. Sorry, we can't be with you on the day, but for obvious reasons, we'll be managing all of the security things around St. Patrick's day in the organization that I'm in. The rest of the country will be sitting back and relaxing, but I'm sure we'll be taking it the way most
33:22
security and policing organizations take it. But yeah, the inner source thing is, I suppose, I've been on the whole open source journey since, I think almost since I started in government in terms of as an engineer sharing code with other engineers on how to do drainage
33:42
design or bridge design and moving that on from those early things, it was all about openness and sharing. And, you know, if I have a problem, can I not just ask another one? And, you know, the archives are all there to look up, to share knowledge. And I think where inner source is really becoming interesting is in the policing realm, where a number of the national police
34:07
forces are starting to share code. And what we've done is we've moved our end user computing or our mobile computing models to, I suppose, a different architecture where we're basically
34:22
architecting at the lowest level or micro architecture. And what that means is we're ruling out the language barriers and we're ruling out the different interface issues that we might have where we can share micro code. So we have some code that can scan number plates
34:40
or can scan licenses or passports or scan the health codes that are where everyone's familiar now with the digital COVID certs, but we've scan our apps and we can swap those with other police forces without having to worry about the top layer or the user interface layer. So a number of us have moved to this micro architecture in order that we can actually
35:04
learn and leverage from each other. And I think there's a code repository starting to build up. Like inner source has given you away the processes by which to do these collaborations, which is brilliant. And, you know, I completely understand that there are certain scenarios where security forces may not want to do that completely in the open. So this is a way
35:24
to do it between yourselves without being completely open source. But when you think about it from a culture change perspective, was there a culture change element in that collaboration and how you all work together? I mean, apart from the technical outcome was, did you find it a culture challenge? Oh yeah, I think I suppose I came at this from not
35:47
having a policing background. The first couple of sessions before we brought the developers in were really about the structure and how will this work. And my having worked with open source for years, my sense was just let's get them in a room and trust them. It'll work.
36:05
And what's happened is other forces actually were looking at how they were doing their development and said, Oh, never thought of this. And they brought more people over to learn about just about the simplicity of, of being able to share beyond below the firewall. Maybe
36:24
is that the best way to describe it in a policing world rather than sharing in front of the firewall where the whole world can see, you know, they, people will assume we have stuff that can read passports and stuff, but they may not know exactly how it works. And maybe those are things that we need to keep to ourselves. So, but it's certainly the more people saw what we were
36:43
doing, the more people wanted to join and understand. And part of our discussion here today has been about how do you institutionalize those, that kind of culture change using something like an open source program office, some sort of, um, some sort of institution that actually helps or smooths that journey. I mean, from your perspective, you have not been engaging or
37:05
you don't have an OSPO or an open source program office or anything to help that journey. Do you think it would help? Like, would that be something that could actually ease that journey for future collaborations? Oh, I think, I think absolutely to take the learnings and to, I suppose, give probably the governance and the, to give the culture a sense of direction.
37:26
But, you know, I suppose without the governance, it just becomes a group of people who are fanatical, you know, so I think you need, and I can't believe I'm saying this, but you need somebody to actually give it a direction and, and have a focus. So
37:40
all those who want to join aren't talking to the fanatics, but they're talking to the realists about, you know, how, how this will all work and the commitments to join and the benefits of getting stuff out of it. Absolutely. Well, thank you so much for sharing part of your journey. I do hope that we do see some OSPOs coming, popping up in that space. We're seeing them pop up
38:01
all over the place in public sector organizations. So hopefully there'll be one soon to help you on your journey, but thank you so much, Tim, for sharing your journey. And once again, happy St. Patrick's Day. Oh, thank you very much. Yeah. Happy St. Patrick's Day. Hi there. Welcome back. I just like to say on behalf of the FOSBAC stage team, a real big
38:23
thank you to all of the panelists. It was a wonderful panel, very interesting. We're very lucky to have two of the panelists with us here today. So please write your questions in the chat for you to ask them. So I would just like to welcome Isabel and Anna.
38:44
Hi there. So yes, now we have some time for questions, probably about 10 minutes, 5-10 minutes. Looking in the questions now, we have a couple of them. So the first one is,
39:00
someone says, hello, thanks for your talk. More often we deal with Innersource and OSPOs as a taxation and transfer pricing issue. Do you see broad awareness for this or a chance to address this within the broader Innersource community? Just wondered what your thoughts on that are. So one thought that I have with respect to transfer pricing is that there is an ongoing
39:28
discussion on that topic. Just yesterday we had a community call in the Innersource comments. It will be public or it should already be public on YouTube, on our YouTube channel,
39:40
so you may want to watch this talk. In addition, we do have these discussions in the Innersource Slack where you can join them. Okay. And there's a question I think that was relating to something that you said Isabel earlier about pull requests. So it says,
40:03
when a pull request comes in, is the assumption that the pull request sender might need mentoring to get started with Innersource? Is that something that you see? It's not so much that they need mentoring to start with Innersource, but it may be that they need support and help
40:22
with understanding the architecture of the project that they are contributing to. It's no different than when you start your very first pull request with an open source project. You may need to educate the person on how the process works, but you also need to make time to explain to them the general architecture or to point them to the correct documentation
40:43
or to like beginner stocks, etc. Okay, thank you. So Anna, you were talking about education in that talk, and I just wanted to get your thoughts on it. What are some of the most
41:03
innovative or interesting examples of this kind of education that you've seen? I wonder if you could share with us some of the things that you're interested in or think it is out there. Are you talking about specific policies or documentations that organizations are doing to
41:23
educate developers? I didn't really have anything specific in mind. I just wanted to get your views on, for example, for people who are thinking about getting involved in this kind of stuff, like what could they look at, for example? I think GitHub has a really useful
41:44
guide for individual contributions. I can share the link later, and in Todo, we have guides for open source program offices, so GitHub has a guide for individual contributions. So if someone is a developer or maybe is not a developer and they
42:04
just want to get started to how open source works, like how to submit my first pull request and how do Git branches work, because that is something that maybe some developers that go crazy with that. So that is something that GitHub has created stuff, and also there are
42:25
some dev roles in the ecosystems that has channels, like YouTube channel, like learning by doing. I honestly learn a lot from YouTube videos and this kind of documentation,
42:42
like for the very first, like how to get started, and I would say that's good resources to at least get started. Also, one of the good things of the OSPOs is that OSPOs are creating for their developers and all the OSPOs, these specific guides, like maybe more tailored for
43:09
their needs and for the OSPO, but it's in the public and it explains everything. For instance, Yahoo has an OSPO web page and they have a complete guide not only about educating developers
43:24
in the community, but also in the legal side, like what are CLAs, how do they work, what are software bill of materials, because that is also really important. I know all the OSPOs, mature OSPOs that already has also these guides, so that's great because it's in the
43:42
open and all the OSPOs can learn from them. Great. Isabel, do you have anything, any thoughts on this kind of education or getting people involved in this way? First of all, I would like to say that I agree with everything that was said so far,
44:00
and in addition, a lot of the bigger open source projects, they also have mentoring programs where you can get into open source contributions. There are formal mentoring programs like Google Summer of Code or like outreachy things, but there are also informal mentoring. If you go to a mailing list, say at Apache and you say, I have no experience, please explain to me how that
44:22
works, then people will be very helpful. Typically, the larger ones or the older ones, they also have pre-existing documentation like how do I make my first patch, where do I find the source code and how does patch submission work. Typically, you will find that on some web
44:42
page, which is for contributors.