OpenJS Foundation OpenJS World 2021 - Community, 2 Jun 2021

Previous Meeting

⏯

youtube image

►

From YouTube: What is Open Source? - Tobie Langel, UnlockOpen

Description

What is Open Source? - Tobie Langel, UnlockOpen

Open source is a deep part of software engineer culture. Yet we struggle to define it clearly. Depending on who you ask, open source is anything from a set of practices and norms to a simple software license. What arguably feels like a fairly pedantic discussion turns out to have real world impact. In the last couple of years, our community has been shaken by high profile projects adopting much more restrictive licenses, which some have started to call faux-pen source. This licensing shift isn't so unexpected when you consider it through the perspective of norms and practices rather than the fairly narrow one of licensing. Approaching open source through this broader and more intuitive lens gives us much better tools to understand the whole open source ecosystem, foster behaviors that are beneficial to its community, and consistently predict bad outcomes early. We should adopt it.

Join the speaker for live Q&A on Slack, channel - #openjs_world-community_building

Thursday, June 3 from 01:00 - 01:20 PDT / 10:00 - 10:20 CEST
Thursday, June 3 from 11:20 - 11:40 PDT / 20:20 - 20:40 CEST

A

Hi everyone, my name, is tobi lanzo. I am a consultant that helps organizations create mutually beneficial relationships with open ecosystems.

A

Today, I'd like to address one of the most basic and yes, most fundamental question about open source, simply what is open source and I'd like to try and give a more nuanced answer to this question that we usually hear. So there are two reasons that this came up.

A

The first is: we've seen a rise in ethical licensing over the course of the last few years, it's being driven by open source practitioners who are concerned about how their software is used and also um we've seen a high number of high profile, open source projects, move from open source licensing to more restrictive licenses, some still open source like a gpl and some that really fall out of the scope of what is recognized by the open source initiative as open source licenses.

A

This started a few years back with redis. Then we had mongodb follow suit, more recently elastic and even more recently grafana, which moved to a gpl.

A

So if you look up what open source is you generally fairly quickly end up on the website of the open source initiative? Looking at the open source definition.

A

But what does the open source definition actually describe?

A

Well, it turns out that the open source definition doesn't really define open source.

A

Actually, it defines what an open source license is and, as you can see, this is fairly different right. This is not just a rhetorical issue, um it's not the same thing and if we were in person- and I was able to ask some of you here in the room, what are the features? um How you would define open source? You would probably say wildly different things. Then it's the license of the software corresponds to the open source definitions, 10 criteria.

A

For example, you might talk about the ability of contributing to an open source project, or maybe the community aspect of the project, the ability to work together, the ability to work in the open, the ability to learn in public the fact that the software is just freely available for anyone to use the ability to learn from others to network all of the community aspects.

A

As you can see, the definition is really broad and different.

A

People different constituencies in the open source ecosystem will have a different perspective and think differently about what open source is and what it means to them.

A

So, just looking at this, we see fairly quickly that, although the licensing aspects of open source are important, there's a whole other set of aspects that are important to people too.

A

And it's interesting to sort of like try to combine those in order to dig a bit deeper.

A

And if you really look at what all of these aspects are they're really about the norms of open source on one side and the legal licensing aspects. On the other.

A

So what is this going to look like in a two by two full quadrant diagram?

A

Well, let's simply put on the y-axis whether the license of a project has been certified by the open source initiative and on the x-axis.

A

Let's put whether the project follows or ignores typical, open source norms like the ones that we discussed before so we'll package in this horizontal axis sort of all of what makes a project feel open source the ability to be able to contribute the ability to be able to work together on a project etc and we'll put only the licensing aspects on the y-axis.

A

So what does that give us? Well, essentially, um any kind of project that has an open source certified license will be on the top two quadrants and open source projects that follow norms will be on the right two quadrants.

A

So let's now dig in to each of those quadrants more specifically, starting with the top left quadrant. This is um the quadrant, where you find projects that are open source in terms of their license, but don't really abide by your typical open source norms. um An example of this would be, for example, the android software right.

A

Android is an open source project in terms of its license, but from the perspective of all of the other aspects of open source that you would expect, for example, that the project is built in the open or that it accepts external contributions, or at least considers them not to mention things like having an open governance.

A

um Well, that project doesn't meet any of these really. The only thing that makes it open source, strictly speaking, is the fact that it has an open source license, and so um I really like the fact that some people have started talking about this and calling these projects nominally open source, I sort of think of them as open source and letter only not in spirit um a lot of the open source projects.

A

The high profile projects that we talked about initially were actually in this quadrant and have moved downwards towards the bottom left quadrant, as they abandon strictly osi certified licenses um in in favor of licenses.

A

That made it easier for their business model or that's their claim, and so this is the second quadrant I'd like for us to explore, which is the quadrant of um software, um whose um licenses are not open source certified and who ignore open source norms, and this has been dubbed open source and for open source um is essentially on projects that sort of claim to be open source um from a licensing perspective, but aren't and also really don't respect any of the typical norms of open source that you find- and this is really where you find a lot of the um open source vendors who are who really see an open source, essentially a marketing tool.

