[MUSIC]
 So the next talk is about ancient history, or at least ancient history as far as computers are concerned.
 A long, long time ago there was a company called Sun Microsystems,
 and then they got bored by Oracle, and that destroyed a lot of great hardware,
 but it also destroyed, or nearly destroyed, an interesting code base.
 The code base that in the end became LibreOffice.
 Torsten and Bjorn are here to tell you about what happens when your code base gets bought by a huge giant IT code base.
 How the code base gets bought by a huge giant IT company, and how you survive that.
 It's actually about being bought by Lawn Mower, as the saying goes.
 So the company with the mission of destroying open source projects.
 I think we've now snipe you into actually attending a talk about a bit of a history of open office and LibreOffice.
 Welcome everyone.
 So a quick introduction, who's talking today.
 First of all, me. My name is Torsten.
 I've been with the open office project for, I don't know, more than 20 years.
 So I started at Sun.
 I got out before Oracle bought the company. I was then working for SUSE Linux,
 and I was working for another company who was serving the Linux project for the city of Munich.
 I founded my own company some three years ago, and I'm still happily contributing and working on the old code base that used to be open office.
 It's now called LibreOffice.
 And the great thing about open source is that you can change your job and take your work with you.
 Yeah, hi. I'm Bjorn. That's me.
 And I joined the open office team at Sun in 2008, and I was a very happy camper back then because I was in Sun.
 That was wonderful.
 And then this evil empire bought them.
 And yeah, so shortly after LibreOffice was founded, and I quickly did exactly what Torsten said.
 I did the same job just for a different company, namely Canonical, and started with working on LibreOffice shortly after.
 And I became a member of the board.
 So I, from the start, when we founded the foundation behind LibreOffice, just like Torsten,
 and I even stayed on the board after I quit the job at Canonical and was only a volunteer contributor to LibreOffice,
 where I was just hacking in the evening in my free time.
 OK, so I heard that people are slightly exhausted from the heat and everything, and there are lots of great talks, and now there's this here.
 So we thought we make this a little bit more interactive.
 So if you have lots of questions, ask them during the talk.
 Like, there comes a slide, you have a question or you have a comment.
 Make it. We will come running around with a microphone.
 There will be time for questions afterwards, but not that much.
 So first question. Who has been affiliated or working with one of the many projects that Oracle asked?
 Yay. One, two, three, at least. Four, five.
 That's a decent number. OK, so let's start with some how to bootstrap out of Oracle's grip.
 So, bit of history. Well, the codebase is ancient.
 Well, not that ancient. The idea is from 1985 when there was a DOS application.
 But the actual codebase is from 1990, literally the first commit in that old codebase is from, I think, March 1990.
 So it's really quite ancient. C++ timeline overall.
 So OpenOffice started in 2000. So that's also 23 years ago.
 There was lots of like tiny little forks or semi-forks over the time of that codebase.
 So, and quite relevant. I might be biased there, but it's one of the largest open source projects still around.
 It was a great thing that Sun back in the day open sourced it almost, I think, as significant as Netscape open sourcing Mozilla and that codebase.
 Yeah, so history, whatever. Sun releases that. Some changes there on license.
 So the first license was relatively commercially friendly. So IBM at the time took the opportunity to fork that internally and not contribute back.
 So for the project of that size and that relevance, I do believe that license matters.
 And in this case, Sun agreed and changed the license to LGPL, which actually then requires contributing back.
 And then sadly, they cut a side deal with IBM. So IBM could continue to use the proprietary version under a special license, which in the end, community members didn't like that much.
 So pretty much from not from day one, but probably from 2004 or 2005, there was some unhappiness in the community.
 There was also some promises for an independent open office foundation that never came to pass. So there was some bit of grumbling there.
 And of course, the project itself was very single vendor. So there was Sun and then there was a very large gap to the next contributor in terms of size.
 And then again, it was very successful in gaining traction and gaining support and being ported to any number of platforms.
 Yeah, last major release was 2008. And then this happened.
 So there was this announcement that Sun was not doing well for a number of reasons and there was a number of companies being paraded as potential bidders.
 And in the end, Oracle was outbidding everybody else. And that pretty much from day one was causing concerns.
 So Oracle was known already at the time to be very bottom line focused.
 It was very obvious at a time with a staff of more than 100, I think, 100, 10, 120 people at the Sun Microsystems open office team.
 That was looked pretty unsustainable under Oracle rule.
 So I think at least in, I think, late 2009, early 2010, all over the world, community people started looking into serious looking into what are we going to do.
 So there was already kind of community support and communication channels being axed and being increasingly hard to get someone to commit to something inside the open office team.
 So the writing was essentially on the wall. What's going to happen?
 There was a history of Oracle. There was other open source projects that were under some maintainership that had similar concerns.
 I think at the time when early 2010 already one was already, I think, under in serious peril.
 So, yeah, so overall people started to be concerned and started to think about what to do.
 And I think this is one of the first ingredients that you need if you want to try and break away.
 You need critical mass. You need critical mass at the end for users to matter.
 But first of all, you need the critical mass of people, of contributors that matter.
 If you don't have that, probably don't do it yet.
 So there was the time before 2009, there was some people who were considering putting some pressure on Sun or going at their own.
 I think ultimately probably all of those opportunities, all of those attempts would have failed because, as I said, you need a critical mass of contributors.
 You need most of the core contributors for something like LibreOffice or Firefox or something else.
 You need a number of knowledgeable people who can actually maintain your code base. Otherwise, don't do it.
 So that was suddenly there was this opportunity. So there was a way with lots of people in the community being concerned.
 That's an ingredient number one.
 One example question I would like to ask the audience. Who here knows and uses Hudson CI?
 Example.
 Who uses Jenkins or knows about Jenkins?
 Okay, Jenkins is just Hudson without the trademark name because Hudson was a project by a Sun employee who did that mostly in their free time.
 And they fired him, if I remember correctly, and afterwards told him, your project has to do this, that, and this, and that, those ways after they fired him.
 Otherwise, you can't use our trademark.
 And then Hudson became your name, which was Jenkins. So that was a bit of a foreshadowing for things to come.
 Right. So and that's the second ingredient. So if you are end user focused, you bloody need a name.
 And if you don't have a name, you very quickly need to make your name.
 So and then there was another one of the problems that actually Sun at the time and then Oracle held the trademark rights for open office.
 So that was out. Right. So that caused quite some headache and some planning there.
 So you need critical mass. You need a name.
 And you need something actually that people can, at the day when you announce that, you need something actually there.
 You need some some bits and binaries to download.
 So all of that taken together.
 What happened then was that all those people around the world were coming together.
 It was very conveniently.
 There was a very last open office conference in September 2010, and everybody was there anyway.
 And it was my first conference.
 And I was very happy to be there and be at this huge event. It was my first open office conference.
 And these guys did other things than talking about open office.
 Yes, so we wanted to meet like privately, but it was this kind of Oracle run event.
 So we all had a stomach ache one evening and we didn't go for the river cruise.
 But everybody like surprisingly, everybody had a stomach ache. There was nothing wrong with the food.
 But we all came up with the same excuse.
 We met in Budapest for some conspirative dinner and hashed out and hashed out the not the final supper.
 You know that I'm not in there.
 I didn't know, well, except for everyone having a stomach ache, I didn't know about what they were doing.
 But clearly they were doing something.
 So we actually we hashed out that so we launched on September 27.
 So there was like looking each other into the eye and like committing to it.
 Like, yeah, we're going to do that.
 And we had people from Linux distributions.
 We had lots of volunteers there.
 We had quite some critical mass, I would say, at the time.
 And we sat there for dinner, had some good meal and some wine.
 And we looked each other in the eye and said, yeah, we're going to do that.
 We go live and then prepared everything like, yeah, whatever.
 Lots of nights hacked and websites prepared and downloads and binaries prepared.
 And we set up a mirror system so that when we hit the go button, that we wouldn't like,
 I don't know, all those 20 people start downloading liberal office,
 that the mirror infrastructure wouldn't actually break down.
 It wasn't more than 20 actually.
 It might quite a splash.
 So that's probably so when you have critical mass,
 probably you have some people with some marketing experience, with some press contacts.
 And for something where you need to make your name, that's the fourth ingredient that really matters.
 So from day one, you have to be in the press for a while because nobody knows you.
 So people need to read about you for a little while.
 Right. So we went on.
 And we actually asked ourselves the question, is this a dot?
 So is this going to fly or not?
 And of course not.
 It's a fork and a successful one.
 So yeah, we went on, announced, went live, had some, I think, I don't know, some,
 I think the first month, I don't know, I don't have that number,
 but it was not shy of a million, not much lower than a million downloads, I think, in the first month.
 And for something end user, like give the people something to play with.
 Okay. Going on.
 I'm going to speed this up a little bit.
 So anybody remembers those days?
 So we actually were quite lucky.
 Like everybody remembers like Heizer writing about that?
 Yeah, that's great.
 So I think that's super, super lucky there.
 And of course it was like fitting the narrative like Oracle bad.
 And so it was kind of helpful to be at that moment.
 But that's probably the fifth ingredient.
 Like use the moment.
 You will know when the moment has come and then jump and don't hesitate.
 Just fucking do it.
 Right. So then, well, actually then we did it.
 And then actually the problem started and the work started.
 So before that was all kind of theorizing.
 But then actually we had to start working.
 And we had to change from something that was sun funded, sun promoted, sun owned,
 and then Oracle owned, to something that was completely community run.
 So from this umbrella, there's someone holding the umbrella and paying the bills
 to something where you actually are thrown into the cold water and you have to run it yourself.
 And trying to actually make a difference and using this momentum that we had from that day.
 And the momentum was actually also on the development side.
 That was essentially 10 years of pent up demand when people wanted to change something
 and sunset, no, whatever.
 And our engineering quality standards prohibit us from doing this.
 So, yeah, I don't know.
 Sun was kind of still a bit corporate and this was community and people just wanted to break free and hack.
 And that's what they did.
 Right. So that's a bit of the commit history there.
 So you see there's some pretty much coming up from zero.
 The blue top there, that's Oracle.
 Open office committers.
 There's almost nothing else when we started.
 So almost all development was actually done by sun engineers, Oracle engineers.
 And then you see this explosion, this Cambrian explosion there of people starting to contribute.
 You see Christmas, that's when people take a break.
 But it recovers from there on.
 Yeah. So lots of things that we did that led us to being on every Linux distribution,
 that led to trade press likes us because we had lots of feature releases that could write something about us.
 This release train thing is quite important to actually lay a different foundation for the community or the contributors
 because in the release train, everyone has like the same influence on when something is released.
 Namely, not at all because it will be released by a specific time.
 And at Sun Oracle, it was always, yeah, I spoke to a release engineer once at Sun and he said,
 "Well, I always take vacation on the release date because I know that it's not going to be released on that date.
 So because it would always be delayed."
 So there was a privilege in Sun Oracle to set the release date at whatever they wanted.
 And all the others didn't have any influence.
 And the release train actually made all contributors equal and their influence equal.
 You had to get your feature in by a specific date and if not, well, then in the next release in half a year
 or in a feature fix release just like everyone else.
 So there was no special treatment there. That's quite important actually.
 And then Oracle threw us a curve ball, that one there.
 So they shut down the open office team and contributed the project to the community,
 which had already moved on.
 So they found another community to contribute that to and donated it to the Apache Foundation.
 The upside of that was that LibreOffice could relicense.
 So the code was then suddenly available under the Apache license.
 Also Oracle had fired everyone working in there.
 Like everyone that was working on open office.
 Just five people were rehired by IBM.
 But that's just a side note.
 So they donated the project after firing everyone.
 Right, they fired everyone and then they donated the project.
 So I think in hindsight we did the right thing with forking.
 Of course it would have been nicer to agree beforehand so there wouldn't be two competing projects.
 Hard to say.
 Alternative histories.
 I don't know.
 So as I said, the upside, and there are quite some upsides, is that LibreOffice could relicense.
 And so we are now under MPL, which is slightly better, we think,
 from how LibreOffice, with extensions and everything, is built.
 So it's slightly more business friendly.
 So if you add a file, you have to open source that file.
 In MPL it's like you change the file you have to publish.
 And if you add something like new files and functionality, then in theory you can keep that proprietary.
 So there are upsides.
 And of course the open office project, there's lots of friendly people there that we meet frequently at conferences.
 But of course at the time it was quite a problem.
 Because then of course there's this, well there's now two projects.
 So who's the trade press going to celebrate?
 And who are the, like, if you want to hack an open source office suite, where are you going to go?
 I think in the end that turned out quite alright.
 So if you look at the contributors, this is a scientific paper that had a bit of a look there.
 You see quite some overlap.
 So you actually see people committing on both ends.
 But you also see how relatively small that is.
 And for something as 10 million lines of code or 8 million lines depending on how you count,
 of course number of committers actually matters to make a difference.
 So in the end it was mostly this where we ended up.
 I think both places have a point.
 Of course having some nice solar roof is nice.
 I like to be living on that side.
 And finally, and then I will hand over to Björn with a bit of take home messages
 and actually actionable content like what to take for your own projects if you want to fork.
 So we had this little foundation thing there.
 So we actually promised to have a foundation.
 And someone said foundation in German means Stiftung, so let's have Stiftung.
 And actually that was, nobody ever did that.
 So we had to figure out how to do that.
 And we did it in Berlin, which is cool.
 Berlin, I love them.
 It just took a while.
 Also, the lawyer you see there, we can make him an honorary hacker
 because he made Stiftung to be something that was never done before.
 Namely that its leadership is democratically elected by the contributors.
 No one ever did that.
 And Berlin was very, huh, what's that?
 When that came up.
 Berlin was like, what's that?
 Well, actually, why not?
 Yeah, but it was something very new and done the first time there.
 Right, so there's lots and lots of things to say about that foundation thing, but I'm not.
 If you are curious, hit me up after the talk.
 So let's hand over, so there's lots and lots and lots of numbers and lots of conferences.
 And actually the project is actually going strong and growing, which is just awesome to be a part of.
 It's now actually able to attract about one and a half million euro of donations a year.
 And with that, able to sustain a substantial number of people, both like hired staff that run the foundation
 and that run the infrastructure and that run the bills and releases and do mentoring and all of that.
 And also like to fund development, both with internal developers and with tenders, like tendering that to the ecosystem.
 Right, and that's that bit. Any questions so far?
 Just out of interest, did any of you work on Star Office?
 Maybe 4.0 or something?
 Because Star Office was always a product, like there was always this, there was single vendor open source.
 You had open office and then you had the proprietary version of that, dual license if you will.
 So Sun had a contributor license or copyright assignment.
 So they were able to sell Star Office under proprietary terms and did that till the last day.
 Yeah, I did so too. And it was wonderfully harder to build because it didn't have open source contributors
 making the build even easier back then. And LibreOffice made it a lot more easy for people to actually contribute.
 So open office was already hard, but Star Office was way harder to use.
 Because it was internal and we can't treat our developers like that.
 Yeah, I don't know. I think many of you are working on software.
 So do you agree with that difference between if it's open source and you get contributors, actually making things easy and nice and fun matters,
 but internal projects somehow not. Is that generally the case?
 Yeah.
 Yeah, yeah. It's interesting. So it's great to have one of those great things with open source.
 So go contribute to open source. The fun is there.
 All right. So let's go to the boilerplate and some stuff you might find interesting, horrifying and whatever when you start a fork.
 Like licenses, ownership and CLAs, contributor license agreements, codes of conduct, brands, statutes and donations.
 So what of these things are important? Is it important to have a license?
 General agreement in the audience. Is it important which OZ approved license you choose?
 I would say not so much actually as who owns the code.
 For example, if you have to contribute all your code to one company or one entity, they can change the license.
 And well, HashiCorp did that recently, like last week with Terraform.
 In that case, the license isn't that important because if you're not owning it anyway, they can change it at any time.
 So yes, it's important to have an OZ approved license. Which one is not that important?
 So just choose one of the OZ approved ones.
 Yeah, I think that's really one of the many take home messages. Go with Borg standard stuff.
 Don't reinvent anything that does not matter for what you really can do, which is hacking on code.
 So run with one of the three most prominent OZ approved licenses.
 Which one actually does not matter that much if you want to fork?
 Probably you can't change the license anyway, so just run with the license you've got.
 So in hindsight, we had this discussion in 2010.
 In hindsight, I don't think the license fundamentally matters, except for the case that, of course, your project needs to agree.
 So it's more like the underlying basement, like how your community interacts.
 Like if I contribute code, what am I getting back? What are others getting out of it?
 So in a sense it matters, but not greatly. What matters is not alienating your contributors.
 In that way it does matter.
 And going beyond that, what is true for the license is even more true for the code of conduct.
 If you want to write your own, your contributors will spend two years fighting each other, hating each other in the end,
 and not talking to each other and not coding.
 So just take one of the existing code of conducts and use that.
 The importance is really to execute on what is in the code of conduct and not each single word in the code of conduct.
 Brands and donations, that's also quite important.
 If you want to have donations or if you want to have money or users, then the brands are important.
 Because when Liber Office started, well I say we, you, you had the contributors from the first day.
 I was joining half a year later.
 But the users, there are still lots of people using OpenOffice, even though it's like there's not even a cow to ride on anymore.
 It's so dead, or a horse to ride on.
 So brands are really important if you depend on the users in some formal way.
 And that's surprising.
 I mean, I don't know, so as a geeky person, I would always like, why does it matter?
 I mean, why do I care how the thing is called?
 Is it bleedingly obvious that this gets more contribution than that?
 So I'm going for that.
 But of course, if you're end user focus, that doesn't work.
 So I mean, I don't know if you make the experience as well, how strong brands are and how much that matters.
 Once you have an established brand, you're up against.
 But don't underestimate that.
 Also the longevity.
 So OpenOffice is still getting, I don't know, a million downloads or something a month.
 Okay, let's go on.
 So we have this wonderful title, an aging organization.
 We fought ten years ago.
 So what did we learn?
 So let's quickly go to the next slide.
 Ten years ago, roughly, we set sail and everyone was agreeing on which direction to go.
 And it was roughly something like this.
 Yeah, we want to promote open source and should be free.
 This is actually the English translation.
 It says free of charge.
 The German one says freie Nutzung, which is not explicitly free of charge.
 So there's already some things in there that might be misunderstood or understood differently for different people.
 And how many of these are the words that you can have epic discussions ten years after about?
 And the interpretation of these words, everyone agrees on the sentence that was there in the beginning, but not everyone agrees on what they mean.
 And that might actually, that means that it's really important to get a shared understanding what you're aiming for.
 And still have that renegotiated if the environment changes, if something like cloud productivity becomes a thing and so on.
 All right.
 So what should you take care of when you do something like that?
 You built the ship of TSLS and you exchange things on the deck.
 Well, the things you should quickly exchange is, I don't know if you can see that, but it's technology and being able to work in different environments.
 You should also not always like directors like me should not stay on the board for eight years and like you not for longer.
 But that's, we kind of had the problem that we don't have enough candidates.
 But still, you should exchange people and there should not be single points of failure and people being like having power just for their role.
 But the things that should be internal should be principles like do as decide.
 Freedom is important like freedom in freedom as in beer or freedom as in freedom.
 That you fight lock in and monopolies and that you want to have your project sustainable and open and diverse and things like that.
 And we did not succeed in everything we say there.
 I mean, there are two white guys standing on the stage here.
 But still, it's important to have the principles to be there and everyone having a shared understanding about them and being flexible about the rest.
 The stuff that is more to the right.
 Yeah, and quite indeed.
 And that's like for longer term projects, the only constant is change.
 So make sure you can change.
 There was a bit of a problem, there is a bit of a problem because some things can't easily be changed for a number of reasons.
 Once you've set sail and went on.
 So the ship of thesioids is a great metaphor.
 Just that you can't change anything that is below the water line.
 And that's quite a lot for liberal office.
 Yeah.
 So what you get is you have a vision, a mission, something where you want to get to. And then you have holographic superpositions, which is what everyone thinks everyone else agrees upon.
 But maybe not everyone is agreeing on.
 So how can that look like?
 And I have one example.
 The next slide is not by me.
 It's by Italo who does liberal office marketing.
 Awesome guy.
 And it shows you like how the liberal office project has different strata strata of people like the core people are people who are being paid to work on that or are working on it as if they were being paid.
 That's a cough.
 Maybe 40 people.
 And then there are regular volunteers and occasional volunteers and a whole lot of people who are not in here.
 People doing user experience, QA, translations and stuff like that.
 So there's different things.
 And everyone has different perspectives on this.
 And I want to give you like the comic version of can you give me the next?
 The comic version of a developer point of view, which incidentally might coincide with my view when I'm unconstrained by being on the board and just talking for myself.
 And that might be the most important part is the project.
 I want to win new contributors, more people who develop on the code.
 I want to have innovation.
 I want to build new things.
 I want to have liberal office like Google office in the cloud and stuff like that.
 I want it to be free as in freedom.
 That is everyone should be able to innovate on top of it.
 And I want to have the business stuff that works on it to be actually in the product like someone building new things on liberal office itself.
 Like below the line that is actually part of liberal office.
 And then you have again a comic version of someone who might be further apart from the developer perspective.
 And that is something like, yeah, I want to have more users.
 For example, this is a perspective of someone who's doing trainings for liberal office.
 Then obviously that is very important.
 And the corporate actually doesn't need to change that much.
 It might just be well enough to just be well maintained and get security fixes and stuff like that.
 It needs to be free as in beer.
 That is should not be like cost money.
 And the business cases are built on top of that.
 So I'll take liberal offices as an existing product.
 And I sell stuff on top of that.
 And in the end, next night, you want to have something like this.
 You want to have the community create more users from which you can recruit new contributors, which again makes the product better.
 And maybe even create new use cases for the product which creates more users and so on.
 So you should balance both of these perspectives.
 And in the Document Foundation, we have a democratic process where everyone votes and everyone has the same vote.
 But the thing is you have to balance these points of view.
 And if you leave ten core developers in a room, they will come up with one perspective.
 But you always have to bring these perspectives together so that you are not having only one side of one view on the project and the product.
 So that's really a challenge that grows over the years with your community getting older and seeing more of these challenges.
 So this is the summary within one in the title.
 There are two things here.
 If you want to have users, actually the brand is really important.
 For getting users, LibreOffice as a brand is hugely important.
 For the contributors, the brand, you could fork tomorrow into something called something else, maybe Go-O-O or something.
 And no one would care.
 But if you have a good brand name, that actually gets you the users.
 And if you care for the users, that's important.
 The same for the contributors in a different way.
 Because for the contributors, the project is really important.
 What can I do?
 What are my options to grow in this thing?
 Right.
 So this is essentially the essence of it.
 So I was listing five important things earlier in this talk.
 But many of them flow out of those two.
 You need a name. If you don't have a name, have the means to make a name.
 Like make a big splash, make sure you get lots of attention.
 You need contributors, of course.
 So take your contributors with you.
 If you can't, be prepared for a rough ride or have some means to create a new community.
 Those two are the most important things to have.
 If you don't have an answer to those two questions, don't fork.
 Yes.
 Let me read that because it's, I think, not visible with the sun.
 Forking, we can help.
 Come and ask us.
 Thank you.
 Thanks so much.
 Thank you, Thorsten and Bern, for a great trip down memory lane,
 and also very practical information about open source projects and how to survive being borked.
 Any questions?
 Thank you.
 Have you already thought, I mean, before you have thought that maybe OpenOffice would be the winner in the game?
 So I was at OpenOffice at the time, so I had no thoughts in that regard.
 You got to answer that one.
 Yeah.
 As I said earlier, so this is hindsight 22.
 That's hypothetically maybe.
 It could have changed something.
 At the time, we were absolutely convinced that if this becomes known, that Oracle would play this divide and conquer game
 and go to many corporate friends and say, well, your database licenses are priced like that,
 and maybe you want to change your mind so that they price the same tomorrow.
 So we're really, really afraid that they would pick out those like in particular corporate sponsors of the liberal office project from the early days
 that actually contributed a lot of development resources that they would be not available or gone or sitting on the fence.
 But yeah, as I said, hard to say what would have happened.
 Hello. Yeah. Did anyone stay in Oracle for long enough to actually make any friends there out of all the developers obviously been there for decades
 and maybe tempt some of them over to the bright side?
 So I left on 1st of February. I was at Canonical. Six weeks later, everyone at Canonical was fired, at Oracle was fired.
 So a lot of those who were still with the company at the point that I left were there just for six more weeks, were not allowed to move over.
 And then Red had hired quite a few of them and they became quite valuable core developers in liberal office.
 But obviously we could not in the liberal office ecosystem like hire everyone who was just fired. We would have loved to mostly.
 But yeah. But actually we managed over the course of the years following.
 So we had to start from somewhere and that was quite constrained.
 But actually we managed over the course of the years to pick a few more from those former core developers down.
 And so I mean there is with Oracle, I mean so there are great people at Oracle to this very day and like very, very good open source people to this very day.
 So of course it's a bit of a black and white comic strip villain thing that we painted here and apologize for that. But it makes for great talk.
 Yeah. Also it's a good idea to talk to Oracle people if they are at FOSDEM or something like that where you can talk about the projects and not about the company.
 And they might be more interested in like the things you share and not the things that like I mean don't make them defend their company. That doesn't help anyone.
 Is there anyone working for Oracle here?
 One last question.
 So my question is in recent days there have been a lot of mutes from companies against open source projects.
 What is your take? How could these projects like how could open source be more, could be better for the company so that they share this common vision in the future?
 Like how could this, so what incentives would you have to set? That's basically my question.
 Well it's a bit tricky to see all of open source projects but I think you see quite a few of those projects that were open sourced and were closed sourced now or in some way moved towards that.
 It might have been always the plan of that company. If that's a venture capital company that wants to grow big that might always be the plan.
 Because open source is not a business model.
 Yeah so the thing you need to do and this is what we were talking about here too and we had in the foundation statues is to make the project sustainable. And that means it needs to, also for the commercial entities, it needs to be relevant to be part of that.
 And there are actually very few projects who did that. Apart from LibreOffice I think Linux is one of the projects where it's really multiple contributors from all over the place.
 They all have very different use cases and that's why it works. So many people have so many use cases that their shared work is more valuable than if they would do their own thing.
 And you need to find that thing to make everyone have a shared interest in the thing.
 So open source helps tremendously for getting very, very widely distributed. Like ubiquitously distributed everywhere.
 It also helps attracting contributions if it's accessible, if it's well done. But it's not a business model.
 Yeah as Bjorn said some might think that for venture capital the idea was to get onto everybody's machine and then cash out.
 For LibreOffice we already had all of that there. So we had existing business models that could continue. We could fine tune that.
 We could find spots there. Of course we didn't need to feed 120 people which was sad at the time but it also made it slightly easier to keep things going and growing over the time.
 Thanks a lot Torsten and Bjorn. Thanks for your insights. Let's give another round of applause for Torsten and Bjorn.
 [Applause]
 [Music]