Hello everybody. Good evening. It's my pleasure to see all you here to the actually last
colloquium of this semester. At first we have to decide about the language. So our guest
is able to speak both languages, but I would like to ask, is there anybody in the room
not understanding German? Okay. So we stick to English. Yes. At first I have the great
pleasure to introduce Professor de Grille to you. I'm happy that he agreed to our invitation
to join our university for a talk. He is, as you already can read, from University of
Erlangen in Bavaria or Franconia as well, if you like. And he actually started his professional
career while he started here at this university and later went for Ph.D. to Zurich to the
ETH. How do the Swiss people speak about it? And where he did his Ph.D. with Professor
Thomas Kors in system software, but he was always strongly related to industry. For example,
during his Ph.D. he worked at UBLAB, the labs of UBS, the large bank. And later he went to U.S.
He was working with startups in Boston and Silicon Valley, but in the end Germany was
lucky enough to get him back. So he came back in 2009 and became a professor for open source
software at Erlangen University. So it's my great pleasure to have you here. Thank you.
Well, thank you very much for the nice and kind introduction. I stood close to you so that the
microphone input worked. Those in the room know, of course, we're in a computer science colloquium
because there's a bug with the software and presenting the first slide. So let me get started.
I'm a professor at University of Erlangen and have been so for the last nine years. And before
that I worked for 10 years or 15 years, depending on how you count an industry,
which is what brought me to the topic of open source. I view myself as a software engineering
researcher. And specifically, this means for my research group that we do open source software
engineering research and something called inner source software engineering research, which are
the two main topics that both academics and industry partners alike care about. And then we
have one of topics. So the idea of this talk was that I forced myself to write a paper I wanted to
write on what is so innovative about open source. And it turned out it, I should have known better,
it's just very broad. And so I have to take a broad brush and it will be a mixture
of our own research, as well as, of course, so open source industry challenges and some research
that we did for that. The four parts, four big parts, I think, where open source has been
innovative. Most of you are most who hear about open source will think about these funny or weird
or interesting licenses, but that legal innovation is only a small part. Open source has also been
highly innovative in terms of software engineering processes, as well as some tooling for software
development. And also, open source is actually quite a business or from a research perspective,
economics topic. So I will also touch at the end at what made open source sustainable, a phenomenon
that's here to stay and will even more than already dominate the industry and our own
professional life. But let me take it slowly. I intend to, what I heard, speak for about 45
minutes, 15 minutes, question and answers. So legal innovation, let me start by the classic
or one definition of open source software, which is software, open source software, software.
That software becomes open source software if it's given to you under so-called open source license,
which in turn is a category of licenses that fulfill these ten requirements. Then a software
license becomes an open source license. The key parts of these requirements is it doesn't cost you
anything to use or free. You get the source code, you can modify the source code, still use it for
free, you can even pass it on. And then some other requirements. I like to point out that
you open source software requires, or the license is required, that you do not discriminate against
fields of endeavor. So you cannot say my software is open source software, but cannot be used for
evil in the world. As soon as you say that, that's not open source software any longer because it
discriminates against particular uses. This basic definition, free of cost, modify it,
pass it on in source code, already triggered what we see today as this sharing behavior or the idea
to collaborate. This license reduced most of the friction for people to collaborate.
So there's ample research that shows how people really enjoyed sharing work with others, engaging
in work with others. And that's why I consider this basic definition of what makes up an open
source license a first innovation. May I ask, is anyone from industry here?
All right. Usually industry people get riled up or are particularly interested in the second legal
innovation of open source, a particular clause in the licensees or in some licenses called the
copyleft license. So when you look at an open source license, it has three main types of clauses,
which is the rights that's given to you, like use it for free, the obligations put on you if you
want to be allowed to legally correctly use the software, like you have to give credit to the
authors, and then some things you're not allowed to do like claim endorsement. One of these clauses
is the so-called copyleft clause, which requires that if you strongly simplifying, because I don't
want it to become a legal lecture, but that requires that if you modify some source code
that you received on an open source license or extended it, that whatever additional source
code you put next to it, depends on the coupling on a code level now, will have to be passed on
under that same open source license with that copyleft clause that you received the original
software with. This has given rise to a lot of worry in the industry in that if you use copyleft
licensed open source code in your products, for example, then you may have to lay open and open
source under that same very license, your own source code. So industry sometimes worries then
that they're giving away the crown jewels, their own intellectual property, and doesn't want that,
so for the longest time there was actually quite some fud, fear, uncertainty, doubt, strategy around
open source that you should not touch it, because you may lose your own source codes or the rights
to certain exploitation. So you may wonder then, so what, then don't touch open source. Maybe you
have that discipline not to use open source. So and first of all this is of course an innovation
of sorts, because this propagation, the intention behind this clause was indeed that as you use
software that has this clause, it forces all open source code that it touches to also become open,
so that you never face some binary again to which you don't have the source code,
with the intention that you can always help yourself. If there's a bug in the binary then
you have the source code, you can fix it, help yourself. That was the original intention behind
the copyleft license. So you may wonder why industry then touches open source code, so why use it?
Maybe obvious in an academic context, it's just good software, but you have to maybe
take a step back and ask yourself, well why is it good software? So let's go there.
Open source software components are often of high quality. If some open source software component
is used broadly, it will obviously have lots of users. If you have more users,
if you have more people looking at it, the component simply matures faster.
That's why an open source component that's widely used is likely to be of higher quality than say
something that you develop internally, or even something that you just purchased from a supplier,
licensed from a supplier, which doesn't have as many users as a well-worn open source component.
For a company to use an open source component makes a lot of sense. You don't have to go
through a purchasing process, you just use it off the web, possibly. So almost no friction
in getting to work, getting your work done, if you find the right component.
And of course the open source license says you don't have to pay for the component. That's much
nicer than sourcing a component from a supplier, where you have to pay for the license.
The secondary benefits that follow, which is well you get the source code, you can help yourself.
You're not locked into some supplier, where if you want some change you have to ask your supplier,
may have to pay for it, etc. Sometimes or today even open source components are the reference
implementation. They literally define the standard for some piece of infrastructure and it's the
behavior of the open source component that defines what the real order factor standard is.
So we are still with legal aspects of it and it is actually what sounds like a good idea
from a legal perspective, a real problem for industry, which then if you're as applied as me,
turns it into an interesting research challenge. Let's look at a simple example of a license.
This is the MIT license. It doesn't have anything to do with this copy left license,
laying all source code open. Just a very simple, one of the most simple licenses there is,
which is really nice even for commercial users. It gives you the rights to use the software,
so that is the rights grant, that is this paragraph, that's the whole license. So here's
the rights grant, you're allowed to use it for free, pass it on, modify, pass it on, etc.
There's the usual disclaimer. We don't make any guarantees. If there is a problem, you're on your
own. And then there's a small obligation. There's really just one obligation in this license, which
is the above copyright notice and this permission shall be included. The above copyright notice is
the first line. So where the author says, I programmed this, it's my copyright, I give you
these, I give you usage rights by way of this open source license. Looks simple, innocuous,
and is a huge problem. Why? Let's look at how software is built. So let's assume you're a
company and your product is on top. There's a very coarse idea of how the component,
code component structure of some software might look like. Your product sources, uses a library
by a commercial supplier and then uses just a number of open source components. Business as
usual. Then you realize that's actually layers. So that closed source component you're using,
that may be using other closed source components, may be using open source components, the open
source components you are using, that is in your build files, may be using further open source
components. Soon you realize that the reality behind it is still strongly simplified here,
a huge component graph. Anyone who built a hello world in Java and wondered why you had to download
80 megabytes of libraries from the web will know that there's a huge iceberg under the water line
in terms of code that gets included and makes it into your products. Now each box here is supposed
to symbolize one component. One component has from one file perhaps to hundreds or maybe even
thousands of files in there, each of which may have been touched by an open source developer
who put their copyright notice into the header of the file. You look at Linux, I think it's at
40,000 files with more than 10,000 developers which have spread their copyright notice all
over the text. Copyright is still quite understandable but people have used their
native language and maybe it doesn't say copyright. People don't necessarily put it at the top of the
header, they put it somewhere in the middle of the code. As a consequence, in order to be compliant
with the licenses and only then do you actually get the right to use the software, you have to
fulfill all these obligations and the simplest one already means that from a gazillion of files
you need to find all the copyright statements. So what you have to do is actually create the
so-called bill of materials. From a large component graph structure you need to derive
various pieces of information, you need to derive all the origins of all the code in there
with the corresponding copyright statements and then you know in a first step what is in your
product if you're providing a commercial product to the market. Based on that then you can now go
through the licenses and follow each clause in the license and again the simplest one is just
collect the copyright statements but that already is in some cases if you will impossible.
Nobody knows for sure that anyone has a correct bill of materials of Linux because people in the
past have copied code back and forth and it's been simply lost in time and then configuration
and inversion history and inversioning systems where what code comes from being compliant with
the licensees is something you have to you have to put effort in but it's actually really really
hard. So in a sense industry is trying to address that, industry is trying to clean up its act
meaning there's just various efforts underway to view software as a supply chain of components
that make it into a product and where each component should have a clear bill of materials,
clear statement of who provided what so that you can fulfill the license clauses. But there's a lot
of cleanup necessary as well. Well that is a nice domain for various sorts of NLP or machine
learning just to derive the lineage and history of code to determine who is to be given credit.
The processes behind that in industry are the so-called governance processes. If you're a large
company you will and you're at the state of the art you'll invariably have something called
an open source program office. That's a real job these days and your job is to help your developers
use open source software correctly in the first step and for that you have various processes.
So you will look at how do we select a component, what dependency do we introduce for our products,
is the license compatible with what we have for example can we do a copy left clause or can we
not accept that how you structure contracts for your suppliers who you source components for etc.
These governance processes are not widely understood. The top companies you and I might
think of when we think of the industry software industry do that. Naturally Google and Microsoft
and IBM have a good handle on that but you look at some Deutsche Mittelstand and which gives you
some industry industrial PC. There's a Linux in there they will barely understand that yet sadly
but we are slowly getting there. So one interesting research topic for us then is actually
that at any point of time we need some sort of product architecture model
which is actually a reflection of the code components including all that meta information
that I talked about which is usually not included in software architecture descriptions these days
which is where does the code come from, what are the associated licenses and beyond that today
many other specific things like are there any export restrictions, well that has been around
but also security issues. So that is perhaps something that open source has caused.
No product today without open source components. Open source components means they are widely used.
Crackers make the assumption oh that's a widely used component so if I'm going to look for
security vulnerabilities maybe I'll go looking for them in components that are widely used
meaning open source components and as a consequence it's a continuous stream those of
you working in security I'm sure will know that it's a continuous stream of vulnerabilities that
become known for open source components which are doing their job in products all over the world
but maybe those operating the software do know that for that component in their product
a vulnerability become became known or they don't so it's it's a very practical problem
but companies need to start tracking the components in their products at any point of time to know
exactly when to upgrade or go to the suppliers or change the projects to update upgrade some
component for which vulnerabilities became known. I guess we are doing questions at the end
otherwise if there's an urgent question please just raise your hand. I have a lot of topics so
let me move on to process innovation. As I said there's one definition of open source software
which is that by licenses so software open source is if it has that license that's actually only
half of the equation and arguably there's a second half to what is open source and that
may be even more important and that is that open source is a software development approach
very broadly speaking that at least in the words of the open source initiative which has some
sway over what is open source because they're kind of socially speaking those who accept or
reject open source licenses and on their website they say open source is a new development method
all right for distributed peer based on harnessing the power of distributed peer review transparency
of process with some quality criteria quality result results better quality in general high
reliability and if you will also philosophical statement at the end philosophical philosophical
statement at the end no predatory vendor login okay so let's look at that because that is changing
the industry not in open source but within companies as well let me get to that in steps
so how does open source develop software is it like you do scrum in a company not really
first of all open source is a two class society or an open source project is a two class society
there's a distinction between those who make contributions and those who have a right
so-called committers have a right to integrate that contribution into the main code base
in open source that's a common misunderstanding not everyone can write code into the repository
that's authoritative for some open source component but rather you have to run your contribution by
a core developer called committer basically traditionally it's been called you submit a patch
a contributor submits a patch a committer will pick it up and integrate it into the code
repository today maybe you send a pull or a merge request to some code base and then
a committer will review your merge request and will integrate it into the code base the consequence
we do have this distinction between contributor and committer where the committer are the core
developers are even if most of their work is just integrating changes and they increasingly don't do
much of the development themselves Linus Torvalds known for the Linux kernel is not
the person who does most of the development on the Linux kernel but he certainly does most of
the reviewing and integration in the end of the code base so there is a two class society which
is also how quality assurance is done it's basically pre-commit code review so you submit
your potential commit gets reviewed gets rejected or a discussion ensues and then it gets integrated
and i actually speculate though nobody will be able to show that that this heavily influenced
the google people which heavily influenced garage with heavily influenced the type of
pre-commit peer review we are increasingly seeing inside companies as well i like it
this way open source gets weirder the way people collaborate in open source is really
very different from how people work in companies so there is no single open source software
development process so we can't say this is take this or that step but there are principles
that you can argue is what makeup makes up the process of a good community open source software
project and in my book it is egalitarian participation so we don't exclude anyone
anyone a priori you make decisions based on the merits of the argument rather than someone with
status comes and decides and open source projects even choose their own processes
it's very different from how companies work in a company you join a company you get a
signed to a project you don't choose your own project like an open source as you make decisions
maybe you're a junior in the beginning and the senior guy or gal says this is how we do it
if you decide by power or status you will quickly lose the collaborators or volunteers in an open
source products you can't do that and of course inside a company a company hopes in some sense
that you're a cog in a machine because then you can be easily replaced more easily replaced and
so you become don't become expensive and the company doesn't become to be dependent on you so
company always has for efficiency reasons among others define predefined processes while in open
source people choose the process that there is no big boss telling people in an open source project
how to go about their work of course there's history and there are best practices that
migrate and you won't get to change everything because people want to keep a pattern of working
together but if you come in if you make a sensible suggestion that will improve the process you can
discuss it and it can be adopted no process definition department keeping you from doing it
which by the way for soft engineering researchers is absolutely fabulous so where I live if I were
to go to Siemens and ask them we've got this idea about how your process could be so much more
effective can we please restructure your organization to do the process in a new way
I'll be laughed out the door it's heavily it's very expensive to do experimentation and soft
engineering research with with companies an open source it's happening every day because
there is nobody who is determining from the top how to go about things so people are trying those
things that they think is going wrong at work all the time and that's why you can look at open source
it's a proverbial thousand flowers who are blooming and you can learn from that
I'm still with weird so how people communicate in open source is actually also quite interesting
pretty much all communication should be public don't hide anything it should be written so that
it's traceable and of course complete you should not not omit anything and it gets archived so it's
an mailing list archive enabling from the get-go globally distributed software development
and generally considered quite a challenge the effects of these rules which are written
explicit in some projects others only implicit the effect of these rules is that it's very
disciplined in most cases disciplined discussion that ensues that has nice properties like
self-documentation so if an open source project needs to make a design decision about the
architecture of a project or something like that it will discuss this on mailing lists publicly
for everyone to join and at the end when the decision has been made there will be a summary
email which goes into the archive and voila you have your own architecture design rationale your
decisions documented in the moment where it has the highest value for you and then archive for
future pointing back to so a year later someone comes complains why didn't you do it this way
you just point them to the archive and say this is the decision making process from way back then
that is a very nice form of documenting your work where nobody ever likes to do documentation
after the fact because it happens in the moment when it generates the most value
so here is one piece of research that we never did and it's only an illustration so this is not
not this is based on real data but it's a bit uh bit um there's some imprecision here i don't
want to get into what you can see is how many projects it's a logarithmic scale here the number
of projects of a certain size measured by number of developers and these are year lines so more than
10 years ago we had a database that was representative mostly representative of open source
and we could look at in 1995 there were 10 projects of size one developer in our database
and maybe there were there were four projects of size 10 developers so not a lot but next year it
was more and more and more and more and more and you can see how open source over the years
continuously expanded so in some sense i'm speculating that um open source projects by
their nature by the way how people collaborate without knowing exactly how that is just the
empirical observation here might be that is the hypothesis scale free that would be an important
result because it would show that in the way how open source organizes its development it can
potentially grow as this suggests here for a long time so that would be very interesting to know
the data is possibly there even though it's getting harder and harder to get a representative
picture of open source but at least the data is all out there since open source is public so you
can dig into that data so there's a lot of research around that actually the most common type of
research and open source is how do these open source project communities work why do people
contribute to open source project rather than go and go on a hike or do something else on the
weekend and also these engineering processes contributing to open source so some company
starts using then it wants to contribute comes with its own challenge the motivation is usually
that as you take in something you create a dependency on that external component that
dependency needs to be managed if they're even bugs then you want to put them back out so you
don't have to reintegrate them with each new version the biggest effect that i think open
source is presently having and how it changes companies is by way of these practices and not
by way of the licenses there's a phenomenon now called inner source which is basically the idea
that companies would have a more productive software development effort organization if it
were to use open source best practices within the company so legally speaking it's not open source
software but you're a foul model or you're an agile methods shop and now you use in addition
so it's not either or you add to your processes open source best practices and so let me maybe
explain what that means it means and that's why it's orthogonal or independent of say doing agile
or formative it means that you simply accept openness now that is not common to companies
many companies will have projects they hide themselves the project manager varies for
political reason who gets to see what's going on not so if you try to adopt open source best
practices inside the company that is to inner source you should open all artifacts so show
to the rest of the company the projects that are going on so everyone can see what everyone else
is doing even more so if someone comes along and wants to help you then welcome them rather than
ask them why are you here what are you looking at my project go away rather welcome them because
if they are coming to your project maybe they see some potential reusable component so there's
potential value in here if you take an open source approach this is what companies have reported they
say well I make my code I make my project I make my components I make my internal platform
widely visible more people are using it for the various products components in a large company
so I have the same effect as an open source my components mature faster because more people are
using it bugs are found faster as people potentially collaborate within the company
across the boundaries of the silos that you typically have where you're allocated to that
one project and that silo and don't get to see what's going on left and right as you do that
our knowledge sharing happens better across those silos we're talking about large companies so some
Siemens or some other companies where you really have a lot of business units who are
usually don't see broadly what's going on in other departments and also empirically companies have
reported that their developers are more happy so pretty much everyone these days is claiming at
least they are doing in a source it works in all kinds of specific use cases for example if
you're a platform that is used by some compose some product that product can help itself if
there's a bug with the platform traditionally product a whose component x uses component z from
the platform would file a bug report that gets triaged there's a decision when to take care of
that bug six months from now so in the next release nine months later product a will have
the bug fix and work can keep going on that's not what's going so if in that classic way then
component x will be annoyed will write more code to shield itself from the bug that doesn't get
fixed right away so adding more bad code to existing bad code an inner source component x
sees the problem it's closest to their heart so they may now in inner source because they have
access like an open source to the source code of the platform develop a bug fix compile the
platform for themselves or better yet push back contribute back to the platform
that that bug fix to hopefully be integrated much faster than going through a bug triage process
with results later the other way goes as well so you need to evolve your apis the platform has apis
those apis need changing if you follow traditional patterns you version your apis
and it takes a long time until you can finally remove that old api if you have access to your
client code within the company you can fix up your clients submit back to them please in
preparation for this api evolution here's how to change your code we did some research on how that
applies to software product line organizations this is a typical set of a product line where
you have products these kind of silos which each are profit centers meaning they are making money
in a market with a product and most of the code in these products is the same so think
uh the small uh computer tomography machine the medium size and the large one um that's
the product line three different three similar products but sufficiently different etc 80 of the
source code in there is the same and hence um they are you have this canonical now by the textbook
organization of some platform for these products who depend on that and there's a lot of things
wrong with that the textbook don't tell you yet but we know because that was our research
there's a fair bit of delayed deliveries which uh results from the platform always being
understaffed this is now an economic argument if you work for a company like Siemens or someone
else which has basically this product line organization these guys who have a product
in the market will always find it easy to hire a new person because they can argue this new person
helps us get the feature out the door with the feature out the door we'll make more money in
the market hence give us this new person the platform is always one step removed from making
more money uh as engineers as uh software developers we like the platform the more general
code but we are always one more step removed from the customer so it's harder to get more resources
down here it's a consequence um there's always too many people in the products and not enough
people in the platform organization and that leads to delayed deliveries because the task of the
platform is to provide the software that's common to all the dependent products i think
i'll speed up a little bit because then uh the companies we work with realized they wanted inner
source in between because inner source now means that the products don't only use the platform
they also send people to collaborate with the platform on the development of the
software components assets uh they care about so in the door walks the knowledge about requirements
walks development capacity and collaboratively that what inner source implies here you can now
develop the shared components that you need so the structure of product line engineering changes
because of that and we can see this in our companies so the nice thing is of course you
go to the code repositories you look at the flow of work and so we found easily um where
inner source was working well over on various level levels of the hierarchy the flow of work
or code contributions over the boundaries of those silos something that had not happened before or
was not even possible before when companies were hiding their components and projects from each
other i actually think that this is leads to a very potent hypothesis which is if you have a
large company and it's structured into business units each of them their own silo uh even today
we see that there would be lots of shared components they all want so typical thing everyone
so where i live and work there's a habit of embedded systems work everyone wants a safe
and secure linux kernel that's the vanilla linux kernel but hardened in very form various ways
depending on the industry or domain you need certain ways of certification and certain proofs
and that is used widely across the business units you could now use the traditional product line
setup create a platform organization or we just do away with it and say let's just collaborate
between the business units why am i saying that when you look at something like the apache software
foundation which gives us projects open source components like the apache web server hadoop you
can see how companies like ibm and microsoft and sap and google can collaborate on high quality
infrastructure components and there's no platform organization the the apache software foundation
last time i looked employs one and a half people to take care of some finances all the development
is by the companies collaborating and if companies like oracle and sap who fight each other to the
knife in front of a customer can collaborate why shouldn't two business units and some large company
collaborate to develop shared shared components and that would be quite the upset because the
textbooks tell us product line engineering as soon as you see commonalities set up a domain
engineering process establish a platform organization but that may not at all be necessary
so the various challenges um i want to move forward on how to actually make a source happen
maybe some of your questions might reflect that but let me move on here so open source gave us
some interesting tools just a quick remark maybe the smallest part distributed version control
so you can argue that git and mercurial this decentralized way of working was natural to
open source and also led to the creation of these new sets of tools um and you can really see how
git and mercurial are i don't know whether anyone uses cvs any longer i'm sure there is
for good reason but in general if you get a choice people move on the more interesting thing is
software forges so this is a recent this is actually from a couple of days ago a screenshot
of github github is a software forge a software forge is a web-based tools platform for developing
open source project but more than just giving you a bug tracker and a version control and what
have you for a particular project it's also in total of the place where a lot of projects are
going on and so the innovation here that open source gave us is the idea that as simple as
it may sound all the projects should be in one place at one url uh where you can find them
searchable etc this is not didn't used to be the case in companies before companies started
adopting software forges internally companies would have version control here bug tracker over there
and you would not know a way to find out whether some open source whether some software component
has been developed one time five times a hundred times within that company
a software forge is set up to make a matchmaking process happen between people looking for
components and those offering the components and you can see it by keyword-based search up there
each software forge lets you search for software by way of a keyboard keyword um it has here a
recommendation engine what you might be interested in based on prior browsing behavior it goes by
lucky chance let's show the user some projects possibly of interest not shown here is another
factor typically hierarchical browsing projects classify them you can just go by hierarchy open
source forges gave us the first impression in my as far as i can tell about social networking
constrained to the development to the domain of software engineering some 20 years ago before
there was twitter and facebook etc moving on um this is perhaps of least interest here but i do
want to make a certain point about the sustainability of open source and any student here
no students well i'm sure you talk to a lot of students so let me show that uh in a second as
well um at this stage you may still think interesting and yes open source has been around
for 20 30 or more years so it's probably here to stay but just why after all you can decide to go
home on the weekend and go again on a hike or something else or develop software and then
you're not even getting money for it why would anyone do that and so i think it is important
to understand that there is clear economic sense and reason behind open source and the way i look
at it is it's actually different high level business models if you will that make open source
sustainable um there is types of open sources so there's the traditional open source which i call
community open source that is honest community work there's a license in the middle of it that
regulates intellectual property issues and then people have processes around it they just have fun
are developing software started around or near GNU emacs or the GNU tools
linux came along postgresql the database is a great example of community open source and
there's still plenty of it um at some point of time uh people realize these are commercially
valuable software we need to protect it uh things that can go wrong is uh some developer
bus factor runs is run over by a bus and now what to do about it all developers get sued because
someone has a beef with the software so our foundations were created that shielded that
decided to stand in for the project like the apache software foundation make the apache
web server project are sustainable in parallel and ever since so developer foundations are for
non-profit i'll come to that in a second they exist to support the open source component but
nobody is directly making money of the open source component because that is freely available for
everyone so you can't directly make money off it um in parallel however there were models
uh where people were making a lot of money so i'm sure you know the linux distributors
here they are susan 92 redhead and 94 redhead was bought now by ibm but was a billion dollar company
um the details will be too much right now because but you may ask well
the nux is available for free why is anyone paying uh redhead well on the surface
this is a slide i usually use for structuring what companies sell on the surface actually
nothing that is being sold is new uh so open source did not invent some new feature or something new
that was being sold they still sell what everyone in the commercial traditional commercial business
software business has been selling like hotline support bug fixes etc um but in order to provide
that the distributors mostly what they own as the intellectual property about integration so
the complexity of linux makes it really hard uh to not just have the kernel but a full-blown
operating system uh to have that uh have all the pieces work together well that's actually
their intellectual property what i wanted to say here is what they sell you these commercial open
source companies that i'm talking about is not new what is new is why they do it the open source way
and um so if you i'm sure you've heard about you know my sql as a database as the old example
um which was a giving away at software for free one could argue as open source and still it was
another billion dollar company bought by sun microsystems then so somehow it had customers
it was just selling them this year um support bug fixes it was also actually selling them a
commercial license to the software so here's the first and interesting trick that is also color
current at least industry problem probably not a research challenge if you're the owner of some
open source you're the owner of some software code and you open source it all you're doing
is giving the world uh license to use the software for free but you're not losing your intellectual
property you're just giving the world some usage rights so uh you can take the same software as the
owner and sell a usage right under different license a commercial license to uh your potential
to your customers so that's called dual licensing you can have three licenses four or five whatever
you need depending based on what your customers want of you so there's a set of open source
companies with an open source based business model and who's anyone using mongo db redis
or common common open source components um those follow an intellectual property strategy where
they remain the owner of the software gain market traction improve their sales get good ideas about
what could be the next feature by providing the software for free as open source and yet creating
as many incentives as possible for any user to move from being a non-paying user to becoming
a paying customer and one of those moves is to make the software available to you under
the most aggressive viral copyleft based uh open source license out there so that to a commercial
user it's unpleasant to use the software it's great software you want to use it but you want
to use it commercially and now there you are it's copyleft licensed code you might have to
lay open your own source code as well so you want to use this great software but not with that
license so there's the incentive to get a commercial license from the owner who then
has to make sure that they actually can give you that second license which means
they don't accept contributions to their project unless from you unless you sign over your
copyright to your contribution to that company so um i have whole lectures on the details of this
business model because i have this world shots informatics side to me if you will um right now
it's super hot in the industry because uh apparently there is implicit consensus that
as you put this virally licensed code into cloud computing context like put it on aws
it's not clear it affects the infrastructure mongodb very much hope that amazon would not
be a competitor running mongodb on aws would not be a competitor because then amazon would have to
lay open the source code to its whole infrastructure which it would never do it turns out uh that does
not seem to be a problem so right now we see this challenge that um are the large-scale cloud
providers without particular software are becoming competitors to those with a particular piece of
software who don't have strong cloud computing operations and now these licenses are being
changed to prevent exactly that use case that is a huge problem in my book because
i forgot to say that this type of business is the one that gets venture capital this is the
one conduit how venture capital flows into the funding of open source software if you're a pure
consulting company which provides services around a community open source project your growth
perspective is somewhat limited you will not get venture capital funding but all the interesting
high quality a lot of the interesting high quality open source projects are being developed by a
commercial interest can have potentially high return on investment which is why there are
venture capital investors and they are facing exactly that challenge right now with unclear
outcome whether this model will keep working the way it is and as a consequence unclear outcome
whether that funding for open source software will still flow so let me zero in on my last few
slides i found this particularly interesting because of the substantial venture capital
funding behind it i would like to turn back to non-profits and quickly look at the open source
foundations in an open source foundation there is no single dominant company but rather there are
many companies working together so you may wonder why did Hewlett Packard, IBM, Intel support Linux
in the 90s you may think windows yes it was against windows which is correct why why were
they so worried about windows you need to look at it an economic from an you need to look at it from
an economic perspective if you have a product to sell it's built from components i'm strongly
simplifying you know let's assume there's microsoft windows and then there's your application on top
of it if your user if your customers always have to buy windows and there's no other option than to
buy windows because there's no other alternative operating system the price for windows will
increase and increase and eat all your own margin your own profits so those companies whether it
was hardware that was complementing the operating system or an application on top of it they all
wanted an alternative to windows so that microsoft wouldn't eat up all the profits that's why they
supported linux because as you can see here illustrated if you have a competitor you keep
the cost for that component where otherwise there would be an amount would be a monopolist down
and you have some added revenue potential for a higher profit so that's why the rest of the
industry if you will ganged up on microsoft to support linux it happened again um ibm started it
and the rest of the industry with the eclipse foundation ganged up on microsoft visual studio
microsoft again was in a position to run away monopolize the development tools and programming
language market on an industrial level so the rest of the industry feared that they cannot be
a monopolist there because then they will eat up all the profits so they uh started the eclipse
foundation and kept the java ecosystem going today it is open stack against amazon web services so
it's not microsoft any longer the big danger in everyone's mind is amazon web services so now we
have open stack um it's only the software part you still need the hardware when competing with aws but
fixing at least the software part is already helpful this motivates how an industry
fights back against the potential monopolist who is going to eat up all their profits
and this is what the software industry pioneered within itself
and now there's a second step that may be even more important which is what
what if this is the software industry and these are all the other industries who need software
we're supposedly a big buzzword leaving living in the age of digital digitalization software is
going to be everywhere software is eating the world as von venture capitalist said
so now what about health care companies what about logistics companies what about the automotive
companies they all need software it's everywhere and the software companies are making more and
more of the profits at some point of time you worry as a car just software driving around
where does the money go as you sell a product and so now those external to the software industry
the other industries are learning based on this model to collaborate and have the software
developed they sponsor they manage it but have the software develop as open source software
so that nobody can own that particular component the software components and eat into their
profits the automotive industry is doing it very nicely they are tech they have technology
technological affinity so they feel comfortable with technology where i live i helped create
a consortium of this kind for the network energy network distribution
divided providers so they needed software for the smart grid and that's now being developed as
open source software as well so i expect software to both be much more important as we all know
because it will be everywhere but also those who don't consider themselves software companies
but rather do something else banking health care what have you getting involved and taking money
out of the software industry by way of sponsoring and managing the development of community open
source finally my last slide no almost last slide here's what christy boner who runs the
open source program office at google has to say about the value of open source when hiring people
so we hire a large number of open source developers if you're an open source developer
you've shown you can code in the real world and showing that means it's the ultimate referral
i turn it around and say if you are a student so that's why i asked for students your github
profile is your portfolio as an artist say you have a portfolio you bring your paintings or
whatever as you show your work for a software developer it's the code you publicly wrote as
part of an open source project that's how future employers can assess your work if you don't have
that you get some coding challenges and it can also show how good a developer you are
but it's a test situation it's a small situation if you have a track record on an open source
software forge then companies can look at that and that's a long-term sustained effort
that is the best referral you can have so working an open source software simply lets the developer
reduce that uncertainty discount that you usually have in salary discussions and so
it's been shown in empirical studies how an open source position actually gives you a higher salary
but it's not just your skills are more easily validated your social competencies are also
confirmed by your peers as you work in open source projects and some open source projects
are so important that it literally means there's power and influence tied to you as a person
and that makes you more valuable to an employer so open source gives some those who
gain those positions more of a free agent status when refer when relating to a potential employer
so let me stop here that was a very broad brush hopefully not too fast discussion of what open
source is offering us in the end it was only just an excerpt but still pretty broad so I thank you
very much for your time.