A

We'll come back to this, so moving up to the top right hand, side corner. What do we find here? We find open source projects that are osi certified right and on that follow open source norms.

A

This is really the place where you want to be, um and I kind of call those community-driven open source, but that's a bit restrictive. There are projects in that space who are not community driven, for example, smaller open source projects really belong in that space. In terms of following norms and having an open source license, but are not technically community driven, essentially because they're too small to be community driven, but the spirit clearly is absolutely there and um going down from that third quadrant right into the bottom right quadrant.

A

This is an increasingly interesting quadrant to me. Why? Well, because you find a lot of projects in that space, that respect and follow open source norms, but who don't have an osi certified license, and there might be a number of reasons for this.

A

What's really interesting to me is that category is actually um way broader right. So I I talk about this in terms of like the broader ecosystem of open source, and I also think that, in contrast with software that is open, source and letter, only um software in that space is really open, source and spirit right, even if it doesn't necessarily have an osi certified license.

A

It really abides by these norms, and I think, if you really go at the very very bottom of of that space, you want to actually find their inner source right and what is inner source well, inner source is um software. That is built internally in a company or in an organization who is not open sourced in the strict sensor doesn't have an osi certified license cannot be used by others right, but really is built using open source practices, um and so you know, and this bottom right hand quadrant.

A

You have sort of like this huge spectrum that goes from um software, that is, for example, a cco license, so public domain software that doesn't cannot be certified by the osi for a number of reasons that we're not going to get into today, um but that is extremely close to open source um in in every other way, um all through um all of the creative commons.

A

um A lot of the creative commons, for example um um the cc by non-commercial, because of the non-commercial restrictions, um cannot really fall um under the open source um label, but are really close. I mean it's not code, I understand, but from a a sort of norms and and and spirit really feels be part of this um build on uh remixing uh culture that open source really has fostered.

A

And then um then you have all of the uh ethical source software which I'm increasingly seeing as open source that is focused around.

A

Maybe smaller communities that don't necessarily um want or desire that their software goes beyond those communities and essentially want to be able to um have some degree of control over how that software is used and going down all the way to inner source, where it's really a software is really protected by um stays inside of an organization or company.

A

So to summarize and walk back through the different categories that we've defined using that um two by two full quadrant structure, um starting off where I started before, which is, in the top left hand quadrant um where open source um is and letter only um so, some projects in that space have a license that is certified by the osi, um but they really don't follow the open source norms at all. um It's really only about the license. So this is where you find projects like android, but it's.

A

This is also where you find a lot of those high prof profile projects that have moved to fopen source over the last few years, like elasticsearch and mongodb were on on this.

A

In this top left quadrant uh beforehand, I.e they had an open source license, but they really weren't abiding by the enormous that much another really common um thing that you find in this space is um open source projects where um community, the the the terms don't apply the same way to the community as they do to the project um vendor the original creator of the project.

A

um So you see this very often with gpl plus cla, where the cla, which is the contributor license agreement, actually gives um the original creator of the software extra rights and essentially the right to re-license that software as they want, and this is how a lot of projects um used to be um monetized in the past, um where um the owner of the of the gpl would actually sell non-gpl licenses to their clients.

A

Moving down from that top left hand corner, um you move to the bottom left, and this is the realm of open source right. um This is a software that really is there, because there are marketing um benefits um for that software, to sort of pretend that it looks a bit like um or osi certified open source.

A

But again here, you will not find a much in terms of open source norms moving to the um top right hand, quadrant. This is um really um what everyone thinks of and perceives as being true open source software, an osi license on the one hand, and of real community open source practices and norms, probably an open governance model or, if not, um clearly, very open um contribution uh system.

A

um So the kind of open source software that we all sort of know and really like and moving down from that top left hand corner um top right hand, quadrant sorry into that bottom right hand. Quadrant is the broader ecosystem of digital commons right, um and this includes a lot of creative, common stuff um ethical source and uh moving even further down to some degree on inner source.

A

So essentially um software um that is built um using open source norms, but doesn't necessarily have the osi certification once licensed, and so has some restrictions around usage which might be problematic for some use cases, but are perfectly acceptable for others right, and this is a really open source in spirit.

A

All right so um still using the same quadrant I'd like to offer um a different perspective on this quadrant, which is one that focuses not on the projects themselves, but actually on the different constituencies that um are part of the open source community.

A

Let's start with uh the user focus, so what's really interesting here is the perspective of a user. Around open source um is really just to make sure from a legal perspective um that they comply the license and so that the license is actually a genuinely open source license, because that makes compliance a lot easier.

A

So the focus of open source users is really essentially the top two quadrants, um so the ones where the software is certified um and to some degree, regardless of whether the software actually abides by open source community norms or not.

A

