As a lightning replacement, you will now hear Shlomo Schapiro on open source.

He's a systems architect and open source enthusiast working at EmoScout. So give him a warm welcome, please.

Sorry, fixed the screen mirroring. There you go. Yes.

Please excuse the wrong format. I did not prepare this. Okay. And the slides are a bit in German because I gave this talk last year at the Linux talk, Linux TAC in Berlin. But it's about the content, not about the slides.

I'm an open source evangelist at EmoScout24, which is a German real estate listing portal. And I'm there for now about five years. And I think it's a bit interesting to tell how to introduce open source in a company also on the enterprise level.

And also how to really make a company benefit from open source projects and from investing into open source. And my personal point of view has always been that open source, it's not just about enthusiasm, it's actually about solid business decisions. And my mission is to combine business mentality, business decisions with open source and open knowledge.

A few words about EmoScout. We have two data centers, about 1600 virtual machines. The company is more than 15 years in business, so we are not a startup. And our entire technology stack is based on open source solutions.

Mostly Linux of course, but also a lot of Java stuff which is almost exclusively open source. We have a lot of people, there are about 200 people working in IT in 30 cross-functional teams. So we have a lot of changes going on and we are actually big enough that we have internal open source projects.

Which is also an interesting thing how to take open source methodology into your company to get things done internally. Well, open source sometimes has gurus or rabbis or you know, the big people of open source with long beards.

But in truth, open source is a lot about money. And if you look at the open source companies today, a lot of them are actually about money. For example, Red Hat. Red Hat is the largest or one of the largest open source companies and they take a big pride in the fact that they make money based on open source.

And I know a lot of other companies, a lot of them also attending this conference, who are also actually making money out of open source. And I think this is not shameful. I think this is a good thing because in the end somebody has to pay the salaries of the people doing the work.

And to pay salaries you need money. And you know, enthusiasm alone doesn't feed your family. So that's why I think in the long term it's a worthwhile thing to do. So, why Linux and why open source?

I guess you know this idea. Linux is just a big toolkit. And the open source world is the bigger toolkit surrounding your little toolkit. And everybody who likes to tinker or play Lego or build stuff loves toolkits and tools and components. And the reason for people to invest into open source is actually to invest into your own tools.

And into creating your own perfect optimized optimum toolkit which drives your business much better than anything else you could buy. And that's the reason why your company should be investing into open source.

And that's how you can easily convince any boss who thinks that's a silly idea. Look for example at a house. When you build a house, when you want a house, you want something like that. A nice house, a castle, whatever. Something with a few windows which looks good and so on.

But then you go to the commercial companies to the proprietary solutions and that's what you get. Looks nice on the outside, like that. But then a night comes and that's what you get. You wake up at night and you realize, well, there's a monster in the basement.

Because there's no operability. They didn't think about updates. They never test updates. With each new feature, the old feature stopped to work and so on. That's what happens with so many commercial applications that we run at our site that a lot of managers started to think, okay, what would be the alternatives?

And there are alternatives, just the way how to deal with that is a bit different. Because open source usually looks like that, right? It's a beautiful house. It has a great design. It's just not finished.

And the nice thing about open source is that you can finish it yourself or you can pay somebody to finish it. And that's the fundamental difference between proprietary software and open source. And the main challenge when you talk about open source in companies is actually making

this connection from let's invest into that and let's gain some business value from that investment. And that's the biggest challenge because there are no huge companies like Oracle who will send you sales droids en masse and be happy to take your millions of dollars or euros.

They're just individual people there and you have to deal with them. And that's something which takes work and it pays to understand how the open source system works really differently than the commercial software system.

We've done this many times and we also try to talk with commercial vendors, for example Red Hat, about turning bugs into features or not seeing bugs as features. Because what happens a lot is that we submit a bug request and they say, well, that's a feature.

And if you look at the Red Hat bug tracker you see a few of our bug requests which, well, they are features. So the thing is how do you get a commercial company, a commercial partner to take you serious? And the sad truth is only with money and the even more sad truth is with much more money than you could ever dream about paying.

Just to give you a few figures, I know from personal experience that Linux distributions start to build customer solutions, meaning stuff which the customer actually needs, only after you are ready to put up several million euro per year.

So if you're big enough to pay that much then you can use proprietary software and adjust it to your own needs. If your budget is not that large then you better look into open source sponsoring.

And why is that interesting? Because open source sponsoring means you pay money into your own organization. You give money away to other people but you actually invest into your own organization. And the reason is that with open source you invest into knowledge and into features and you don't

invest into property of licenses or into having some license paper which you can paste in the wall. So any euro you spend on open source sponsoring goes either into consulting or into fixing errors.

By the way there are two types of open source companies. One they sell you an open source core which is nice and useless. And then they take license fees for the extra features. And the others they give you everything for free and they take money for consulting and for fixing problems.

I personally prefer the latter one because there I don't feel so much pressured into buying their add-on products. But I can also understand the companies who choose to refinance the open source development through selling licenses. A famous example for that model by the way is Opsi, an open source deployment and automation tool for Windows desktops.

