The Cathedral, the Bazaar, and the Coffee House
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 | 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 | 10.5446/66669 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
FOSS Backstage 202334 / 38
7
8
11
23
27
31
33
00:00
Open SourceBenutzerprofilSoftwareAnwendungsdienstanbieterTurm <Mathematik>Strategisches SpielOrdnungsreduktionKomponente <Software>SondierungGraphCodeSoftwareentwicklerExplosion <Stochastik>RechenschieberInformationGüte der AnpassungQR-CodeTurm <Mathematik>SoftwareGraphCodeStrategisches SpielGrenzschichtablösungSoftwareentwicklerRandomisierungStützpunkt <Mathematik>RuhmasseOrdnungsreduktionPunktNumerische MathematikEreignishorizontGarbentheorieHypermediaFreewareOpen SourceSondierungZeitrichtungVererbungshierarchieVerschlingungComputerspielSoftwareschwachstelleEigentliche AbbildungEDV-BeratungBimodulPhysikalische SchichtMathematikZusammenhängender GraphProjektive EbeneSchedulingProzess <Informatik>MultiplikationsoperatorSoftwarepiraterieEinfügungsdämpfungVerkehrsinformationZählenSystemzusammenbruchMinimumMultiplikationContent SyndicationAblaufverfolgungArithmetisches MittelGerichteter GraphMailing-ListeComputeranimationVorlesung/Konferenz
08:15
Komponente <Software>Open SourceSoftwareentwicklerExplosion <Stochastik>AggregatzustandDatenverwaltungKontrollstrukturMinimumFehlermeldungVersionsverwaltungBimodulStrategisches SpielEnergiedichteMAPOffene MengeVollständiger VerbandSoftwareMathematikSoftwareentwicklerBimodulProjektive EbeneZufallsgeneratorSoftwarewartungSoftwareWeb SiteVollständiger VerbandStrategisches SpielOpen SourceProzess <Informatik>FreewareMultiplikationsoperatorSelbst organisierendes SystemDifferenteGraphiktablettCodeGraphfärbungVersionsverwaltungFunktionalTeilmengeSchaltnetzChiffrierungÜbergangSondierungProgrammbibliothekGamecontrollerUmwandlungsenthalpieNumerische MathematikBildschirmmaskeResultanteQuick-SortInternetworkingSystemzusammenbruchZusammenhängender GraphTypentheorieGraphDeterminantePunktSoftwareschwachstelleMathematikEINKAUF <Programm>Partielle DifferentiationFehlermeldungExogene VariableFastringTropfenAuswahlaxiomStandardabweichungRichtungKette <Mathematik>ComputersicherheitKartesische KoordinatenFormale SprachePhysikalisches SystemGruppenoperationOffene MengeEnergiedichteComputeranimation
16:08
SoftwareMathematikOpen SourceStrategisches SpielProgrammierumgebungAssoziativgesetzSpezialrechnerMultigraphInnerer PunktIndexberechnungPlastikkarteOrdnungsreduktionPoisson-ProzessRechenschieberSoftwarewartungSondierungExplosion <Stochastik>InformationUnordnungPay-TVDatenverwaltungAggregatzustandSoftwareentwicklerOpen SourceEinsMetrisches SystemProjektive EbeneEinflussgrößeGemeinsamer SpeicherSkalenniveauStellenringInnerer PunktDimensionsanalyseVerkehrsinformationMultiplikationFirewallMAPPhysikalisches SystemInjektivitätOffice-PaketOptimierungProzess <Informatik>BildschirmmaskeOffene MengeQuellcodeVersionsverwaltungRechenschieberKatastrophentheorieTypentheorieImplementierungProdukt <Mathematik>Numerische MathematikProgrammierumgebungSoftwareSelbst organisierendes SystemLeckDifferenteMultiplikationsoperatorTelekommunikationAssoziativgesetzAnalysisKlassische PhysikInformationsspeicherungTeilbarkeitBus <Informatik>DatensichtgerätGruppenoperationAnalytische MengePhysikalische SchichtAdditionDiagrammGebäude <Mathematik>CASE <Informatik>UnordnungMalwareSoftwaretestFreewareFlächeninhaltAggregatzustandDatenverwaltungMomentenproblemComputeranimation
24:01
Open SourceDatenverwaltungAllegorie <Mathematik>SoftwareentwicklerUmwandlungsenthalpiePaarvergleichQuick-SortSelbst organisierendes SystemMultiplikationsoperatorProtokoll <Datenverarbeitungssystem>BetriebsmittelverwaltungGrundraumFirewallProzess <Informatik>Projektive EbeneInnerer PunktProdukt <Mathematik>MAPKoordinatenLeckStandardmodell <Elementarteilchenphysik>EntscheidungstheorieArithmetisches MittelGrenzschichtablösungVorzeichen <Mathematik>DifferenteInformationSchreib-Lese-KopfKontinuumshypotheseTouchscreenOrdnungsreduktionCASE <Informatik>Grundsätze ordnungsmäßiger DatenverarbeitungApache CassandraUniversal product codeBasis <Mathematik>SoftwareRechter WinkelEinfügungsdämpfungWechselseitige InformationFormation <Mathematik>Mixed RealityOnline-DienstBesprechung/InterviewVorlesung/Konferenz
33:07
Open SourceOffene MengeComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:03
Ah, good morning. Let me start by saying that all of the slides and some of the background information is available at that URL and the QR code there. And don't worry, I will display that again later if you don't get a picture of it right now. But you may wonder about the title.
00:21
I'll start with The Cathedral and the Busy Post by Eric Raymond, in which he describes two styles of open source development. And we'll discuss those later. But the coffee house is a concept that I'm introducing today.
00:40
And along the way, we'll talk about some risks of open source development and some potential solutions to solve those risks or managing those risks. But first, let me introduce myself and present a little history, though I'm Claude Warren, Jr., as you heard. My social media links are there at the bottom.
01:02
I am a member of the Apache Software Foundation. I work, contribute to Jena and Commons and Cassandra projects. I call myself an effectuator. I am not the Claude Warren that's in Wikipedia. That's my father. And if you look him up, you'll find a link to my mother.
01:21
And if you look, follow that link, you'll see that she is an historian. And that's a good segue, because I want to start in the year 1688. So in 1688, Edward Lloyd founded a coffee house on Tower Street in London. And his customers were involved in the shipping trade.
01:44
So the discussions in the coffee house centered around such topics as ship schedules and manifests and losses and things like that. So shipping was the high-tech industry of the day. And as with any high-tech industry, there was a lot of
02:02
money to be made and fortune to be lost. And there were several major risks that his customers were talking about. First among them, sinking. According to Wikipedia, and excluding those ships lost in battle, there were 318 ships lost erect in the 17th century.
02:24
More were lost without a trace. Those are the 318 that we know of that are listed in Wikipedia. You would also be worried about pirates. The 17th and early 18th century were the golden age of piracy.
02:40
So this is a time that you would be worried about pirates. I think we're still worried about pirates. You would also be worried about cargo going overboard in the storm. And Wikipedia lists 87 storms for the 17th century in the Atlantic. This is, again, an undercount because it doesn't include major storms and other oceans and seas.
03:02
And if a storm blew through and didn't hit landfall in someplace that wasn't in contact with Western society, we wouldn't know about it. And then the other one is the prices might crash before
03:23
your shipments arrived. So the market crash, the tulip crash of 1637 is an example of this risk, where if you loaded your ship up and before it made the dock, then the prices collapsed. Then you would have made less than you cost to fit out
03:43
the ship to begin with. So what happened was that they had discussions at the Coffee House, and investors came up with a risk reduction
04:00
strategy. And their risk reduction strategy was that investors would invest in multiple ships and cargo. So rather than putting all of your money into one ship or buying all the cargo for one ship, you would distribute that across multiple ships. And in the process, you would then share in the profit, if there was a profit to be made, or you would share in the loss if there was a loss.
04:23
Effectively, this made Lloyds one of the earliest insurance syndicates. So with benefit of hindsight and the knowledge that those who do not understand the past are doomed to repeat it,
04:41
let's look at risk exposure with open source software. But first, a little more history about this talk. I originally presented this subject as a lightning talk at Apache Con in 2022. That talk was five minutes long, no slides. And at this point in the talk, I recited a bunch of
05:00
dates and events, things that happened in open source development. When I went to do this as a longer talk with slides, that section bored me to death, so I took it out. But let me give you the three salient points. According to a Synopsys 2019 survey, 99% of code bases that they audited contained open source software.
05:24
82% contained outdated or abandoned software open source components. And I want to note that this XKCD panel is so on point that project in Nebraska and maintained by some random person in Nebraska have become idioms, meaning any open
05:41
source project maintained by a single person. And the third point, 73% had at least one license issue. Licensing issues are a deep and difficult subject, but there are a number of open source software licenses, and
06:00
they are not all compatible with each other. For example, if you have some code from the Mozilla 1.1, Mozilla public license 1.1, and some code from the new GPL, the GPL code, and you want to combine those together and redistribute it, you can't do that without violating one of the two licenses.
06:22
And this is true even though both are approved by the open source initiative and the Free Software Foundation. And as a little deeper example, we have the license mess as a graph. And this graph shows several popular licenses, and arrows indicate which licenses can be included in code and with
06:41
other licenses. It's not complete. I'm not a lawyer, solicitor, or any other legal professional, so your mileage may vary. What this graph doesn't show is it doesn't show if the Debian Free Software, if it follows the Debian Free Software guidelines, if it's Free Software approved, Free Software Foundation approved, if it's OSI
07:02
approved, if it's got except copy left code, or in fact, if it allows linking to other modules with different licenses. And again, I'm not a lawyer. Consult proper legal guidance.
07:22
So why do we care? Well, we care because your project probably depends on open source projects. And that means that the outdated and abandoned open source components aren't going to be upgraded if there are vulnerabilities discovered. So the xLab GitHub 2020 Insight report lists about
07:44
54 million active projects. With 14 million active developers, that means that there are about four active projects per developer. And you have to ask yourself, how many of those are one developer projects in Nebraska?
08:00
And now we want to think about why would they become abandoned? And I think that there are probably two major reasons. First is a life change. So marriage, children, sick parents, new job, financial stresses, they're all vying for the time that was previously spent on open source development. And the other reason that people would leave or abandon a
08:24
project is just disillusionment with the process. So two examples of this are in 2015, Azar Kachulu, and I hope I pronounced that correctly, deleted LeftPad NPM module. And he booked thousands of websites when he did that.
08:42
Now he felt that he was poorly treated in an IP naming spat with NPM. And later he stated that the situation made me realize that NPM is someone's private land where corporate is more important than people. The second example is Merrick Squires, who sabotaged Faker
09:02
and Color's NPM modules, again breaking thousands of websites. And he stated that he was tired of supporting Fortune 500 companies for free. So this brings us to the Tidelift open source maintainer survey in which almost half of the
09:22
respondents listed stated that financial compensation was the top reason that they disliked being a maintainer. The other reason we're going to care, probably going to care, that licensing issues are expensive to mitigate. Recently a number of projects have changed licenses
09:42
from pure open source to some sort of partial open source, often for financial reasons. So to mitigate these changes, projects either have to purchase licenses or change the software that they're dependent on or have their users purchase licenses.
10:00
And the three examples that I have of this are the 2018 MongoDB, 2021 you have Elasticsearch and Kibana, and then just in 2022, ACCA changed their license. And the third reason that you might care is that transitive dependencies make any upstream issue your issue.
10:21
And this last one should scare you. As an example, we have this nice dependency graph here. And if you run project P, up there at the top, and project O, just there below it, becomes abandoned, you can probably pick up the code and create a new module to do the same thing.
10:40
Or perhaps you'll take over the maintenance of project O. Or you might find a drop in or near drop in replacement for project O. If project O changes its license, you basically have the same choices, it's not too bad. But if DD is no longer supported and has a problem,
11:02
then you have to know that O depends on H, which depends on T, which depends on DD, all to understand that you have a problem. And depending on what language is involved and how it's loaded, if DD suddenly disappears, your entire
11:21
application may grind to a halt. If DD is no longer supported and a security hole is found, then you're going to have to understand this whole dependency chain to understand that you have a security problem. Now, if your project is II over here, the other one at the top, you will notice that it has a much longer
11:43
dependency chain. So what has to happen is you have to be responsible to track and manage all of the transitive dependencies and all of the issues that arise in those transitive dependencies. So how are that going to impact your project?
12:03
OK, so enough about that. What was this cathedral and bazaar thing that I started with? Well, as I said, 1997, Eric Raymond speaking at Linux Congress introduces the concept of cathedral and bazaar. Cathedral is a top-down development. Its development direction is controlled by
12:22
specific design goals. It's usually a tightly controlled development. It operates much like a standard closed-source development system. Now, there's a perception that some cathedral development is so tightly controlled that it doesn't readily accept contributions.
12:40
For software in this subcategory of cathedral development, it would be very difficult to get functionality added that didn't fall within the existing design strategy. Now, I want to be clear that not all cathedral development is so tightly controlled that it doesn't accept external contributions. But it's a risk.
13:01
And if your project is dependent on a project that uses cathedral development, this is something you need to assess. The other form, the bazaar, has a wider pool of developers, but it tends to lack the tightly controlled specific design goals that you see in the cathedral. Some argue that this lack of tight controls can lead to
13:23
difficult to detect errors. For example, in an encryption library, where if you're optimizing for the code path, you might replace a random number generator with a weaker but faster one. This is going to yield weaker, or may yield weaker, encryption.
13:42
So let me be clear again. I'm not claiming that this is always a risk, but that each project should be assessed for these risks. And finally, there's a combination. You get software development that's a combination of these two strategies. And now all of these strategies have their place. They can all produce excellent results.
14:02
Each has a weakness to go with its strength. But the point here is that projects should be aware of the strategy that's used to develop the components and determine for themselves how that impacts the type of component being developed. OK, are you overwhelmed yet?
14:21
Let's think about this a minute. You have to find all the upstream dependencies. You have to analyze the issues. Is there a license conflict? Is there a wrong development strategy being used to analyze the risks? Is the developer community going to crash? Is there a possibility of a license change? What are the possible mitigations we might have? Can we contribute to the upstream project?
14:41
Can we fork it if we need to? What is it we don't know we don't know? And what is it that we know that just isn't so? OK, have a cup of coffee. You'll have enhanced energy levels, less likely to suffer heart failure, and less likely to suffer stroke. Now I want to point out that I got the benefits of
15:01
coffee from the internet. And as that great US President Abraham Lincoln said, don't trust everything you read on the internet. All right, you could open a coffee house if you want a cup of coffee. You can meet like-minded people. You can meet people with different opinions. And you can have discussion on high-tech topics.
15:22
Edward Lloyd did, and it brought the shipping industry its first insurance company. But more seriously, what can organizations do to mitigate risks? Well, the first thing organizations need to do, I think, is to stop thinking of open source as a cost avoidance strategy.
15:40
There's a lot of free software. Obviously, if you use it, you don't have to pay for the development. That's great. But that's not the only thing that open source is. And organizations need to start thinking about supporting open source development as an insurance policy. For every euro that a company puts toward open source development, it's a euro they're not going to
16:00
have to spend on mitigation when the project in Nebraska collapses. And for every euro invested in open source buys goodwill from the ecosystem. So how can you do this? I would suggest you create an OSPO, an Open Source Program Office. This is a program office within your organization that
16:21
supports open source project that your organization is dependent upon. And then you use that OSPO. And you use that OSPO, and you hire developers to work on those open source projects. And then you can use the OSPO as a firewall between your organizational secret sauce and the open source community. And you do that by not showing your OSPO developers
16:46
the internal source code. Because if they don't see it, they don't know the IP, and they can't leak it. And the second thing you use the OSPO for is to provide technical support for your internal developers.
17:02
So if you have internal developers that are using one of these open source projects, and they run into a problem, they've got somebody within their organization, within the company, that they can go to and say, hey, I've got this problem. Can you help me solve it? The person in the OSPO, the developer in the OSPO is either going to know the answer, know somebody who will know the answer, or know where to go to ask the
17:22
question. So you can help build your software inside the firewall. So looking externally, the OSPO can be used to analyze upstream projects. So what's the community viability of all those open source projects you're dependent on?
17:41
Beyond the classic bus factor or lottery factor, if you prefer that, there are other metrics to measure community and project viability. The Community Health Analytics and Open Source Software Group, also known as CHAOS, publishes metrics for various dimensions of project viability.
18:00
The Apache Kibble Project calculates and displays many metrics in a dashboard. Your OSPO can determine which metrics to use and apply them to the upstream communities to get a measure for how stable those communities are. In addition, you can assess how open those projects are to
18:22
contribution. So how difficult is it to contribute to those upstream projects? Is this difficult enough that consideration of a replacement project may be advisable? You can also use your OSPO to analyze the existing license issues. So you can look at your internal organizations, what
18:42
licenses are being used internally by the project that they're using internally, and see if there's a licensing conflict. And then they can also look at the upstream projects and see if there are licensing issues there. And they can also determine if the process is fit for purpose.
19:02
So you want to know, is the project building a security system in a way that would allow easy injection of malicious code? Are they building a system that claims to want lots of contributions but whose process makes contributing difficult? Now, this edges up to the openness question.
19:21
But it's different in that in this case, if you have a project that wants that contributions but whose process just doesn't quite allow it, that's what you're going to find in this analysis. But you can also use your OSPO to support the upstream projects.
19:42
And you do this, like I said, by hiring developers. And those developers then work on those upstream projects. And you can either hire people who already work on those projects, people who are interested in working in the projects, or have experience working on other projects, perhaps run by the same foundation or organization, or simply developers who have an interest in open source
20:01
development. But the goal here is to ensure that upstream projects have vibrant communities supporting them. And I should note that while I talk about developers here, I really mean not just developers, but I also include documentation specialists, communication specialists, testers, anything those upstream projects need.
20:23
You can donate money to projects. In some cases, it may be possible to donate money to support one of the developers. You might be able to donate money to support the project infrastructure or perhaps donate time on organizational systems for builds or storage on your organizational
20:44
system for products that are built by the project. And finally, you can support the existing foundations. The Free Software Foundation, the Linux Foundation, the Apache Foundation, to name three, all support a number of open source projects.
21:00
And they are always open to support. So there are a number of ways that you can support open source development. You need to check with your legal counsel to see which ones are effective and which ones are legal in your area. Make sure you don't run afoul of local ordinances. So we sort of talked about how to solve the
21:22
organizational problem. But how do we solve the community problem? Is there a community solution that will lower the risk and share the expense and still allow us to reap the benefits? And this time, I think the answer really is the coffee house. And this is where you have an association of OSPOs or other
21:41
interested parties. And you create a coffee house-like environment. You're going to share the data about open source projects. So if we think about this for a moment, if you think back to that dependency diagram, there are lots of projects that need to be evaluated. But in a community effort, each OSPO only need to evaluate some of those projects, provided they can trust
22:01
other OSPOs to do the same level of research. Now there's a concept called inner source development. It's often thought of as open source development within a firewall. But using inner source development, multiple OSPOs can join together, form an inner source project to evaluate common projects that they're all dependent on.
22:23
And within that inner source development project, the data can be freely shared. The coffee house can help you select the metrics. You've got chaos, you've got kibble, you've OSI, and many
22:40
more provide metric implementations. And by working together and discussing the various benefits and drawbacks of each of the metrics, the OSPO can select the most appropriate metric for what they're trying to achieve. And you can publish the research.
23:01
So research from the inner source projects and the research that other OSPOs produce could be published. Reports like Endor Labs' State of Dependency Management or xLabs 2020 Insight Report are examples of this type of report.
23:22
So in closing, the cathedral and the bazaar are good metaphors for two popular styles of open source development Let's add the coffee house as a metaphor for supporting open source development as insurance against catastrophic failures of upstream projects.
23:41
Thank you. And I do want to note that the slide deck also contains references to the various organizations and reports. So we are now open for questions.
24:02
If you are joining us via the broadcast, please use the Please click on the chat button on your screen. And then you can add your questions, which we will then ask Claude here directly. All right.
24:20
Thank you. I assume you can hear me all right with the? It's a great talk. Very excellent. I love sort of the comparisons you brought up in this new allegory to the cathedral, bazaar, and coffee house. In particular, so when you talk about insurance, right,
24:40
viewing open source as like insurance rather than cost reduction, I think that's really interesting. One thing I've struggled with when thinking about it or trying to justify it as insurance is a lot of times organizations, they say, well, who's taking over the liability then, right? Because like if you insure your car and you crash it,
25:00
the liability of paying that off is no longer on you. It's on another organization. And so this is something I've really struggled with when trying to justify it to the organizations I work within. I'm wondering if you can maybe provide more insight about this sort of shifting of liability. I know Tidelift kind of does some stuff around this,
25:21
but I just want to hear more. I think it's more like a mutual insurance where you come together to support whatever the organization or the, you come together in mutual support, right? So in this case, I suppose you don't actually get a benefit
25:43
back in the sense that somebody's gonna pay you for this loss, but the idea is that the amount that you've spent and the effort that you've put into it is going to be lower than it would be if you tried to do it all yourself. And your risk is gonna be lower in general because you have more people trying to keep everything afloat. You know, so.
26:02
We have two questions online. So the first one is what do you think about setting up those OSPOs at the national level instead of the company level to avoid coordination issues? So set up national OSPO instead of,
26:21
I suppose nations ought to set up OSPOs so they can do government stuff that way. But it seems to me that as a, if you're looking at a business, then that business has very specific interests and things that they want supported and that they know what they need. And so they will then support the projects that they need.
26:41
And just like as you would expect government, I think that any organization understands what they're dependent on and where they need to, or should understand what they're dependent on and where they need to put their resources to help support that. Any questions here?
27:01
All right, then let's go to the next question online. I have always thought about inner sourcing as implementing open source process inside the company to avoid internal silos. I understand your take is totally different. Is it about sharing information among different companies or OSPOs?
27:24
Inner source running within a company is one of the standard models that you do that to share within, as she said, silos of the organization. But you also get multiple organizations working together
27:40
to do development. And an example would be if you had a specific, you had to talk to a bank over a specific protocol, or you had to do some sort of specific protocol that was mandated, then you might have multiple companies that needed to implement that protocol. And in that case, those companies might work together to form an inner source project
28:01
and all develop the same protocol, basically. You contribute to the same protocol, it's gonna cost them less, it's to their benefit. So inner source, I always think of it now as open source process done within a firewall. So that firewall then is those three, or those multiple companies would be fired
28:21
wall to wall from the rest of the universe doing their research, but that idea, anyway. One, yeah, go. Sorry. Thanks, Claude, great talk. You mentioned the coffee house about the bringing together
28:40
the OSPOs together to build that community. So my question is that not all OSPOs are equal, they don't have the same amount of resources, they don't have the same amount of funding. So the actual allocation of work can't be equal. I mean, how do you rectify that? How do you manage that?
29:01
Because you're gonna end up with the OSPOs that are the most funded and most resourced taking on a lot of the work. So then it's not really a community effort, it's more of a, you know, hey, the biggest, can make the biggest impact. I think, and I don't know,
29:22
but I think that if you have a bigger organization, you are probably dependent on more things. You have, I mean, it's probably not necessarily true, but I think in general this is true. So your bigger organization is going to have to, it's going to look at funding more things to begin with.
29:41
Your smaller OSPO would obviously then have a narrower band that they're going to be looking at. But I don't think it really matters, because I think the idea here is that you want to get them talking and saying, what can we do together? And so yeah, the big guy coming in is gonna have to take more to do more, right?
30:03
But if they don't come in at all, they're gonna have to do all of it. So the little guy coming in saying, I can take this one or these two, takes them off the plate of the big guy, he's gonna be happy with that. So I think that it's possible to build a community around the idea that we can all benefit if we all contribute.
30:22
Another question from online. Could you please explain the reason why OSPO should be isolated from the main product code? That seems to me contradictory to the idea of OSPO understanding the dependencies issues. The OSPO, you want to keep the OSPO separate
30:43
from your internal if you are the company lawyer. If you're in the legal department, if you're up in the management side, you wanna make sure that the secret sauce, whatever that is, doesn't leak. Because once it gets out into the public, you've lost your advantage, you've lost your company edge.
31:03
And yet, you still wanna be able to contribute to open source. So you wanna be open about what you can be open about. So to do that, you wanna build a wall. And that wall is basically the OSPO. You put all of the open source work in the OSPO, and you don't show them the internal stuff,
31:21
because you don't want that internal stuff leaking out. Now, that doesn't mean that you can't take internal work and say, oh, we're going to open source this, and make it open source. But that needs to be a decision that's made on a case-by-case basis, and that's with all the backing of the management. And then go ahead, move it over, your OSPO could support that.
31:42
But in doing this, you make sure that your IP doesn't leak. And that's the critical issue for anybody who's working in a legal department, or is looking at the higher level of management. So we have time for one last question, and then we will start the next session in three minutes.
32:07
You mentioned that not all cathedral style development excludes external contributions. Maybe could you share an example of that, and whether that could be a stepping stone for people towards more disaster style?
32:24
I think that, and I can't be absolutely certain, but if I look at Apache Cassandra, for example, that I think started as much more of a cathedral style. It has broadened its base,
32:40
but there are still some signs that it was cathedral style to begin with. And so it's sort of a mix, but it began, I believe, as cathedral and has migrated. So I think that there's an example, I think there's a whole continuum of examples there if you look across the history of that project. But that's the only one I can think of off the top of my head.
33:01
All right, thank you, Claude, for a very engaging session. Thank you so much for answering the question.
Empfehlungen
Serie mit 3 Medien