Tim Panton: This is The Distributed Future podcast, and I'm Tim Panton. The podcast is aimed at trying to help people understand what the future might look like by talking to people who we know or who we've met who are doing something that we think is interesting and that may give us a clue about what the future might hold. This episode, we're talking to Lorenzo about open source. But maybe it's best to allow him to introduce himself. So, Lorenzo, tell us a little bit about yourself.
Lorenzo: Hi Tim. And first of all, nice to be here. I'm Lorenzo Miniero. I'm from the South of Italy from a town called Naples. I basically got my PhD and master thesis at the University of Naples across these years. And with the colleagues from there, I co-founded a company called Meetecho and we started working a lot with open source real-time multimedia, and we still do to this day. We're basically excited to see where the future will go in that sense.
Tim Panton: It occurs to me that maybe we don't, you and I and maybe even the listeners, don't necessarily agree with a definition of open source. Maybe you could tell us what yours is and maybe I'll question it a bit.
Lorenzo: Yeah, it's actually a fun question because there are many, many definitions there and I don't even know if my own definition is the right one. Because in principle one could say, if the code of what you have is available, then this could actually be considered open source. But there are actually several different definitions if you look at what the Free Software Foundation says or others that may actually challenge that very definition. Because there may be some constraints in what you are supposed to provide or not provide in terms of open source, in what you're supposed to allow people to do with your code in the first place, which has led to very different challenges across the year. Like for instance, very recently the SSPL license that in principle is supposed to be open source because the source code is available, but just the way it is presented basically means it cannot be considered open source by the way the definitions make it basically. In general, my assumption is that if the source code is available and you are more or less free to use it for what you want to do and possibly also use it in commercial endeavors somehow, then that is very loosely my definition of open source. Then we can debate forever about different licenses and so on and so forth. But at the very root of that, that would be my main definition of open source itself.
Tim Panton: So your definition is around kind of freedom. You're interested in the freedom to take source code that's freely offered that does something and then do something else or do something similar with it and have the freedom to do that. Is that kind of the core of what you think open source is?
Lorenzo: In part, yeah, I believe so. Mostly because these in turn incentivizes all the other advantages of open source in the first place. Like the fact that people are incentivized to collaborate with each other to contribute and so on. Mostly because at the end of the day, we are only interested in getting something out of the code that we contribute to. It's not just, "Let's share something with the world and let's be done with it." It's always a matter of let's give, but then let's also try and take something back out of this.
Tim Panton: That's interesting. It's kind of almost about not exactly enforced, but encouraged community building. It's almost a legal trick. So the license is a legal trick to encourage community building as far as you're concerned?
Lorenzo: In general, I think the more constrained the licenses are, I think the main objective is usually that one. It's not really that you want to prevent people from doing something, but it's that you want the project to drive one way or the other. In general, when you use more constrained licenses, you're not really trying to prevent people from using your software, otherwise you wouldn't be writing it in the first place, but you want to try and incentivize as much as possible people to contribute back to it rather than just taking and so on and so forth. But this is not strictly speaking my point of view of what I want out of my open source projects for instance. It really depends on what people aim to get out of whatever they're working on typically.
Tim Panton: Let's talk a little bit about what happens when somebody comes to your open source project and... Like what do they have to do in order to use it and why would you want them to?
Lorenzo: In general, I don't really want anything specific out of people to actually use my project. In general, what they need to do is just typically visit the repository somewhere, which is typically at the very basis of any open source projects out there. And you make the project available, you provide them with information on how to build it, on how to use it and so on. And that may be the end of the interaction they have with you, and that's totally fine. So people are definitely free to just go there, pick your codes, figure out how to use it, and start using it, and then never engage with you at all. That's definitely fine, and definitely within the spirit of open source software in general. Of course, in principle, the more people are engaged and the more feedback you get, the more contributions you get back. And by contributions, I don't necessarily mean code. It could be people contributing documentation, contributing feedback, doing assessments of the code or finding bugs or anything like this. The more you get this kind of engagement from the community, the higher the chances are that the project can actually grow and become stronger than it was initially. So at the end of the day, open source really is numbers game I believe, especially when it comes to engagement. Out of 1000 people that check out your codes, many will stay with it, some may leave, and very few may actually contribute back. But at the end of the day, it's all about helping the project grow one way or the other. And I think that open source is really making that sense.
Tim Panton: There's a bunch of MBAs, business MBAs, listening to this who are thinking, "Well, why would you do that? Where's the money?"
Lorenzo: That's a good question that we ask ourselves as well. And funnily enough, for instance, we have our main project Janus, we actually did debate very initially whether or not we should make it open source or not. Because we knew it could be an interesting component that people could be interested about, but we really didn't know if making it proprietary and trying to exploit it monetarily that way would be better than releasing it as open source instead. Eventually, we went with the open source way. Mostly because that's how we grew ourselves with any way. I mean, since our university days, we were very much focused on working on open source software, mostly because that was the environment we grew up in professionally. And so we did see the advantages of working with open source. And in principle, I think that one key reason for going open source is first of all the reachability. So even if you are, let's say, still in doubt of whether or not to go for a commercial or open source project, for sure, if you have an open source project, you have much more chances of reaching more people and getting more people interested. Because the moment the project is open source, it means that anybody can go there, try it. If they like it, they stay with it, otherwise they move on. But you definitely reach much more people than you would reach otherwise. And besides, I mean, there's also the advantage of the fact that with open source you may not and you probably are not the only person working on it. I mean, you probably will remain the person contributing the most, but the moment a project is open source, it means that you can get very skilled developers and professionals looking at it, finding problems, fixing issues for you, making it more performant and so on and so forth. Basically, you have the world helping you with the project, which again is something that you will definitely not have available if you close it down and you just start making a project, closed project that you try to sell instead. There are basically several reasons why it makes a lot of sense. And besides, I mean, besides the reachability aspect, there's also the fact that you also gain, let's say, it may sound cynical and so on, but you also get some free marketing out of this. Because again, the more reach you have as a project, the more the word starts spreading around about the project itself, which is something that you would otherwise have to worry about yourself in terms of marketing and additional costs that you may have to face in order just to spread the word around about what you're working on.
Tim Panton: So, you're saying essentially that it's a form of advertising. You're sacrificing what might be some income for free advertising.
Lorenzo: I mean, no. I mean, this is one of the aspects. I'm not even sure that you would be sacrificing that much income because there are ways to monetize open source software in the first place. I mean, the fact that you make a project available as open source doesn't mean that as a company working on that project you have no ways to actually monetize the project itself. Also because I mean, open source is indeed freely available, but it doesn't mean that it's actually free. And here I'm quoting a presentation that [unintelligible 00:10:00.08] guys behind Omar made a few years ago, which I found an interesting take. Which is basically the fact that the moment that you are working on an open source project, writing code and supporting it and so on and so forth, it means that it's actually not free for you, you're actually spending a lot of time and money to actually work on this component that then you are making freely available for everyone. And so it's of course not sustainable to just work with just the open source spirit in mind if you are a company that is actually working on this. And so you may actually get more money out of an open source project than if you actually closed it down. In part, because you may reach more people, and again, since it's a numbers game, you could get more people interested in the project if you actually made it available to a wider base in the first place. And again, it's not a problem if out of 1000 people 990 will never get back to you or we'll never pay you back for something, but if 10 of those do and 10 of those do contribute and even support you financially somehow, then it was worth it basically.
Tim Panton: So how does financial support work? How do people... Apart from producing code and tests and documentation, how else do people contribute to a project financially?
Lorenzo: There are basically different ways to do that, and some may or may not be usable at the same time. But in principle, there are very different ways. The easiest approach you can think of is plainly donations. So you have a donate button on your website, people think you're doing a good work and they contribute to you that way. We did consider it initially, but then we decided we wouldn't do it. Mostly because we were actually not strictly speaking, just, let's say, a few guys in the garage, if you want, working on open source software. But we already were as more company behind an open source project in the first place. And donations make it kind of ambiguous in terms of expectations mostly. So the moment somebody donates money to you, they may expect you to basically give them some priority in terms of identifying issues or bug fixing and so on and so forth, which in principle donations should not imply. Even though, of course, they are welcome, and you may have an implicit bias towards them in the first place. Then there are some challenges in terms of how you frame all of that from a taxing perspective and so on, which is something that I'm personally not familiar with. But for a few reasons, we decided not to go that road and go for a more traditional approach in terms of monetizing open source instead. Even though donations are especially for open source projects that are more the endeavor of individuals that are not strictly speaking part of a company or something like this. That's something that definitely makes sense also in terms of crowd funding or things like this. It's definitely one way to go, it's just one approach that we didn't follow personally.
Tim Panton: So you talk about more conventional direct payments. You're thinking about things like consulting, that's the sort of classic monetization strategy that I think a lot of people are aware of for open sources is that you give the software away, but actually in some way you make it unsatisfactory and therefore people have to buy consultancy from you to actually make it solve their real problem, or am I being too cynical?
Lorenzo: No, in general, it may be a bit too cynical because for instance, with respect to Janus, for instance, there isn't a single line of code that we don't make available as open source. So we definitely don't have any proprietary component that we hold up and only provide as part of consulting for instance. But in general, consulting is definitely one approach that is useful whenever you have people interested in what the software can do but maybe don't have the resources or the time to actually build something around it or possibly enhance the component with stuff that is currently missing. And so some simple examples may be sponsored development of new features, and we have done this a few times ourselves as well. And basically people pay for features that are not in Janus itself to make our own example. And then basically, whatever the outcome is of that effort ends up in the open source repo itself. So in that case, they are basically contributing to the code by having us develop the features that they needed specifically. But there may be a lot of things that you can do out of consulting, like basically building an entire framework or application around your own project, which could be an orchestration of multiple things. Building a scalable architecture of some sorts or basically try to implement the vision that you have for a specific application but you don't have the resources or capability to do yourself. But in general, consulting is just one way to do that, and it's just the next obvious step in terms of what you can actually provide. So some paid development of something or even just providing custom documentation, guidelines, design, and things like this. But you can also provide support more in general. So let's say prevalent support for bug fixing or identify issues or helping people with their problems and so on. Other approaches may be you have some sort of dual licensing, so you have an open source license that everybody can can benefit from, and if the licenses for one reason or another are not usable within the context of somebody that is interested in it, you can provide them with an alternative license, possibly a proprietary license just for them if they pay you a fee or something like this. You can use approaches like the open core model, the traditional open core model, which is basically, you have a model of architecture of some sort, and then you have some parts that are open source, there's some parts that you keep for yourself, and then in that case, people may need to pay for some additional services or something like this or you can actually build services based on your own product. So you make the project available as open source and you're free to install it and deploy it any way that you want, but maybe your software provides some kind of service that you can also provide as a service or as a platform yourself as well for a fee. In that case, you deploy your own service somewhere and then you allow people to use your service for for their own needs for a fee as well. So there are plenty of ways to actually monetize open source in different ways. And in general, it really depends on the nature of the open source project itself, on how widespread the project is or how well known the project is and how easy or not easy it may be to actually use the product itself, which may actually be an incentive to rely on some consulting or support services.
Tim Panton: Yeah, I mean, we had an interesting example of that. In fact, tracking back to your two first business models, we had an interesting example of that, where we will paid to add some features to an SNMP stack actually. But we were paid on the provisor that we didn't release those features into the open source for six months. So the people who wanted this work done wanted to have a six-month lead over their competition. They were happy that it would end up in the open source, but they wanted it held back by six months. I'm not sure that that kind of thinking exists anymore, but it can be quite creative. You know, you can be quite creative about like how you manipulate the license into being worth everybody's while kind of participating in a financial exchange. So it can be quite, I guess what I'm saying is it can be quite complicated some of these commercial models, and it depends on what your customer is, what the value they're extracting from it is as well.
Lorenzo: Yeah, and in general, I have to say that I'm a bit against the holding up features even when people pay for it. And for instance, in our own history, we did reject a couple of proposals that asked for that. And so basically, we never accepted working on something that we could then only release six months later and so on, for a few different reasons. One is as a matter of principle, because we still believe a lot in the open source principle in that sense. And so I believe that everybody should benefit from something from the very beginning, whether they paid for it or not. But then it's also a matter of basically an additional burden that is actually on you in that sense, because the moment that you have to hold up for some time then release for some time, it means that you basically have to maintain at the very least two separate folks of your own staff at the same time, which can be a problem if you have a small team. It can be even more of a problem if you have a very agile development model in the first place, because from now to six months, the code base may have changed a lot. And so when it comes to actually aligning the two different branches because then you can release those efforts finally for everybody, you may basically have to reimplement this thing from scratch because you need to take into account everything that has changed in the meanwhile.
Tim Panton: Yeah, we were on a much slower development cycle at that point. This is we're talking, gosh, probably almost 20 years ago now. I'm not sure that that... Six months wouldn't be viable these days, that would just drive everybody mad. But at least I think conceptually, it's something that you could think about doing.
Lorenzo: Yeah, no, absolutely. It's all part of the different ways that you can try and monetize your open source project basically, yeah.
Tim Panton: So I made some notes before we started, and I came up with two others that are probably not applicable to your project but worth kind of just throwing out there so that we've made a sort of relatively complete list. One of which was just the classic one that kind of Asterisk and Sangoma and a few other of those projects did was just basing it around the hardware. So the open source is a way of selling your hardware, and your hardware is pretty much useless without some software to run on it. And so you need to make sure there's software out there that's widely available, and open source is kind of in some sense the cheapest way of doing that. And we've seen that being very successful in the past. I think it's more difficult these days, but I think it does exist. And then the other one that we've seen happen recently is open source that has no monetization per se until the company is sold. At which point, somebody buys the company and the rights to the software, and they pay a lot of money for it. That's an interesting high-risk model, but we've seen it done. I mean, we both know people who've done very well out of that. I think it's an interesting model, but it's for people with quite deep pockets and a long timespan, I think. Well, any others you could add or any comments on those two?
Lorenzo: I have a few comments. For instance, for the hardware part, the hardware part is interesting because it definitely is not applicable to us in that sense, but it's also interesting in terms of what some people see the future of open source. And part of this is that actually software is becoming much more important than hardware in the first place, which is one of the reasons why open source has gained so much traction in the past few years. But apart from this, especially on the let's work on open source, basically on the acquisition model and so on, in that case, open source may be... Again, if we look at it a bit from a cynical perspective, it may also be a way to bank on yourself as a developer itself. Because the moment that you work a lot on open source, you basically contribute a lot, you become very well-known and so on, your project becomes very widespread and so on. Basically, as you said, it may be a good opportunity for companies to acquire your company. But not only in terms of getting access to the software itself, which they could monetize, but also most importantly, in terms of acqui-hire model. So you are acquiring developers that have been proven are very skilled because basically their platter of open source project speaks for themselves. And so it's definitely a way to get yourself much more known in the community and basically have a way to basically advertise you better to interested people as well.
Tim Panton: Okay. No, I hadn't thought of that. So it's a sort of career development strategy.
Lorenzo: Yeah, basically. You said in two words what I try to say in much more. Yeah, but that could be a very good sentence on that, yeah.
Tim Panton: So you mentioned the kind of, I was going to say demise of hardware, but let's say the increase of the cloud and the services model and the decrease of hardware as relevance. But that kind of services model really does bite into some of the older ways of getting income from open source. Do you see... I'm trying to avoid talking about licenses because that's a whole show in itself and actually probably not a very interesting one. But in general, do you see how the kind of shift to the cloud is affecting open source and how you see that developing in the future?
Lorenzo: I mean, in part, I think it's actually increasing open source usage. Mostly because as I was saying before, software in this case is becoming more important than hardware because in this case cloud usage or even just the pure concept of virtualizing resources in the first place, typically heavily relies on open source software in the first place. And I mean, Docker is a very good example of how it made it even much more possible and widespread in the first place. So in principle, it should be a very good spring boost for open source development in the first place because there will be a need for much more open source development in that sense. There's also the challenge... I mean, and I know we're not talking about licensing here, but there are the challenges of some cloud approaches that are basically potentially impacting the potential monetization of open source software in the first place. And so for instance, I'm thinking about what MongoDB did when they changed their license because of how Amazon and other cloud providers were using their software without contributing anything back and so on, just because they were actually providing everything on the cloud as a service and so on and so forth. So it will be a bit of a challenge, but I do see a bright future for open source in the first place because that's the way the whole world is going. I mean, even Microsoft, they were all saying that open source was a cancer just a few years ago, and now they are among the greatest open source supporters out there. So I definitely see open source growing in the next few years for sure.
Tim Panton: So let's just unpack a little bit the MongoDB story because I think it's interesting. Very roughly, what I think that was about was that Amazon now offer MongoDB as a service effectively. And therefore why we need to run on AWS. And so why would you ever install it yourself? You would just use the Amazon variant and get all of the APIs that you expect, and therefore there was no need for you to install it yourself. That's my understanding of it, but I feel like I'm missing part of the story though.
Lorenzo: Yeah. Part of the story was also that, as we mentioned before, one of the many monetization approaches that you can do is basically providing your own software as a service yourself. And I think that that's what MongoDB was doing as well. So they had their own MongoDB online cloud offering in the first place. And so in that case, it becomes basically Amazon using your own software to fight you commercially as well. So that was the main object.
Tim Panton: And so kind of Amazon having the scale and owning the hardware means that they can undercut you and sell your product as a service cheaper than you can sell your product as a service.
Lorenzo: Yeah, basically it becomes something against which you cannot compete, and you're basically making it even easier for them by providing your software with a specific license, let's say, which I think was the main motivation for them changing the license in the first place to try and prevent that and some other companies try to follow them on that road as well. I mean, there are definitely many controversial arguments there, so people that are a bit in favor, people that are definitely against. Mostly because as we said initially, the license that they went for is a new kind of license that's not strictly speaking open source and has definitely not been accepted by any of the the license providers. But I for one can understand the motivation, but it's hard to defend them when it actually impacts people that are actually using or were actually using your project in a legitimate way instead, which in some cases does happen.
Tim Panton: That touches on two really interesting points. One of which is that having issued your software under a given license, to some extent, at least that version is permanently locked with that license. So if the situation changes, the commercial situation or your situation changes, that version of your software is permanently with that license because you released it with that license. And so you sort of, you can only change future versions, you can't retrospectively change it. And that has a whole bunch of really interesting side effects in terms of... And I think this is probably for me, this is the main advantage of open source that we haven't talked about, which is the idea that even if the people who wrote the software get bored with it or, you know, stopped doing it for one of many reasons, the fact that it's open source and if it was in demand, then other people can pick it up and carry on supporting it. So if there is demand for a project that is dropped for either commercial or possibly even people die or whatever, that project can be picked up and still typically forked, but run with. And I think that gives it an interesting level of security to the people who are using, consuming that project in that they know that if the worst comes to worst, they have the source code and they can carry on with it even if the person who was supporting it chooses for one reason not to. And I think that benefit is hugely undervalued.
Lorenzo: Yeah, no, I agree. And it's usually, let's say, typically a bit underestimated. Mostly because people usually think that the person or the people that actually started working on the project are the only people or the best people suited to actually work on that project, which may not always be true. I mean, it doesn't necessarily mean that if somebody else start working on a separate fork of the project, that then that project is going to die or so on and so forth. I mean, it could actually go in a different direction, which may be bad or worse or most suited to other use cases. But it's definitely a very strong example of why open source is a very good solution in many cases.
Tim Panton: I mean, I think the one I have in mind there is MariaDB and MySQL and that fork. I mean, I think that's been good for the community, the fact that there is a competing option there.
Lorenzo: Yeah, or OpenOffice and LibreOffice, and there are many examples out there. So, yeah.
Tim Panton: I mean, potentially it dilutes the amount of effort that goes into a given fork, and that's always the risk. But on the plus side, it does mean that the thing can continue even if commercially the original vendor decides to pull it. So I think it's an interesting model, but I'm not sure where that goes to in the cloud. And coming back to our cloud offered services, I don't really see how that works in the cloud. Or does it, do you think?
Lorenzo: You mean in terms of defending open source from challenges like the one that you mentioned before like the road that MongoDB went to?
Tim Panton: Partly, but also in the idea that if you were dependent on Amazon's version of MongoDB and then they decided for one reason or another like, you know, they did the classic Google thing, so it's not interesting anymore, we'll just pull it. I'm not sure that the license models would then support the idea that those things could be run on a different cloud and you could move your APIs to point at some other implementation of the same software.
Lorenzo: Yeah. In general, I guess it depends on how those open source project are exposed in the first place. Because if the service has its own APIs and those are the APIs that the cloud provider makes available, then in principle, it should be just as easy to change provider and go somewhere else or deploy it yourself. And basically it becomes a drop-in replacement to make a dumb example of the URI that you contact to keep on using your project exactly as you were using before. If people start building more complex architectures around your software and your software becomes, let's say, a gear as large or small as it may be of a different thing, then in that case, it may be a bit harder to switch from one cloud provider to the other because you may need take into account the fact that you may need to have to change the APIs that are in use or possibly the deployments are different and the sort of things. So it's definitely a tricky subject. But in principle, the fact that the open source project the basis is the same, is definitely a strong factor in the ability of at least being able to migrate from one point to another with hopefully less effort than if you had to basically switch from an entirely different component to another.
Tim Panton: I suppose the flip side of that is that as the supplier of that software as a service, all the effort that you've put into it is something that somebody else can undercut. And so you sort of you don't have what the VCs call a moat. You don't have a lock-in of your customers. And so you've always got to be running harder than the whole of the opposition, otherwise your customers will just vanish.
Lorenzo: Yeah. But for most open source projects, you don't really have what as a company might be considered a user base in the first place, because just for the fact that anybody can just go and download your software and disappear, it means that you don't really have a lock-in unless you're providing a service yourself. So in that case, I mean, unless you're providing a service yourself or some kind of product based on your own software, you don't really have a consistent user base that you can rely on in terms of what you mentioned before. So in terms of what venture capitalists or others may consider as their user base that they may be interested in, because I mean more in general, the open source code base is in principle the word if you think about it. So it's much more widespread. You may gain a lot of users and lose others daily, so it's much more fluid in that sense.
Tim Panton: We really are upsetting the MBAs who are listening to this. They're sitting there bothering themselves about like, how does this work? I'm being unkind, there's probably a very good MBA course that has a segment on open source and discusses this. And actually, if there is and anyone's listening who's been on it, I'd love to hear from them. Because I think it would be fascinating to know what the business community teaches about open source business strategies. It'd be a really interesting segment to have if somebody wants to do that and come on and be a guest. I would love to talk to them about like... Because you and I have kind of done this on a practical basis. You much more than me, but we've sort of done it on a practical basis. But we've not really done the sort of, I suppose, the theoretical business thinking around it, we've just kind of winged it. I mean, I don't know, maybe you planned it, but I definitely winged it.
Lorenzo: Same here. As I said before, we initially weren't even sure if we wanted to go with open source or not, and we went with open source. And actually we did make a sort of a mistake at the very beginning because initially when we first revealed the project to the different communities, the project was actually released under the AGPL license, which is considered sort of a hostile license to most companies because it's much more viral than other licenses. And actually, there can be challenges in using it commercially in different use cases. And so basically we were advised very soon to move to a less strict license, which we did after a couple of months or so. But definitely in principle, I think that the key motivation especially for business-oriented minds is that the key motivation in keeping an open source project live and thriving is engagement in the first place. You have to engage the community, you have to engage developers and so on, and you don't have to lock everybody out. And that's really the key way of keeping people around your project, which may facilitate people actually being interested in paying you for some additional services, which can be consulting, support or other things. But at the very basis of all that, there is engaging the community one way or the other. Because you want to have people interested around the project, and the more they are, the more the project can thrive for different reasons and the more money you can make out of that as a consequence, not really as the main reason behind that. So it makes sense. Not only because it's the right thing to do, but also because it may actually be beneficial as a company to do so.
Tim Panton: The other thing I wanted to talk about and particularly looking to the future is, I see a couple kind of... We've talked about the cloud as a threat or a challenge to open source, I think the other thing that I see as a huge problem for open source is the reduction in the ability to deploy software on hardware without the permission of the hardware maker. So the extreme case of this is iOS, where on an Apple device, you have to get permission from Apple in order to deploy more than pretty much one copy of software onto their devices. And so how do you see open source on those closed platforms?
Lorenzo: Open source will still be there on those platforms because there will still be people interested in providing interesting or announced features and applications on top of those platforms. But of course the deployment of those may actually be more problematic for sure. And for these I don't have an answer also because it's strictly related to some roles and policies that then those hardware developers provide. So there may be less incentive for some open source developers to work on those platforms in the first place because they may see less appealing doing so or they may already know in advance that the project may not be as beneficial as they think it will be. Mostly because it will not have the ability to gain the traction that it needs to actually reach more users in the first place. In general, I don't really have an answer for that. But I do know that there will always be people that will develop for those frameworks as well. Mostly because in some cases, it may not be strictly legal if we think about it, but in some cases you can always replace the operating systems on those others in the first place to something that is more rope, and so you can still take advantage of the hardware, which may be better or worse or just different, just using a different framework for doing so.
Tim Panton: And so thinking for example about the Chromebooks, that is actually really difficult. Like running open source software on a Chromebook is not impossible, but it's really not easy because you can't just boot into another OS very easily. And there's no way of running native applications on it, so you're sort of boxed in to quite a large extent.
Lorenzo: Yeah, that's true. And in that case though, there's also the fact that typically the users of those more locked-in environments are probably also less prone to use open source software in the first place typically. So there may be that as well. But I don't really have an answer specifically for Chromebooks because I don't think I ever actually used one myself or interacted with those much myself typically. But in general, it really depends on the nature of the open source project in this case. Because if the open source project is actually something that is providing a service rather than something that you actually install on those devices themselves, then you may actually be using open source implicitly without actually having open source software on your own box.
Tim Panton: That sort of implies a migration of open source. The early days, open source ran on your own workstation. That was where you ran your open source. You ran your CANoe compiler and your X Window System and whatever else, all of the great kind of initial open source projects were run locally on your own workstation. But now what I think I hear you saying is that open source is essentially around service side and around software as a service, is it?
Lorenzo: I don't know if it's right or wrong, but it definitely means that open source is much more widespread than it was in the past for sure. And right now we are also using one of the largest open source projects in history, which is basically the WebRTC stack if we think about it. So open source is definitely all around us. So one way or another we are all using open source somehow.
Tim Panton: Yeah. I mean, there's a supreme irony that the Chromebook is essentially, all of the code underlying the Chromebook is open source except for the boot code basically as far as I can see. And Google have even released huge chunks of that, but it doesn't sort of kind of help somehow because the hardware is still locked.
Lorenzo: Yeah, that's definitely a challenge, yeah.
Tim Panton: But you're kind of I think more optimistic about the future than I am in that respect. It sounds to me like you think that that challenge is going to be overcome fairly easily.
Lorenzo: I'm more optimistic about the open source movement in general because... I mean, not necessarily about specific use cases, but more in general, I do see a big shift to open source from many sides that I would never expected to do that. And I mentioned Microsoft before, but there are many companies that have switched to open source and are investing heavily in open source in the first place. And that's a good thing in my opinion. Mostly because open source in general is important for innovation in the first place. And so the more open source project we add, even from very high-end companies, the better. Because it means that people can contribute to them, people can fight back on some things that they may not like and so on and so forth. So that's basically where my optimism come from. So there will still be challenges, and that's for sure because it will not be just roses and rainbows in the future for sure. But it's definitely a brighter ecosystem than it was just a few years ago. That's how I see it.
Tim Panton: That's fascinating. We obviously kind of have slightly different views on that, but that's cool. One thing I did want to talk about and not to try and get you into trouble, is you mentioned a long time ago in this conversation about like raising expectations from users that would not be met. How do you think you can best manage people's expectations of what they can expect you to do for their contribution? I mean, they give you a donation or they file a bug or they make some contribution to the project, but then how do you manage what they expect to get back for that contribution?
Lorenzo: In one sense, you don't. Meaning that in general, there is a silent rule in open source software development that basically everybody is basically contributing their own time for free mostly. So any kind of help that you may get or help that you may give is typically considered to be best effort. So you cannot really demand something or expect something for sure. So the best that you can do is put the problem out there and hope that people will actually get interested in solving it. And in the vast majority of cases, that happens and often quite quickly, which for instance ties to an interesting point that Fred Posner said in a presentation a few years ago that I still think is one of the best presentations that I ever saw actually, which was related to open source needs in general. And one of those was basically open source has no support, was one of the meets that the companies tried to spread about open source in the first place, which is actually not true. Because at the end of the day, most of the times you can actually get very good help and very good support from companies basically for free, which is something that no commercial application or no commercial endeavor typically does ever. So typically, and that ties into to your point about expectations, typically, you don't really have to expect anything, but most of the times you're expectations are met even if not exceeded. Because you may not get an answer right away, but you may get an answer in one or two days, but you will get an answer. You will typically get help from people that may or may not be actively involved in the project, helping you figuring out why you have one issue or another. And this is all part of the open source spirit in the first place. And some projects may do it better than others, others may cynically not spend much time on helping on the community to try and incentivize people to draw them to commercial supports and things like this, and these are all different tricks that some may do. But in principle, I think that in general, I don't know if I'm answering this or if I'm circling too much around it, but in principle, the idea is that even though there are expectations, you don't really have to actually do much about those. Just do what you think is right with the project, just help when you can, and in general, you'll see that the expectations are typically made. So the moment people actually demand help or expect something out of an open source project, my opinion is that they are in the wrong place and in the wrong game, for sure. So they're asking the wrong people. The idea is that you should try to engage the community, help and be helped, but not really expect anything out of that.
Tim Panton: I think the people who, it's less true now but back in the day, it used to be that the people who understood open source absolutely least were the lawyers. I used to regularly get emails from lawyers demanding that I showed my FIPS clearance or when I filled out various forms that they wanted to complete for a merger or an acquisition. And I'm like, "Dude, your guys downloaded this and that's the extent of our interaction. I have no obligation to fill out your FIPS compliance form. Thank you very much." They sort of understood in the end, but I think there was an expectation there that you had a sort of duty of care to everyone who downloaded it. And I never managed to get a way of conveying that that wasn't the case. And hopefully more education and more use of open sources kind of got that implicit, people understand it already without me having to say it. But I think that back in the day, that certainly wasn't true. And you had to explicitly say, "No, that's not my problem."
Lorenzo: Yeah, and at least in our experience, I think that we've been lucky in that sense because we did find some people that behaved like that for instance on the reports or on our forums and so on. But they were very, very few and sometimes they were chastised even by the other people in the community. So it's basically, as I said, something of a silent rule that you can't really expect anything and that's fine because you'll still get help one way or the other. And on your point about lawyers, I think I agree that it was a problem in the past, but I do know that open source licenses and so on have become a big object of study in that case as well. Mostly because licenses, they are not strictly speaking contracts, but they are in a lower like kind of language that is closer enough for them to understand better how it all works basically.
Tim Panton: Right, cool. That's actually really, really positive, much more positive than I expected to be. I was kind of expecting our final segment of the future here to be rather gloomy, but you're very upbeat about this, which is great. I want to thank you for that, you've cheered me up. I kind of went into this feeling a bit, "Oh dear, it's doomed," but you've convinced me otherwise, which is great.
Lorenzo: Part of that is because if it all fails, then I'm doomed to fail as well. So it's all sort of...
Tim Panton: Right. Well, as you say, we can only do what we want to do and have the time to do, and you just see what happens from there on out. Which is pretty much the attitude of the podcast, which is that we're throwing this stuff out there, we do it because it's interesting and we hope that the listeners kind of find it interesting. On which note I should say, that if you've got this far and you've listened this far, we really encourage you to subscribe to the podcast otherwise you'll miss the next one whenever that's about, and maybe listen to some old ones. On this topic, we did a really interesting interview with Amandine Le Pape about the legal structure and the commercial structure for matrix, which was really very interesting. And again, challenging and interesting experience of kind of trying to get my head around how they were thinking and how they made their decisions about how to license and how to structure their organization. So yeah, listen, thank you so much for doing this. I do appreciate it. If you've got anything kind of final words you want to say or links you want to give, and that's something I should have said at the beginning, if you've got links, send them to us and we'll put them on the show notes page. But otherwise, if you've got a kind of final thing you want to say, now's a good moment.
Lorenzo: No, I'm just happy that we had the chance of having this conversation. An hour flew by much quicker than I expected it to go, which means that at the very least we had a nice chat for sure.
Tim Panton: Yeah, no, absolutely. I mean, I do find that about this format, is it does give you the opportunity to kind of have a more of an in-depth chat than you can do in other formats, and I do like that. It's very rare that I don't enjoy myself doing this, and usually that's my fault because I'm not well prepared or something and slightly stressed about it. But that's definitely not the case in this one. You did a grand job. So thank you so much. And yeah, we'll see you at some point in the not too distant future hopefully. Quite where, I don't know, but hopefully.
Lorenzo: Let's hope so, yeah.
Tim Panton: Okay, great. Thanks so much. Okay, bye.