It has an open source core, it has commercial add-on features and as soon as they refinance the development of these commercial add-on features they turn them into open source.

So I mentioned it, people. Here a lot of people. This is an open source conference, at least partially, and it's all about people. And the main thing which you need to understand when dealing with open source is you're dealing not with projects, you're not dealing with companies, you're dealing with individual people. And individual people are individual and they need individual treatment and you have to really understand the people behind the

projects if you want to interact with them or if you want to influence how the project will be developed. And as soon as you manage to have somebody in your company who sees it as their job to deal with the

people doing open source, that's the moment you will be successful as a company in utilizing open source towards your own ends. So what do you have to deal with? Mailing lists. Avoid the flame wars, they're just a waste of time.

A much bigger problem is some of the people doing open source actually do it really just for fun. Hobbyists. And that's actually a really tough problem for people like me because I've had it already. There's a great project which I would like to use and which just lacks this little tiny bit of polishing or extra feature or whatever.

I write an email to this person and I don't get a reply. I write more emails, eventually I get a reply and the reply is, I'm not interested.

Like here I'm waiving money but the people are not interested. And that's a big problem. It sounds crazy maybe but it exists and then if that happens you are a little bit out of options because then you can't use the main competence on that project, the author.

You have to find somebody else internally or externally, you can take a freelancer, ask them to work on the code and so on. It makes it a bit more difficult but thanks to open source you can actually do that. Because you can take the code, you can fork the project, you can take a freelancer, put him on it, pay some money, get the thing solved.

And if you're a business, what you care about is solving problems through money. That's the core of all business decisions. And with open source that works quite well especially if you have open source orientated companies. And I want to show you a few examples of successful corporations which we as Immobile Scout have been doing recently.

Just to show you that it is possible to find open source projects which are really good, really important, which are backed by individuals or by companies who are also willing to work with us as a company. To support their product exactly as we need it.

One thing you have to care about is the legal stuff and the legal pitfalls. Because especially in Germany there are different kinds of contracts which you can make and depending on the type of contract you pay either for the time of the person or you pay for the actual artifact being produced.

And when you pay for the artifact being produced then there's a big pitfall of warranty. And that's why many open source developers they don't want to be paid for a feature, they want to be paid for time. And as a company you then have to go with them and say okay I'll pay you two days worth of development for doing support.

You know on the contract you write support and then you actually ask them to write a feature and then it's all okay from the legal side. And I also was doing this a lot as a consultant and I always told my customers I'm supporting

you and as part of that support there will be magically a new release of my product on GitHub. Which you can then download following the disclaimers in the GPL so that there's no personal warranty involved.

It's a bit Germany legal stuff you have to know about it. Then of course your boss will be afraid. People are afraid. People are afraid of the unknown. And how do you overcome fear? You make a small step.

Let's say you find a small project where you can take 100 euro or 500 euro and get a big improvement. Something simple. Hey there's no spec file or no Debian directory for packaging. You pay the developer 100 euro, he'll add one. To make a first step to show your boss that okay we paid money, we got a result, worked out well, was great.

And then you go from small steps to bigger steps. Don't start open source sponsoring from a big project. It will fail. Because you as the sponsor in your company will not have the experience to do it right.

And then there will be problems and then the whole idea of open source sponsoring will be spoiled from starting on a big thing. Start small, grow with the experience. So, what do you need? Trust. And that's again back to the people thing.

I actually met with a few of the open source people who work on projects which we're using just in order to get to know them, that they won't see my face, that when we exchange emails, it's not just somebody anonymous but it's somebody they've met before.

And trust builds bridges. And when you have a bridge of trust, then you can actually go further and do also bigger projects. That's the stuff which is actually a very good point for open source sponsoring because nobody likes to do it.

No developer likes to write documentation. Nobody likes to work on tests which don't produce features unless you're a test driven friend like me. So, when we do open source sponsoring, all our sponsoring contracts have these things written into them.

Develop, write tests, document it and create an upstream release. And we pay actually for the upstream release. We don't pay for custom code, here's your tar.gz which you can install. That's not worth anything. Because custom code will not be maintained.

What you want is an upstream release that will be maintained by the original author as he continues to develop his project. And these are actually valid points which you can use to sell open source sponsoring within your company. Because obviously if you have an upstream release that has been tested through test automation and is well documented,

then you will be spending less internal effort in integrating that in your platform. So you save money by spending money at the development side. You spend internal effort or maybe consulting money which you would have to spend.

So that's a worthwhile investment. A few examples from my personal past. OpenVPN Gateway Builder was the first open source project which I launched commercially. And there was a customer who came to me and said, I need some handmade custom VPN configuration between two computers.

And I asked him, well, no problem, how will you maintain that? He said, I don't know, we just switch it on and it runs forever. Which as we know is not a good plan. So I came up with an idea to create a build system that would generate bootable CDs that you can just pop into the VPN endpoints

