The pool next to the ocean: How to bring OpenSource skills to more people
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 |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 490 | |
| Autor | ||
| Lizenz | CC-Namensnennung 2.0 Belgien: 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/46971 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSDEM 202085 / 490
4
7
9
10
14
15
16
25
26
29
31
33
34
35
37
40
41
42
43
45
46
47
50
51
52
53
54
58
60
64
65
66
67
70
71
72
74
75
76
77
78
82
83
84
86
89
90
93
94
95
96
98
100
101
105
106
109
110
116
118
123
124
130
135
137
141
142
144
146
151
154
157
159
164
166
167
169
172
174
178
182
184
185
186
187
189
190
191
192
193
194
195
200
202
203
204
205
206
207
208
211
212
214
218
222
225
228
230
232
233
235
236
240
242
244
249
250
251
253
254
258
261
262
266
267
268
271
273
274
275
278
280
281
282
283
284
285
286
288
289
290
291
293
295
296
297
298
301
302
303
305
306
307
310
311
315
317
318
319
328
333
350
353
354
356
359
360
361
370
372
373
374
375
379
380
381
383
385
386
387
388
391
393
394
395
397
398
399
401
409
410
411
414
420
421
422
423
424
425
427
429
430
434
438
439
444
449
450
454
457
458
459
460
461
464
465
466
468
469
470
471
472
480
484
486
487
489
490
00:00
Prozess <Informatik>UnternehmensarchitekturKollaboration <Informatik>QuellcodeOpen SourceMereologieDifferenteRandwertKollaboration <Informatik>Güte der AnpassungStrömungsrichtungRechter WinkelBrennen <Datenverarbeitung>ProgrammierumgebungComputeranimation
01:21
StrömungsrichtungRechter WinkelComputeranimation
01:58
QuellcodeUnternehmensarchitekturLuenberger-BeobachterSpieltheorieFokalpunktOpen SourceQuick-SortNormalvektorInteraktives FernsehenFreewareSoundverarbeitungVollständiger VerbandGruppenoperationeCosUnternehmensarchitekturNotebook-ComputerProgrammierungMinimalgradOffice-PaketMereologieSelbst organisierendes SystemDienst <Informatik>MathematikKollaboration <Informatik>Offene MengeCodierungRechter WinkelMultiplikationsoperatorComputeranimation
03:56
ProgrammfehlerCodeMultiplikationsoperatorAutomatische HandlungsplanungQuaderCASE <Informatik>Computeranimation
04:33
CASE <Informatik>MarketinginformationssystemOpen SourceOrtsoperatorComputeranimation
04:51
Open SourceKollaboration <Informatik>TelekommunikationDemo <Programm>DistributionenraumBitProgrammierumgebungOpen SourceFokalpunktOrtsoperatorBetragsflächeTelekommunikationMinkowski-MetrikTeilmengeWärmeübergangEinfügungsdämpfungCASE <Informatik>MultiplikationsoperatorKollaboration <Informatik>VerkehrsinformationAmenable GruppeComputerspielMathematikStrömungsrichtungRechter WinkelQuellcodePhysikalisches SystemPackprogrammRückkopplungRuhmasseGlobale OptimierungSoftwareOffene MengeUnternehmensarchitekturComputeranimation
08:54
Offene MengeBitOffene MengeDistributionenraumGruppenoperationUnternehmensarchitekturProjektive EbeneOpen SourceBereichsschätzungKollaboration <Informatik>MultiplikationsoperatorMinkowski-MetrikQuellcodeOrdnungsreduktionMechatronikFokalpunktComputeranimation
10:09
Kollaboration <Informatik>SoundverarbeitungOrdnungsreduktionTermDistributionenraumTermGebäude <Mathematik>UnternehmensmodellOpen SourceComputeranimation
10:49
Produkt <Mathematik>Projektive EbeneSoftwarewartungQuellcodeCodeMultiplikationsoperatorOpen SourceVertauschungsrelationComputeranimation
11:22
SoftwareQuelle <Physik>NormalvektorQuellcodeProjektive EbeneSkriptspracheComputeranimation
11:41
Shape <Informatik>SkriptspracheGebäude <Mathematik>SchnittmengeUnternehmensmodellComputeranimation
11:59
VideokonferenzSchnittmengeVideokonferenzOpen SourceCASE <Informatik>Rechter WinkelBitUnternehmensmodellWeb SiteServerComputeranimation
12:26
VerschlingungQuick-SortYouTubeUmwandlungsenthalpieTwitter <Softwareplattform>QuellcodeOpen SourceVersionsverwaltungComputeranimation
12:43
WellenlehreDateiformatMusterspracheQuellcodeEinflussgrößeUnternehmensarchitekturUmwandlungsenthalpieVerschlingungQuick-SortLuenberger-BeobachterKontextbezogenes SystemDatenverwaltungStatistische HypotheseComputeranimation
13:31
Dynamisches RAMDualitätstheorieInklusion <Mathematik>Open SourceGebäude <Mathematik>Rechter WinkelCASE <Informatik>QuellcodeSchreiben <Datenverarbeitung>Web SiteComputerschachComputeranimation
14:38
Quelle <Physik>EreignishorizontDualitätstheorieVerschlingungCASE <Informatik>Message-PassingComputeranimation
15:22
PunktwolkeOpen SourceFacebook
Transkript: Englisch(automatisch erzeugt)
00:05
And our next speaker is Johannes Tiegs, who's gonna speak to us about bringing open source skills to more people, so please give a warm welcome to Johannes. Right, so hello everyone.
00:21
I'm here as part of the InnerSource Commons community, as one member, and when I'm not here, I'm giving a talk, I do open collaboration, consulting community stuff, and some DevOps and special things, but let me go on. So who of you ends up working in a large company
00:42
like, say, 3K people or more? There are a few. And who can regularly contribute on behalf of their company to open source? A lot less. Right, so what I do see,
01:01
there are people from different sizes of companies, and there might be different approaches to open source. My talk actually spans all of these environments and roles. InnerSource is a topic that is focused on enabling and encouraging collaboration across boundaries.
01:21
And let me start with a bit tougher. We see here the ocean, that it can be somewhat dangerous, like tides and currents and that, but swimming in it can be really fun if you are good at swimming for that. And then there's a nice pool, and pools are a safe place to actually learn to swim.
01:41
And this nice ocean pool in Bondi would allow you to swim next to a real thing and to feel the gusts and the smell of salt, and then to just jump right into the ocean once you feel ready for that. And right, let's go to other things.
02:01
So while working in companies, I observed, my personal observation, there are sort of two groups of people. First, the enterprise people, which just go about their daily coding business and possibly take advantage of OSS, the free S and free B away. And then there are the open source communities
02:22
and their members who are actually involved in that and do contribute and all of that. And unfortunately, they do not really have that much of an overlap. But for this talk, let's focus on the ways of working. There are lots of other aspects.
02:40
And actually, these days, there is some overlap with more and more of these large enterprises having open source programs, offices, and all the nice foundations such as, for example, the Apache Foundation or the Linux Foundation gaining more and more impact. And if OSS, like open source, would be the absolute norm,
03:00
we'd not be having these open source focused and open collaboration focused conferences like the nice host time here or open source programs offices because all of that would be just standard daily business. And so what there exists, let's assume for this talk that there are still a lot of these really closed off enterprises.
03:22
And enterprises, yeah, right. So they do work and to some degree and brought us nice things such as these laptops or your laptop, flight booking services, and some parts of our cars. However, they do have their changes, challenges. Like they're hierarchical, they are often focused on spoken interaction
03:40
and all sorts of meetings, and there's lots and lots of tribal knowledge. And you need to actually find the right person first for whatever, and often you have to talk to them for a while to get somewhere and get to that tribal knowledge. And they have silos, and those silos have quite some adverse effects actually. So imagine you are depending on some other team
04:02
and you need something from them, and then they just do not have it on their plan what you might need. Some other teams might need that too, but yeah, probably you will wait for a very long time if you get it at all. What might happen is that you might end up building a workaround and amass extra code
04:21
that you actually have to maintain, or you duplicate existing work by that, and then you actually are responsible for the bugs you introduced and that extra stuff. And this could happen per team that faces this issue. Another thing that Hap, Maya, Meti might have seen is the case of escalation, where things get escalated to all those higher ups,
04:42
the big cheeses, if you will. And if you do that too often, you basically lose credibility and end up as the boy who cried wolf. So that's, maybe some of you have seen some of those corporate things. Then open source. So it's great, actually, and has lots of positive aspects, and I'm sure many of us here have likely experienced
05:02
some of those firsthand. And I'll just name a few approaches related. For example, there is collaboration to arrive at a solution. This could have fixed the workaround and escalation and waited out scenarios that I mentioned. The focus on written, archived,
05:21
and searchable communication often, which makes this tribal knowledge more explicit and reconstructable, and this facilitates onboarding and distributed work approaches. And there's working in the open, as we all know, the pull request, and publicly visible, that enables fast feedback and the distribution of knowledge.
05:43
And actually, there's a lot of fun in it. At least for me, there is outside visibility and you can do the good thing. And there are lots of other advantages for these large enterprises, far side of cost. So there are, however, some challenges
06:02
because it is not entirely free. Maybe some of you have experienced some of those yourself. For example, in the case of working in the open, you have to be comfortable to share unfinished work and open it for criticism and scrutiny by others. And for this, you actually need to create communities
06:20
where people feel safe and comfortable to do exactly that, and you have to keep them productive and positive. And you have to develop an acceptance and a way to deal with mistakes in a positive way. There is this case of text-focused communication, which means a synchronicity, and hence, the loss of important non-verbal aspects.
06:43
And you need to be able to establish a report with far less personal presence with people. And you need to be able to create an environment that is welcoming to often unknown people with unknown motivations to join and an unknown time budget and stay duration.
07:05
So, and there are actually also these governance and licensing issues. And many of us likely have learned to do this on their way through the open source community and the larger side, and you likely grew while doing so.
07:24
And you built valuable relationships, and likely you also had quite a bit of fun. Proverbially, you learned to swim in the ocean directly, and obviously, you survived. Maybe some others didn't. And all right, so do you actually remember
07:40
how you, what got you into the open source community, and how you learned to handle these challenges I mentioned? And how possibly you were afraid that some suboptimal public contribution might come back to haunt you? And in most cases, actually didn't. And maybe someone was even thankful
08:01
that there is something instead of nothing. And you had to learn about all these licensing things and the mess around it. Or if you have a company, you try to open source, or a working one, open source something. And yeah, maybe you would have wished that your colleagues, some of them, might have more of a grasp
08:21
of these open source ways of working. Or you tried to hire people to work on your open source software, and you needed them to have these open collaboration skills. And wouldn't it actually be great to have a safe space to enable people to learn about these open source ways? Yeah, in a safe and productive environment.
08:42
And maybe, if you could even get some relief with these silo, innovation and knowledge transfer issues while along the way. Or just have a bit more fun while you still have to work on proprietary stuff. Right, so inner source can actually act as this space that allows people to learn, fail without fear,
09:03
and grow their open collaboration skills on the way. It can be the prevailable pool next to the wild ocean of open source. And it can allow people who don't feel comfortable to learn to swim in the ocean to prepare for this in a safe way.
09:22
And if you grow internal projects like open source projects from the start, you can actually transition them into full open source easier often. And the people that are, when participating, in the end are equipped with these skills, will likely have an easier time adapting to other open source communities,
09:41
and will be able to act with confidence and kindness there. And yeah, additionally, it actually can bring the advantages of quite a bit of open source to your enterprise. That would be collaboration, for example, this working in the open. Yeah, and some reduction of issues on silos
10:01
and large distribution. And they might even actually get to have a bit more fun in their everyday business. Yeah, that is actually valuable too. Right, so does all this magic that I mentioned happen on its own? Actually, very unlikely so. So you need to have some people
10:21
with great open source and community skills to mentor the new and interested people. If you don't have a large company, they can't be everywhere though. And what if you don't have them in the first place? Wouldn't having a simpler model that encompasses a few important things to start with, and some documentation on that be great? In our work, we've found a few roles
10:42
and terms to start with, making it easier to reason about that and allow you to start building and customizing your own. These are, yeah, so the host and the guest teams for the both involved parties, the trusted committer, which is what is usually known as maintainer or committer.
11:01
The guy who's, or the person who's trusted with the code base and community contributor, yeah, would probably be what you know. And if you have a very large project, a product owner, and yeah, some of those people may have multiple roles at the same time, often product owner, trusted committer, and you might have more than one trusted committer,
11:21
and yeah, just like with normal open source projects. Is any of that supposed to replace everything or agile or I don't know what? Actually, no. You can replace that. You can integrate the intent to solve something via your source in your normal spring places for your big cathedral software project,
11:42
or you can have graduate-style side projects, and maybe they'll evolve into something bigger or just be this nice release or build automation script that is, in fact, used everywhere, and there's surely more, because Innersoft actually comes in all shapes and sizes.
12:01
I mentioned a bit of documentation on the model for people to use to learn, and a set of volunteers actually created that, and still created that, me included, and there is a set of videos and a set of articles, in case you don't like or want to watch a video right now, and all of those are open source
12:21
on the Creative Commons license, and yeah, we welcome contributors if you would like to. They're available on this nice website, on YouTube as well. There's all sorts of links. If any of these doesn't work, just hit me up on Twitter, and if you happen to have an O'Reilly account, they have a very nice version of that
12:42
prepared to write. So, just as with open source, there are actually some challenges, some similar to what you might know from open source, and some more specific to inner source and the enterprise context, and like, for example, measurement of success, incentivization of middle management,
13:02
some nasty text issues, and there are somewhat proven attempts to handle them, and they are collected by community members in something that is called the inner source patterns, the sub-community, and yeah, there's our observation of those challenges,
13:23
approaches that happen to have worked, or hypotheses, and collected in a sort of pattern format. I've got a link at the end, and they're actually pretty useful. All right, so an important question is, should actually be the goal to stop at inner source?
13:40
Absolutely please not. Let's not allow companies to open source, greenwash, if you will, themselves, and call that inner saucer. Got this nice washing label here. And if you have the right people with open source skills, and you can make this case to directly open source something,
14:00
absolutely please do it. It's the right way to go. But what if you cannot make the case to directly open source something, or you let the people with the skills to actually do that properly? Wouldn't it be great to still be able to profit from some open source work approach advantages, and get to build open source skills
14:21
with people on the way that might or will come in handy once you're ready to open source something, actually? I think this is actually a way to help more people embrace open source who might otherwise not have considered it. So that's what brought me here. And we have also a nice small ad,
14:43
a nice summit in the middle of April in Madrid, Spain. And there's a website if you're interested in that, and I have a few flyers in the other case. Right, and you're welcome to join us there. And so that is all I have. Here's a bunch of links that are if you have any questions or other things you're interested in,
15:03
use those hashtags or just message me. And thanks for listening. And yeah, some of us are here as well. Maybe you can put up your hand and talk to us. If that was interesting, talk to them. Yeah, so thank you. That was all. Thank you.