Building a business on open-source applications
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 39 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/67216 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Open sourceBuildingOpen sourceCartesian coordinate systemSoftware developerEvent horizonProcess (computing)SoftwareService (economics)Sound effectCore dumpPerspective (visual)Open setDuality (mathematics)Product (business)Electronic mailing listCombinational logicInteractive televisionCodeClient (computing)DivisorLatent heatFocus (optics)Projective planeMobile appConsistencyMereologyFreewareComputing platformStreaming mediaSinc functionBuildingNumberMultiplication signFrequencyTask (computing)Business modelWeb applicationVideo gameSoftware bugPoint (geometry)Software industryRevision controlTraffic reportingRight angleLibrary (computing)Universe (mathematics)Goodness of fitModel theoryDatabaseForm (programming)Compilation albumSoftware frameworkType theoryFunctional (mathematics)Plug-in (computing)Wave packetAdditionConstraint (mathematics)Direction (geometry)Reading (process)Vector potential
09:27
Endliche ModelltheorieOpen sourceCore dumpOpen setService (economics)Software as a serviceEvent horizonService (economics)Type theoryComponent-based software engineeringMobile appCombinational logicModel theoryLibrary (computing)Projective planeFreezingFreewareUniverse (mathematics)Business modelWeb 2.0Product (business)Direction (geometry)Different (Kate Ryan album)Chemical equationSlide ruleException handlingAsymmetryLevel (video gaming)Server (computing)OSI modelRight angleAreaOpen sourceMathematicsMultiplication signPerspective (visual)System callFocus (optics)Point (geometry)CASE <Informatik>NumberCodeStreaming mediaPlanningShared memoryDesign by contractAnalytic continuationSoftware developerConsistencySocial engineering (security)Event horizonOnline helpComputing platformSummierbarkeitSoftwareCore dumpVirtualizationOpen setComputer architectureMereologyDuality (mathematics)Cartesian coordinate systemGraph coloringCopula (linguistics)Plug-in (computing)Computer animation
18:51
Hybrid computerComputing platformEvent horizonVirtual realityOpen sourceSoftwarePower (physics)Projective planeCASE <Informatik>SoftwareFiber bundleDecision theoryOpen setPoint (geometry)Degree (graph theory)Service (economics)Endliche ModelltheorieBusiness modelLibrary (computing)Web applicationMultiplication signData structureSoftware developerDifferent (Kate Ryan album)Streaming mediaComputerLimit (category theory)Sound effectForcing (mathematics)Category of beingSingle-precision floating-point formatServer (computing)Self-organizationBitEvent horizonCodeModel theoryAnalytic continuationBoundary value problemStack (abstract data type)Product (business)Integrated development environmentData conversionRevision controlRow (database)Sheaf (mathematics)Touch typingInformationOpen sourceLine (geometry)Video gameEnterprise architectureSoftware bugType theoryPerfect groupCompilerDivisorScaling (geometry)FreewareRight angleComputer animationMeeting/Interview
28:14
Open sourceComputer animation
Transcript: English(auto-generated)
00:04
Thank you everyone for joining in on my talk about building a business on open source applications. As Sven said, my name is Raphael. I'm an open source developer and I'm also the founder and CEO of Rami.io, which is a small software company consisting of currently 13 amazing people
00:24
and together we're building a number of software products. One of them is Venueless. If you're joining live for FOSS Backstage and not viewing this as a recorded talk, you are currently using Venueless since it's the platform that is handling the streams as well as the chat and everything you're currently looking at.
00:42
One of the other products we offer is PreTix, which is the software that you use to get your ticket for FOSS Backstage and get in here. And the third one is an Android app for interfacing with public and university libraries. All of them are open source or connected to open source
01:03
at least in some way. We will get into the details of that later on. Before we do so, there is the question of why and we can ask the question of why from two different perspectives. First, from the perspective of an open source developer, why would I be interested in doing business? So the main idea is that it's one of multiple methods to ensure long-term
01:26
consistency and sustainability of a project. You maybe experienced this yourself at some point. You had a problem in your life or in your work. And to solve that problem, you started writing code. And at some point, you published that code as open source software. And it solved your
01:43
problem. And you saved a lot of time because of it. And you also invested some time. And it maybe was fun. And then your problem is solved. And at some point, you noticed that you've not only solved problem, you apparently also signed up for the task of maintaining that code now. And people are coming to you with bug reports. You need to
02:04
read them, review them, answer them, fix bugs, review code contributions, and so on. Which also can introduce a lot of work that you might not have the time for because you've gone on doing other things in your life or working on other projects. So the building part
02:20
of software is often fun. And the maintaining part can also be fun. But it's much harder to find the time for. And with doing open source or with turning open source into a business into a day job, you allow yourself to allocate the time and get focused resources on the project. Also,
02:43
depending on the kind of project, not all tasks can be crowdsourced to many people. Some tasks like project design or software design benefit from the same person doing them over a long period of time, which is much harder if you do not have someone who can focus on something.
03:03
There is the saying that if one developer can do this in one month, then two developers can do it in two months. And there's some truth to that. So some consistency and some focus on specific people in the team can be very useful to the project as well.
03:21
Asking the question from the other end, why would we do open source as a business? Isn't that harmful to doing business? There are some interesting reasons as well. For me, as someone who's been socialized in an open source community, part of it is that it feels to be the right thing to do.
03:41
I believe in the core values of free and open source software and doing this as part of my business endeavors allows me to follow this passion for open source software in a way that is sustainable. But there are also more businessy reasons for it. It can be a great factor in building trust with customers. Especially as a very small company, you often experience that large
04:05
clients are hesitant to sign on with you because they fear that you, being a small company, will be no longer around in a couple of years because you lost interest or gone out of business or something like that. And with open source software, we can tell clients that our product
04:22
will survive us in some way. So even if something happens to the company, the technology will still be there and they can find someone else to continue maintaining it or they can just keep it running for long enough to safely migrate off to something else. Then there's also the benefit of contributions. This should be very trivial to understand. With a business perspective, people
04:44
might come around and contribute to your product for free. How amazing is that? It of course also introduces work. You need to review that. You need to engage in discussions and so on. So it's not always net positive from the pure work side, but there are very interesting side effects to it as well. Having outside contributors is a perfect way to get to know
05:05
potential candidates for hiring. You will learn so much about them during the process and about the quality of their work like you would never do in a job interview. And the other way around as well, potential candidates learn a lot about the quality of your code and the quality of the interactions around it so it can make you a very attractive employer.
05:27
So with these reasons to combine open source and businesses, the next question that we need to ask is how to do that. And this is certainly not news to many of you. Many of
05:40
the typical business models I'm now going to list have been around for decades, but it makes sense to quickly review them. One of the more popular models, at least until some time ago, was the dual licensing model where you publish your project under an open source license that has
06:01
some strict constraints. For example, a strict copyleft constraint. And at the same time, you offer clients who do not like these constraints a commercial license for the software. A second model is sometimes described as the open core model or the add-ons model where you have a core product that is an open source project and then you have in the open core flavor you
06:25
have a larger version that contains more functionality that is not open source or in the added version you have additional add-ons or plugins that can be installed next to it to enhance the functionality. Then there are the business models of providing professional services
06:43
such as support services, a guarantee on bug fixes, trainings, customizations for specific clients and so on. There is the approach of offering a software as a service, a hosted service of your application or product for people who do not want to deal with running it themselves.
07:02
Then there is the business model of selling books about your open source project and finally any form of donations, corporate sponsorship, crowdfunding or events. To give some examples, a popular or well-known example of the dual licensing model would be the QT framework. Well-known open core project would be GitLab. The add-on model can be seen in WordPress
07:27
which is an interesting example because not only the creators of WordPress but many many other parties as well are able to make a living within this WordPress add-on ecosystem. Then for the services model I think the SQLite database mostly works based on this model. GitLab again would be
07:45
a good example for the software as a service. I don't have a good recent example for selling books and there are many examples for accepting donations or sponsorships. For example the Django project and the Python Software Foundation generates lots of revenue through running the PyCon
08:04
developer conference so that would be an example of making money with running events around your project. Of course all of these also have some downsides as well. Using the dual licensing approach you're kind of leaving the moral high road of free software philosophy and you're
08:23
creating an asymmetrical relationship between the community and the company running the project because the company will hold more rights to the project than the general public. With the open core approach you risk some conflict about what features get in the open source part and which
08:43
features not. Often it's typical to put very enterprise-y features like compliance features into the non-open source part. With the services model the problem is that it takes a lot of time away from your actual product development because you're usually only getting
09:03
paid for those services like you're getting paid for the hours you put into support or for the trainings you give but those take time as well so you're still not actually getting paid to work on your main project directly. The software as a service approach only works
09:20
for specific types of software such as web applications or databases but much less so for example for compilers. The documentation and books approach usually doesn't work that well from what I'm hearing. You don't make that much money of selling technology books these days and the donations model is very hard to get started to get to a point where it's really
09:44
a sustainable amount and if you're dependent on very few number of corporate sponsors that can also be an unfortunate relationship dependency in the relationship. Many of these as you can see are related to the question of licensing an open source project so let's quickly talk about that.
10:06
If you want to go into more detail please listen to actual lawyers instead of me and I think we'll have some interesting talks about this topic at this conference later today and tomorrow as well. From the business perspective there are basically four different approaches to
10:20
open source licensing. There is the approach of very permissive open source licenses like the Apache license, the BSD like licenses and so on that allow you to do very many different things with the project and make it very easy to run a business model like the add-on business model or the software as a service business model. On the other hand they have the business risk of
10:43
having a high risk of what we could call unfriendly reuse so someone else using the project in a way that is harmful to you and at the same time also not beneficial to the open source project and the community for example a competitor starting to use the software driving you out of the market and the competitor has no interest in giving back to the community and then
11:04
doesn't release the changes in open source and then that's basically it. The second approach would be a strong copula of license like the AGPL or GPL license that is only possible with very few of the business models that I've talked about before. You can absolutely do that if you're
11:24
selling support services but it makes it very hard or impossible to sell add-ons or an open core project and it also makes it legally quite risky to run a software as a service project. It's
11:42
before mentioned dual licensing business model where you license the project both under the AGPL or GPL license as well as a commercial license but this approach is legally complex and often raises the bar for external contributors quite high. They need to sign a
12:01
contributor license agreement or something like that which usually isn't that nice. Also as I said before it creates an asymmetry between the company and the community because if someone contributes to the project the company running the project will earn more rights to the combined work than the individual who contributed the new feature. And the fourth area is what I could
12:24
call almost free software licenses like the business source license, the server-side public source license. This is a quite new model and as I said these are not technically free source. They don't fit the definitions by the FSF or by the OSI and I think we'll have
12:43
a talk specifically about that topic in about one hour or something on the same stage. And they also introduce the same asymmetry between company and community but on the plus side they try to strike the balance between the different things that I have on the slide here.
13:03
They usually work like that you allow everyone to use the project for almost anything except direct business competition to the project creators. So usually they say something like do whatever you want but do not use it to run your own software as a service business.
13:22
So with all this theoretical background let's quickly have a look at the different products and projects that we're running and how we've created a business model for them over the years. The first one and the oldest one is the WebOPAC app which is an Android app to interface with
13:42
public and university libraries. It's a free app both free as in freedom as well as free as in free beer. It's available to connect to over a thousand libraries worldwide. I started the project as an open source project in about almost exactly 10 years ago and the project is licensed
14:04
on the Apache 2.0 license. And the business model that emerged some nine or eight years ago is a business model centered about white labeling the app. So it's a combination of the open core and the services model maybe where larger public libraries come to us and we create a copy of the
14:26
app that has a different logo and different colors and is named like the library and maybe has some bonus features that make sense for that specific library like integrating their event calendar or their news feed or something like that that would make less sense in the
14:43
general app and they will pay us a specific sum for the customization and a monthly amount for keeping it running and keeping the support. This has been a moderately successful business model for a number of years. It's slowly starting to get harder because public libraries
15:06
of a specific size are a very limited resource or a very limited market and they are of course chronically underfunded in most countries so they don't really have the money to spend on so we're slowly starting to see that we might need to look for different ways here or think
15:24
about this in a different approach. The main product of our company is Predix. Predix is an event ticketing application that can be used for all kinds of events like for spec stage. I started Predix as an open source project in 2014 when we needed a better ticketing solution
15:44
for a conference I volunteered for in the organizing committee and I pretty soon had the plan to turn it into a larger business to allow myself to work on it for a long time consistently
16:00
with a larger share of my time. We initially licensed or I initially licensed the software and the Apache license as well but last year we did a re-licensation to do a licensing model with the AGPL and the commercial license at some point last year. I think there's a talk tomorrow
16:21
that will call this type of re-licensing as moving to the dark side. I will be very interested to join into that discussion and see if that's actually what we did here. For Predix we have a business model consisting of multiple components. For one we offer software
16:42
as a service and hosting product. This is the main part of our business model because many of our customers either do not have the technical skills or just not the time to run the software on their own servers so they're happy for us to provide them with a turnkey solution. We also have an open core model. Predix has a WordPress-like plugin architecture
17:04
where we have a core project and then many different add-ons that you can install that add additional features and there are some add-ons provided by us as open source, some add-ons provided by the community and some add-ons provided by us that are only available under a paid commercial license. We also offer support services and paid development for people who
17:26
need custom features or custom add-ons or help with running the software themselves. And since our licensing switch we also technically have a dual licensing model. We usually try to couple the last of these business models, say we never sell support or
17:44
licensing individually, we usually sell them together as a package because we think it makes more sense and also it allows us to always have a consistent revenue stream on the support contracts, not only like we do not want to get paid only if the software doesn't work and the
18:02
customer has a question, we'd rather have a continuous stream of payment, especially if the software works well. And the third product that is currently in our focus is Venueless. As I said you're currently using it, it's the platform for virtual and hybrid events and it's actually a
18:22
joint venture between our company and two different partners. We settled in this case for the business source license which as I said before is not technically open source but could maybe be called delayed open source. Specifically the BSL as we use it allows you to do almost anything with the code, reuse it, modify it and use it for your own
18:46
projects and your own events but it specifically disallows running a software as a service business based on the code base. However, and that's why I call it delayed open source, there's a specific clause that says that every version published of Venueless will automatically be
19:07
converted to Apache 2.0 license within two or three, I don't know exactly, years time. So the version from two years ago is now Apache licensed and today's version will be Apache licensed automatically in two years. And this kind of guarantees the continuity that even if
19:27
we no longer exist as a business or we just lose interest and drop the product, at some point the code base will be completely free and available to the community. The business model for Venueless is currently mostly software as a service. Theoretically we could also
19:45
offer some kind of support or do a licensing model but so far that there has not been many interest in that because most event organizers are very happy if somebody else takes care of hosting live streams and so on for them because it's a little bit more involved than
20:00
hosting a simple single server web application. So the question now is do these business models work? And the answer is yes, they do for us. As I said before to different degrees and not for all projects the same but we are able to to make a living on that and we've been able to grow the
20:23
company from just me to 13 different people right now. Looking at our revenue from last year the different business models work to different degrees. Three quarters of our revenue is from software as a service and 15 percent is from support licensing and add-ons. As I said we usually
20:43
sell them as a bundle and the remaining 10 percent are for custom development that we do around projects. So if it works so well for us maybe it works for others too but to figure out if it could work for your project or for a project that you're thinking of starting it might be
21:01
interesting to ask what factors play in our favor. Yeah why do we think that it works so well for us? Well because it obviously doesn't work for everyone. One of the reasons we think is very important is that we are selling to a market that is willing to spend money on software. We're selling to businesses and institutions who are used to paying money for software they use.
21:26
This is much much harder if you have a software that is used by consumers because consumers these days unfortunately often expect to get software for free. Also we're scaling a larger scale web application that is interesting to both the
21:43
technical and non-technical audience. So software is used by a lot of people who wouldn't know how to set up a server and run it and who need us to provide a software as a service or something like that or to provide them with technical support. This is much harder if you're working on a software library or a developer tool like a compiler or to make a business case
22:04
around support because many of your users will have the education and the skills to just use your software right away. And also we're directly competing with some successful proprietary software. So if we have a sales conversation we usually don't need to convince the customer that
22:23
they need to have the type of software we're offering. We just need to convince them that our software is better or cheaper or more ethical or whatever than the one that they are currently using but we do not need to sell them on an entirely new category of things.
22:42
So this has all been very positive and we could suddenly call this a success story of running an open source business but there are of course downsides and risks to combining the open source and the business world as well. There are some risks for the open source project for example this can have very negative effects on an open source community depending on how it is structured.
23:04
If a company drives the main force behind the project that usually leads to less engagement of the community and fewer contributions. This makes sense if I as an open source contributor only have a limited amount of time and want to spend it in a way that is
23:20
most helpful. I will probably not spend it on a project that is able to hire full-time developers and I will rather spend it on a project where nobody has time to work on it otherwise. And this is totally fine and I would behave just the same and I'd do the same in my free time. But this also often means less power to the community so the governance structure of such
23:41
an open source project is usually very centered around the company driving the project and all the decisions about the future of the project are usually made within the company. We've seen some cases where the company at some point abuses less power and there is a community fork of the project or something like that but in most cases it works quite well
24:03
with the negative effect of the less contributions from the community. Then there's the risk of conflicts of interest. Many of the business models that we've talked about have a built-in conflict of interest. If you're the perfect open source developer you
24:23
write well-tested code that has almost no bugs it's very easy to understand. Why would someone pay you for support for bug fixes? Why would someone pay you for documentation or books? If your software is really really easy to install on a server it decreases the incentive to
24:41
pay you for software as a service and so many of these business models kind of work on the limitations of open source projects and the imperfectness and you often need to balance these different interests and we try to do that in a way that leaves the project very useful and very high quality to the community and only focuses on some very specific enterprise needs
25:05
for the business case but it's a thin line to walk. From the business side the main risk of doing open source is that competitors might come along and use your product which of course is just a fact of life with open source software. That's kind of the point that anyone can use it
25:21
but it becomes a business risk if it's used by competitors who have the force by being much larger to be an actual danger to you and if those competitors have no interest in continuing the project as an open source project this also becomes a product a risk to the community
25:40
under the project in itself and usually since we have less contributions less power to the community often failed business due to such an issue and leads to an abandoned project because there will be no one else around to handle it. So these would be some of the downsides that we hope to navigate in a way that works best for everyone but that always need to be kept
26:06
in mind when bringing these two worlds together. With that I'm getting to the end of my talk. I would be very interested to join in a discussion with you and answer some questions. I will be sticking around in the breakout room for a while and if you want to get in touch
26:21
with me or the Predix, the Venulus team, here's all the contact information that you need and yeah I want to thank you very much for the attention. So thank you Raphael for your talk. I think we have time for maybe one or two questions and after that we can move the discussion to the record room which you can join to your left in the channels section and you can
26:46
continue the conversation there. So one of the question was how do you attract contributors for your project? So as I said this is hard and it's also not really that we spend
27:04
we actively spend time on finding contributors. I think this is a problem that is mainly solved by the fact that we can hire people to work on the project and that the problem of finding contributors is more a problem of non-funded open source projects. We see that most contributors
27:22
that we have are people who are using our software and creating contributions to fix the problems they encounter themselves or to add features that they need themselves. Okay so maybe we can get to just one more question and this would be what are the risks
27:41
for software as a service modules models with a GPL license? Oh I'm not a lawyer let's maybe I don't think I can do this in two minutes let's maybe move that one to the breakout room. Basically the boundaries of the AGPL are sometimes unclear that how like whether it
28:01
moves into also your deployment stack and something like that like it's very hard to define where the AGPL software ends and where your hosting environment begins. There are some cases that are clear and some cases that are less clear.