and then maintaining it is just generating a new CD. He thought the idea is cool, sponsored the project and if you Google for it you can still find it even though it's not maintained anymore. Relax and Recover was another open source project which is very successful.

It is now the defector standard for Linux disaster recovery, automated. And it started also small as a small project where I offered my customer, well, don't buy 30,000 euro commercial disaster recovery tools.

Hire me for about half of that and I'll write you an open source tool that does the same job more automated than the commercial tool. So I could do the job cheaper and better than the proprietary alternative and again an open source project which is still alive today.

And the project has since been extended and advanced through many, many more consulting projects at many customers and they're all very happy because they pay like a few days of development and they get a fully featured tool supporting their personal proprietary backup solution.

So if you care about disaster recovery check it out. The prices are really the interesting thing here because all of these were cheaper than any other alternative that the customer had. And that's the strength of open source that the initial cost of development can be sometimes even cheaper than alternatives.

And then of course the cost of further development even if it's very special for one customer is usually still cheaper than other alternatives. And the way how to market that to a customer or to your boss if you're working in

a company is basically the trick which you need to do to get open source sponsoring on the road. A few things we've done at ImmobianScout, Isinga, probably everybody knows. Hands up, who knows Isinga?

Okay, well it's a clone of Nagios, the standard monitoring tool. Isinga has been forked already several years ago and is maintained by many people around the world. But a German company holds a significant part of Isinga developers which made it really convenient for us.

Because we could just talk to that German company called Netways, some people know them, and ask them to implement a few features to fix a few bugs. For example, reloading the service took ages so we paid them some money and they redesigned the reloading code internally and then it's now done in a few minutes.

Or Subversion, probably everybody knows, again there's a company actually here in Berlin who hold a couple of Subversion developers, they also hold a yearly Subversion conference here in Berlin. And we had a few compatibility problems with Subversion 1.7.

So we asked them to fix it, they fixed it, it cost us a thousand euro and everybody was happy. And that actually was a major blocker in rolling out Subversion 1.7. And we could have spent days and days internally to try to get over that but it was much cheaper for

us to hire that company to fix the code upstream and create an upstream release than to deal with it ourselves. And another example is X2Go. X2Go is a Linux terminal server solution which allows you to create a terminal server and then access that through various clients running on Linux, Windows and Mac OS.

And we're using that in our data center to create a bastion host so you have to first go on this bastion host and then you can work on all the platform. And again, a cool product developed by a lot of people around the globe, three developers in Germany and they're doing

little fixing, little bug improvements, little features for us already for several years because we're using that on a daily basis. And it's great if we can spend a little bit money and fix our big problems which make this thing work much better. We also have our own open source projects.

Our biggest open source project is YET, an augmented deployment tool. It's our deployment chain which is completely open sourced and it manages everything in our data center, how we roll out software, how we do configuration management. It's package based so it's a little bit different from what you maybe know from other tools.

And why did we do that? We did that because as a company we learned that open source pays. As a company we learned that investing into open source pays and that sharing what you're doing is actually a benefit because you get feedback, you get patches, you get bug reports.

And that's the way how you can simply extend your internal development force with external help and of course reviews and code reviews and questions and so on. So yes, if you manage to establish open source in a company then the next step is to start internal open source projects.

And to take your own code and show it to the world and be part of the open source community. I'm at the end. I hope I managed to convince you a little bit more to use open source not only for fun but also for business.

I hope I was able to give you a few arguments to take home and I hope we still have time for a few questions.

Yes, thank you for stepping in for Kenneth and yes we will have some questions.

Thanks for the talk. So as a developer how would you try to fit some kind of custom requirement from a customer in your open source project if it's not really what it was designed for? Well this is a good question. If you look at Relax and Recover this project has been faced with that question many times.

And our philosophy is anything that doesn't harm other people is most welcome. And the code is highly modularized so that it's really easy to implement something which will be run only in a very specific scenario.

So we say please write it so that other people don't suffer from your peculiarities and then you're welcome to put your code into our project so that when you deploy our software in your environment you get out of the box a working solution and don't have to extend it with some local stuff. Okay, nice. Another question. If you are paying instead a developer who is not the author to work on a project how do you

still kind of try to make it go upstream if the original author is not interested in the patch that your guy is doing?

Well we actually in the contracts we pay for upstream releases. So in some cases we split the contract into the functional part and into an extra added money for getting an upstream release.

So that we really pay for the work of the communication with the author and of convincing the author to accept this code. Because that is actually work. And the very last thing. If you need something very quickly it takes time to get something in upstream release so how would you do that?

Well if you take Subversion as an example it took less than a week from initial contact, contract, fixing the thing and creating an upstream release. But yes the people working at this company, can I have my slides back please? The people working

there actually are part of the core team so they can just create a release if they want. Initially they told us oh we have to talk with all the team and all the project has to agree that we make a release. In the end it was no big deal.

Thank you. We have to finish and there is a general announcement following. Thanks a lot.