However, savvy users of open source will um check and be wary of um software that doesn't um abide by open source norms and there's two reasons for this one is this can really be open source in the making, so, um typically, if, if you've been betting on, for example, elastic for european source project a number of years ago, now, you're, probably in the position where you're not super sure what you have to do, maybe you want to rely on the fork that amazon is maintaining, so it's a bit of a um a complex situation that you probably didn't want to be in.

A

So um that is um one reason to um tend to look at not only whether the license is um actually open source but make sure that the community, um the community exists around the software um and that um the culture of the the project really is an open source one and, of course the other reason to do. This is um really from a um a sustainability, long-term health perspective of the project right.

A

If a project has a sustainable um multi-um user governance model, etc, it is a lot easier. It's um you know much better position to participate to this project, fix the things you care about, but also make sure that the project is still going to be there in two three four five six years. um So really the user perspective focuses on the license, um absolutely um and and but also savvy users focus on norms.

A

Now, if we look at open source contributors well, their perspective is fairly different right because they're much more interested about what the community looks. Like. I mean lots of people, don't mind using the beer license or the what wtf license. Sorry and why? Because what matters to them is the contributing aspect, the community aspect of respecting the norms aspect, and so really. You will find these um contributors caring more about um norms than they will about licenses.

A

And now I'd like to look at the last constituency that we're going to look at today- um and these are software vendors and while software vendors are kind of all over the quadrants, uh you will find some in every one of those quadrants um and what so, what's really interesting is to understand how their perspective differs and kind of how they're thinking about open source um in each of those different quadrants.

A

So again, in the top left, quadrant vendors are building software that has an open source license, but the open source aspect is: there is more of a marketing gimmick to some degree um than really a reason to build a strong software together, and so, when project slide from having a northside certified uh licensed to having an um a non-osi certified license their perspectives.

A

uh Changes from open source is great, for marketing to open is great for marketing right, so that's kind of where the perspective is that contrasts quite a bit um with projects that see open source, not so much as a marketing strategy, but as an engine to build really great software.

A

um For me, the canonical example of this is, of course, red hat, which really sees its upstream open source as um um a wonderful place to build great software and its role, not so much as selling on that software, but at making it um really easy for their clients to be able to use that software well for their projects, um and so in that space, um really, the perspective is open. Source is a great way to build software, so that's in the top right hand.

A

So this is osi certified, combined with um abiding by open source norms, or I mean I should say, leveraging open source norms to build fantastic software and so bottom um right.

A

Well, a lot of players in that field um actually aren't players that really care about open source but find it really hard to monetize or just concerned about monetizing open source software in that space.

A

But just don't come from that culture, so, for example, github when it started, um I mean still not open source today, but when it started really sort of felt like it was in that bottom right hand, culture which is um open source is great.

A

You want to open source as much as you want, but if you open source too much or if you open source your whole product, it's going to be really hard to monetize it, and so instead you should essentially be um open sourcing um sort of the infrastructure or the pieces that made um building what you're building um easy to do.

A

So this is um the perspective from um vendors right. um So you see uh moving from a culture where open source is a marketing um strategy to a culture where open source is really how you build um great software and then wondering about how to monetize open source in that space.

A

All right so, to conclude this presentation, really. What I wanted to show to show you today was that open source is a lot more than just um its uh license, um and this is something that that's a feeling that we all in intimately have- um and I really want to validate this feeling open source- is about community open source is about open source norms. It's about um a shared sense of purpose.

A

It's about all of these things and it's extremely important not to um reduce open source to just the license, um um and not only for these, uh some of the very personal reasons, but also for the business aspects of this, because um when you stop considering open source more globally and just consider the licensing aspects, you start missing um signals that a project is actually on a trajectory, uh or at least on a potential trajectory to becoming phobian source and and creating a world of hurt uh for um companies uh developers, projects that have been building on top of it.

A

So um there are really good signals that you can pick a pick on um to avoid putting yourself in that situation, or at least if you really have to rely on a project that is risky from a community health perspective. Do so knowingly, and these signals are essentially around those typical norms that we talk about like. Is it easy to contribute to that project? um Is the the maintainers um all from one company? Is there an open governance model? Is the project in a foundation, or is it really controlled by a company?

A

um What about the trademarks? Is there like a lot of confusion between the name of a company, uh that's behind the project and the project itself? All of these are red flags. um If, if you see those thread carefully, because um you might very well put yourself in harm's way in um the mid-term right, um but to end on a more positive note, I think it's. um This exercise is also really valuable, because it shows that one of the key aspects of open source or all of the community norms aspect.

A

This is what creates this really high quality software that we all care about and those same practices.

A

um The the same spirit of open source can be used elsewhere elsewhere to great success, whether that is inside of a company I'll call it inner source if you want to or in projects that are more restricted in terms of who is able to use them, uh for example, cc by non-commercial or ethical source licenses, um but still really carry the spirit of open source, because it's the spirit, it's these um community aspects um that we really um see value in personally and that are also extremely valuable in order to create um software.

A

That is um of really great quality. So thank you so much for your time and uh I'm happy to take questions. One more questions now and and to hear your comments about this sort of more nuanced answer to the question of what is open source. Thank you very much.