Open Source Outlook

Speaker 0: Let us kick it off. So this is the second episode of Bridging Bytes. This time, we have we have bridged from the last episode of the intersection of design and development, and now we are talking about, the open source Outlook. So, obviously, a very important topic, something that's near and dear to my heart, having worked on Directus now for 2 decades, over half of that as an open source maintainer. And then we have some amazing, guests here that are gonna be leading the chart in terms of this conversation.

So I'll be moderating the the chat. I can give a quick background, and then I'll introduce our 2 our 2 guests. So, my name is Ben Haines. I am CEO and founder of Directus, the open source, data management platform. And I've been I built the platform originally in 2004, and we actually open sourced it in around 2010, 2011.

So we'll get into more of the history of of what we did in our open source journey. But, I'd like to next introduce Bruce Perrons, who is sort of the the godfather, I think we were calling him, of open source. Bruce actually created the open source initiative, which I think was in 1997. Give her we'll let him

Speaker 1: 87.

Speaker 0: When was it?

Speaker 1: 1987 was the creation of the open source initiative in the open source definition. And the document actually came about, I think, 8 months before, it was then the Debian free software guidelines.

Speaker 0: Yep. Obviously, there's some interesting aspects of using the word free versus the term that was actually chosen, which was open source. But yeah. So we have Bruce Perrons here, who is the cofounder of the Open Source Initiative. And, you know, great thanks to your work, I believe, within, Debbie.

Basically, Bruce, why don't you give a quick, overview of your background and and and what brought you here?

Speaker 1: I I'm sorry. It really was 97. I'm just going over the calendar in my head. So, 87 was actually when I got to Pixar, and, I started as a filmmaker, was one of the founders of computer graphic 3 d feature film animation, and worked at Pixar and their predecessor in New York for 19 years in total. Have a credit if you go on IMDB on a couple of films.

And in, 97 we'll get that right now. I wanted to define what Debian, included, and we created something called the Debian free software guidelines. And then a little later, a group met and said, well, let's market free software to business and call it open source. And, so that happened. And I was called up the next day and I said, well, great.

I'll take my Debian free software guidelines and make them the open source definition. And so there we go. It's been a long time, and it's been incredibly successful. If I had said to you, back then, we're going to, give away our software and completely take over the industry by doing it. And we're going to make an encyclopedia, and it's going to be the first thing to put a Microsoft product and Carta out of business.

If I had told you that, you would have just said, well, I wanna smoke that dope too. So, so it it's been a long strange trip. Hasn't it?

Speaker 0: Yeah. Well, I here I am sitting here, you know, so excited to be 20 years in, to the entirety of my project, Directus. And you've got, you know, 20 years under your belt just, you know, with, you know, elements of your your history. So thank you so much, Bruce. It's really exciting to have you here.

Lots of knowledge, obviously, spanning back to the the mid nineties and even before with, you know, your work on those projects. I think next, I'd like to introduce Steven Tay who's joining us. Stephen, I'll let you give a quick background from what you did with with Vercel and what you're doing now at dub.co.

Speaker 2: For sure. It's an honor to be here. I feel incredibly humbled by the the the wealth of experience that you guys bring to the table. I think Bruce was talking about how he he he did that DBL thing in 97. I'm like, that was the year I was born.

So it was like a little bit of a it it feels very humbling. But, yeah, my name is Steven. I was, a developer advocate at Vercel for the last two and a half years. I started in 2021. It was there where I got, introduced to the open source community, got to actually learn and became a better developer.

Before that, I was doing a lot of, like, data science, coding in Jupyter Notebooks, not really building any, like, software that's used by the end user. So I I learned a ton through my time at, Vercel. I built a lot of open source templates, open source, guides technical guides that people can use to learn about Vercel's technologies like Next. Js, Turbo, Rebo, etcetera. And, it was actually through Vercel.

So we we dub this company that I started back in December of last year, it came about as a side project that I built when I was at Versal. I I had this need to, like, be able to share links, on on social media with really nice preview images, and it started from a very niche use case, but then eventually blossomed beyond that into a full link management tool. So, it was in December when I when I started talking to a lot of our users and realized that the market opportunity behind Dubb, It's a start company around it, and here we are.

Speaker 0: I love that. Thank you so much, Steven. That's a it's an awesome intro. I mean, obviously, we have, you know, different levels of experience, with open source, with building, but that's kind of how open source works. You know, you've got maintainers and contributors and users.

You have some projects that are out there and they're just small little packages or libraries like an SDK, you know, with one hobbyist sort of kind of maintaining it on the weekend versus things like Directus and, you know, even larger operating systems or platforms supported by tens or hundreds of developers. And I think, you know, in the last few years, we've seen all sorts of things happen, that really showcase the importance of of open source, vulnerabilities like Log 4J or just the the escalation of different open source platforms, like, really taking hold in the ecosystem. So it's obviously a very timely conversation. Specifically, my passion is around I I've spoken with Bruce for a while about this actually, is about how to build I think it's a nice acronym, SOS, but sustainable open source. Of course, SOS being, you know, talking to how important this is to get right and to do it timely.

But I think we can kinda dive in. The purpose of this, Bridging Bytes episode is really to talk about this theme of open source, past, present, and future. You know, we we, of course, have Bruce here to to really help us understand the roots and how this came to be. We made our our platform open source a decade ago, you know, obviously based on the WordPress license using GPL. And then we are we relicensed about 10 months ago.

So there's all sorts of things happening in the past and present. And, of course, you have to be really mindful of where do things go next. You know, how do we actually make open source sustainable? I've heard some pretty interesting ideas from Bruce that I'm sure he'll share around his ideas of what he's calling post open, at least as a working title for now. We'll figure out what that might look like.

But, yeah, so I think we should we can dive in. And my first question would be for for Bruce. Bruce, I'm curious, in all the experiences that you've had, maybe you could share how those have shaped your views, of the evolution and impact of open source over such a long tenure over over these decades since 1997, not 87, but through now. How do you think that those experiences have shaped, you know, your views on on that evolution?

Speaker 1: Well, I should just say a long, long time ago as if I'm telling a story because it feels like forever. But, so I I started out, working for a film company, and I I had fun. I mean, we did something for the first time. You know, we we made our IPO. They let us have our IPO at the same time that we put out the first three d feature animated film, which was crazy.

And so it it was a really interesting ride, but I started at this point to work on Linux because, we were using Unix at Pixar, and the PC was coming out. The PC started to be capable of running Linux. And then, Steve Jobs for a while had his office right across from mine. This was not because I was important, but because they wanted to keep an eye on me. And so, one day, Steve made his peace with Bill Gates, and the next workstation stopped being on Steve's desk, and there was a Windows laptop.

And Steve would tell us that, you know, eventually, we'd switch off of Unix, and we'd all be using Windows to do our animation. And no one was very happy with that, and especially then because before Linux was really big, the quality of Windows was very poor because they could afford to have very poor quality. They were essentially the only game in town. And so I started working on Linux and tried SLS and a few other things, you know, ancient distributions, and and then landed on Debian. And at the time, my idea was making a Linux system for amateur radio operators, ham radio.

And the reason for that was there was a lot we could do with software, and I thought we could put it all together. Well, that never happened, but I became Debian project leader along the way. And I think it was becoming more important than my work at Pixar. And the real moment for me was one day I got an email from someone and they said, I wanna use Debian with a serial console. Do you can you tell me how?

And that wasn't a feature at the time. And I thought it was interesting, and I I sat down at Pixar, you know, when I should have been working and figured out how to do it and sent this fellow an email. And he wrote back and said, that works great. This is going on the next space shuttle flight. And so I walked all around Pixar looking for someone to tell this to.

The only person there who knew about Linux was working from home that day. And so, it came a time when people would say to me, well, you're having such an exciting life. You've come out with a film, and your company has an IPO. And isn't this so exciting? And I'd say, yeah.

But my hobby project is orbiting in space. And at that point, I sorta decided maybe I would eventually leave Pixar and work on Linux and open source full time. And so we have had a history of that sort of serendipity. I mean, the hobby project of a students. You know, Linus was a student and maybe a lecturer, takes over the operating system world, and the industry software is taken over by amateurs who give away their software.

I mean, at this point, none of them were working for companies. And IBM abandoned AIX in favor of this hobby project. So all of these amazing things were happening and why the world was ready. There was a a market vacuum, and this came along and filled it. And people don't realize that this is all straight economics.

It's it's no you know, some people call it freakonomics, but there's nothing freaky about it. It's just economics.

Speaker 0: Yeah. I mean, it it goes without saying, you know, by some estimates, you know, open source power is 80% of modern code. So, you know, there's quotes from people over at Google, Filippo Valsorta, who had said something. I've had this quote here. He said, open source software runs the Internet and by extension the economy.

And I think that kind of really qualifies like how large open source has become. Obviously, in the early days when you're working, on defining it, Bruce, there was all sorts of there was the, I think you mentioned in Debian, you had the Debian Social contract, in 93. And there's the SPI, which was, you know, software for the public interest. You did the OSI, the Open Source Initiative. There's all sorts of, like, what's the term gonna be?

What are the rules? How do we, you know, really label these things? And what we got from that is essentially ten sort of rules or guidelines for what is open source, which is right there, you know, on opensource.org. It was how did you guys come up with those 10 terms? I mean, I I I've looked at them quite a bit because we have an open source source spirit.

You know, our ethos has been that since the beginning. But, of course, with a license change and trying to stay true to the terminology of source available versus open source versus whatever new terms we come up with, there's always gonna be those 10 terms sitting there within the OSI. So was that was that an easy or difficult thing to, you know, sort of memorialize for the world?

Speaker 1: Well, first, I don't wanna take all the credit. We are standing on the shoulders of Richard Stallman and the free software movement. And, Richard and I were actually speaking at a UN Summit in Tunisia, and I said we're standing on the shoulders of Richard Stallman, and he goes like this. And so, I think that we've had a lot of, different words for what we're doing. And because of that, the concept of having a brand came up.

You know, there was free software and there was Shareware. Remember Shareware? And

Speaker 0: Shareware and Freeware. There was, like, all the wheres. And it's interesting thinking of, like, how the word free left. Like, you still have thos, you know, free and open source software. But, you know, the freeware versus open source and the difference in perception, again, something that we deal with when we're now selling licenses for, you know, we've for years, been selling licenses for open source software through our cloud SaaS and, you know, breaking the perception of from free to paid is an interesting gap to kind of, cross.

But

Speaker 1: So so I'll give you another word that everyone's forgotten, consortium. It used to be that real software products were made by consortia, which was a collaboration of companies. And the problem was that they all had their own different interests and that the engineers did not control the operation. So the consortia had a lot of trouble getting along. And my very favorite, consortium story is the X Window System Consortium decided one day that they would not have a canonical user interface for x.

And Microsoft, of course, ate their lunch because they did. And and what the x consortium was trying to do at that point was allow each of the different Unix workstation manufacturers to differentiate their work station and also to lock in their customers by having a different user interface for that version of Unix. And they didn't realize that if they didn't work together, Microsoft would just take over the market and, you know, go find a Unix workstation today that isn't a a Linux or BSD system on a PC. So we had all of these economic issues, and we also had the need to create a brand. And so the open source initiative came by because, in Debian, we wanted to say what Debian was, and also we wanted to elucidate our social contract with the community.

And so we, wrote the Debian social contract and the Debian free software guidelines. I sort of created and edited it, and we had a 1 month discussion with the Debian developers about it and then publish the results. And this, part of it became the open source initiative, definition. The Debian social guidelines is still very prominent on the Debian site, and you can see the other part that became the open source definition at the end of it.

Speaker 0: Yeah. No. And that's something I think referred to quite a bit, especially as new licenses come out, you know, making sure they check all 10 of those boxes, to truly call themselves open source, you know, and not have some big glaring asterisk. Yeah. That's it's amazing just to hear the history of, like, all this tumultuous, like, what is this you know, there's just a huge landscape that was not defined.

So it's exciting to hear it was defined. Same issues that we're still facing today in terms of how you get financing and make sure you have an authoritative, list of of defining what this is, and that that's being, fostered by people who actually care about what it what it's supposed to mean and not just guiding it based on commercial endeavors. Steven, I'd like to, start over to you. Obviously, you've had, 2 sort of key roles that that you highlighted in your intro. Obviously, going from DevRel over at Vercel, to now founding, dub.co.

I'm curious how your perspectives of open source, you know, in the development of those those open source projects has changed, and evolved over that transition of your your career.

Speaker 2: Yeah. For sure. I think there's there's definitely been quite a shift in terms of, like, the way open source, I guess, the way we view open source personally. But one thing has always stayed true, and I can go through the distinctions there. So when I was at Vercel, we basically maintained this fairly popular React framework called Next.

Js. It's basically a framework for you to build with React, service side rendering, and basically an entire full stack applications with batteries built in, like API routes. You can even do stuff like, having a middleware to do redirects, rewrites, and all these different things that regular React would, you know, it'd be harder to build with that. And through Next. Js, it we were able to tap into a massive customer group and and not, I guess, not exactly customers, but, like, potential users that could be converted to customers.

Folks like, let me see here. Like, folks like, Netflix. I I I remember tweeting at one time that 4 of the world's largest streaming platforms, Hulu, max.com, Amazon Video, Netflix, they were all using XJaaS, which is kinda cool to see. And, through that sort of, I guess, user base, we're able to expand our enterprise, pipeline because we are able to tap into engineering managers who are using X. Js and and sort of pitch them our host of solution and give them a sort of white gloved approach to spinning up and and maintaining that Next.

Js applications. So in that sense, the symbiotic relationship between Next. Js and Resell was very clear. It was like, you know, you have this open source framework, MIT licensed, and you have this proprietary hosted solution that basically, does your Next. Js hosting for you, and you have you have to worry about stuff like Kubernetes maintenance and stuff like that.

So that was that that sort of relationship was very interesting. And the work that I did there was also sort of different because, I wasn't working a lot on Next. Js specifically. I was mostly more working on developer efficacy, which is building open source templates, and that sort of, like, drew me to gravitate towards another side of open source, which is building templates and also products that are open source, but at the same time, licensed under AGPL, which would give you, the the maintainer or the the company behind the project a certain level of ownership and control, over how the prod the the code is distributed. So, that sort of drew me to to basically build Dubb as an open source, first project.

It started as a project, and it's it's our company. And, so the relationship here is slightly different. Right? It's it's more of a we we call ourselves a cost, which is like a commercial open source, software, which is similar to what, for example, MongoDB started back in the day with, like they had their open source database system that people can easily clone and just run it themselves. And then now it sort of evolved into the wave of, companies like cal.com, which is an entirely open source company sorry, open source product that's, they have their repo, it's out in the public, and they also run that for the hosted service.

And they also have, like, a directory that is enterprise only. So if you want to use code in that directory, you would have to buy an enterprise license. And that's sort of the direction that we're going towards, and it certainly has changed quite a bit about how I think about licenses, how I think about getting contributor permissions, and stuff like that. There's so much nuance to to this whole ecosystem that, honestly, I'm still trying to figure out. I'm working with a few lead councils to understand where we should be, you know, what sort of precautions should we take, what sort of, licenses should we potentially change to in the future.

So, yeah, very excited to to to discuss this with you guys more and and sort of get your thoughts and and advice on this this whole, space and how we we should move forward.

Speaker 0: Yeah. No. That that's awesome. I think I mean, I've seen I've lived several of those different iterations of, like, how you commercialize, how you make that more sustainable. Seemed like you were describing sort of like an open core model.

Sometimes, you know, you can also work that and call it like an icing on the cake model. There's also the support, like the professional services where you have almost like an agency that leverages it and to get that support and the authoritative maintainers, you know, access to them. That's a paid service. Of course, that can be difficult to scale because you have to scale humans, and not just scale the software out, as you distribute it. So it's interesting to hear, you know, all the different methods.

And it kind of ties me into there's a few other questions I'd like to run through before we open it up to the audience. But maybe we'll we'll rapid fire these so that we can actually make sure we we work our way through it. But I think the next one that I think is interesting in this, you know, mid nineties all the way through the mid 20 twenties, where we are now, what would you either of you say are some of, like, the biggest milestones that have significantly impacted this open source landscape? You know, whether it's for maintainers, users, and awareness of, you know, open source as a whole. I'm just curious.

I'll I'll leave that pretty broad. But any big developments or milestones that, you guys can think of regarding open source?

Speaker 1: Well, I'll talk about myself. In 2005, I wrote a paper called the emerging economic paradigm of open source. And I think that it's very relevant to business and so called costs or commercial open source businesses because it explains how the economics work and goes into the business differentiator of your business. And every business has differentiators, which make their business appear different directly to the customers than others. And, you know, one of your differentiators is you've got dub.c0, and other people have 7 or 8 long, character URLs.

And so, we can open source everything but our business differentiators and collaborate with our very worst competitors on everything but our business differentiators because they're probably the people who need the same infrastructure we do. But we shouldn't open source our business differentiators until they rot. And over time, they will no longer be differentiating your business because other companies will have them. And at that point, it makes perfect sense, for that to be open source. So I think this perception of where open source could actually fit in a business and that you were not creating economic suicide and joining the communist workers' paradise by, taking it up, was a a very important one, and and I think that it was pioneered by the big Internet companies.

And so when Google and others take up open source, everyone else notices and says, well, these guys are making tons of money, and maybe there's something we should do there too. Another thing I talked about in that paper was a sort of 80 20 phenomenon, which is 80% of the software in your business is non differentiating. So you have a choice of how you make it. You can build it yourself because you have not invented hear disease, and you think everything you do in your company is better. This used to be a a more prevalent thing than it is today.

Or you can get it from the open source community. So say you use open source to reduce the cost and risk of developing that 80% of non differentiating software. You take the money that you saved on that, and you move it into making your business differentiators better. And it was the development of economic perceptions like this that I think made it smooth for a company to participate in open source. And and I'm not taking the credit.

I think everyone could have made the same observations. But if you, go back and look at that paper, I think it's still very relevant to businesses today.

Speaker 0: Yeah. No. And certain certainly a large milestone. Steven, any thoughts on other other milestones in the open source world?

Speaker 2: Yeah. I'm I was struggling to come up with one because, I'm fairly new to that open source space, but I I just wanna comment on what Bruce mentioned. I think it's very, very, interesting to hear about that 80 20. It's sort of like the paradox principle where you you take the the you basically leverage open source as a way to collaborate with other amazing developers. And I feel like for us personally at Dubb, the 3 sort of main benefits of being open source is 1, you get to tap into this massive talent developers and people that are, you know, constantly, contributing to open source code, and as a result, your code base becomes more secure.

I believe Mark Zuckerberg came up with this quote in an interview a long time ago is that open source software is generally more secure. So that's one. And secondly, there's also the aspect of tapping into larger enterprise customers that you never would have been able to work with if you're not open source. So in our case, Dubb is actually used, we're currently working with the government of Malaysia, which coincidentally is where I'm from, to basically, they're they're forking our our code base to build, like, a official government link shortener for the employees to be able to use, and that's something that we could never have done if we were closed source and they will have to subscribe to our software. So that's something that's really cool to be able to collaborate with all these different, like, agencies that have much larger, like, bureaucratic red tape, stuff like that.

And thirdly, definitely the the aspect around open source and the trust and transparency that goes into it is also massive. Like, you cannot just be putting spyware or, like, you know, like, ads and, like, what's it called, privacy invasion software into your code base just because you wanna, like, track your users or, like, I don't know, find a way to sell ads and stuff like that because your code is fully out there and people are scrutinizing it. So and as a result, like, companies are willing to trust and use the software more and goes through procurement much easier than if it was closed sourced. So Yeah. I feel like those are the 3 that we've seen so far.

Yeah.

Speaker 0: It's interest yeah. And I it's interesting to think of how much trust you can get. You've made your source available. You've made it open source, you know, through the license. These these steps are amazing to make to give you the transparency you need, which as you said, like, there's no hidden code.

There's no black box, and it's like, oh, what happens there? You're sending, you know, telemetry back to the mother ship or something weird and you're just unaware. But it's interesting that that transparency, while it does give you the ability to audit the code, you know, we at Directus were actually in use in the public sector. So the Department of Defense in the US and the Department of Energy. You know, we couldn't really do those things if they couldn't see the code end to end.

But at the same time, smaller open source organizations, almost always underfunded, really can't afford the security analysis or security researchers, to actually formally ensure that it is the code is audited audited. You know? So auditable and audited are 2 different things. And I think one milestone that comes to mind for me was sort of that big moment with log for 4 j or log you know, from the log 4 shell, vulnerability where people suddenly were very aware of how reliant, everything in the world was to open source, you know, specifically this one package. But, that I think was a really big moment for beyond just open source maintainers that are aware of their own value, of course, but everybody leveraging their systems to be also aware of how critical open source is to what they're building.

Speaker 2: So It's crazy. It's I was chatting with this, the he's a product manager at TypeScript of TypeScript at Microsoft, and, we were talking about this, it's a funny analogy where that's I think it's like the what's it called? Like, p k p x p xcd comic or something where it's like p xcd? SKCD comic. Exactly.

Where it's like this entire world that's, like, balancing on the shoulders of one big

Speaker 0: wall. Yeah. It's a very famous it's a very famous one. You've got this, like, Jenga Castle, and then suddenly there's, like, one little piece that could not be removed, which

Speaker 1: is They buy a hobbyist in Ohio.

Speaker 0: Yeah. So exact exactly. It's one of the probably the most popular xkcd comics if if editing can, like, toss it somewhere on here so everybody can see what we're talking about. But, super, super interesting to kind of visualize exactly what we're talking about here. And I think before, you know, some of those bigger vulnerabilities, people just weren't aware of it.

Now they are, and, of course, we're trying to remediate how do we solve that. Not always the easiest thing to resolve, but I think the visibility and awareness of, open source, whether it's commercial or free or otherwise, it needs to be sustainable. This is not only a hobbyist project for people. This is, you know, supporting big enterprises and and therefore, you know, big parts of the economy.

Speaker 1: I think there's another point that's really important about security especially is that the size of the code base that we use increases exponentially. So when open source started, a 100000 line code base was a large code base. Debian, I think, is now 1,500,000,000 lines. And so as the size of the code base increases, of course, the attack surface increases as well. And, thus, we are now at the point where no company can look at everything with their own employees regardless of the size of the company.

Speaker 0: To your point, Bruce, the scale of everything is getting so big. I mean, I forget figured was it called everything or whatever that NPM package was that had a dependency of everything? The dependency trees. You know, when we go through our institutional financing, there's big checks to make sure that we've done everything appropriately, and you have to provide for your software the full dependency tree. Those things just get so enormous, you know, to your points.

Everything depends on other things. And then you have some crazy joke, like, whatever that everything package, I think that's what it was called, That suddenly you can't remove because it is a dependency on so it becomes very complex very quickly. And how do I get out of this complexity and make things sustainable? I I guess it's sort of the next question Yeah. That I'd love to cover is, you know, you have these open source projects, hobbyists or otherwise.

Obviously, we're talking about how heavily relied upon they are. How can those projects and maintainers transition to commercial viability, to sustainability, to supporting themselves? And as the project grows, again, myself and Drake, you know, created this, you know, 10 years ago. We were working on it together, just the 2 of us, as an open source org. Now there's 30 people at the company full time that it takes, to kinda support this this project.

Those are full time salaries. That's a big, big cost. I'd love to hear your, both your thoughts on how these open source projects can transition to, a you know, to be commercially viable.

Speaker 1: Well, I think they do it kind of poorly today. And so let's take support because support is the way that a lot of companies try to make money, and open source companies don't do support very well. Why is that? Because they support their own program. Okay?

Now say you're a customer, an enterprise customer, and you have 200 important open source programs in your business, then maybe you have 200 support entities. And your job when a bug comes up is to isolate the bug, figure out which of those support entities to call, and then convince them it really is their fault while they all point at each other. And so, open source support, I don't think works all that well, and people get IBM support contracts because IBM says we're gonna support everyone. So that's one of the big problems that we have.

Speaker 0: Saying support is not a good option. What would be, like, what would be a an actual like a viable commercial option then for these maintainers to, bootstrap themselves?

Speaker 1: Well, continuing to talk about how open source does it today, we also have the widget frosting paradigm, which is you take a, open source thing and then you sell a proprietary enhancement to it. And so that is the way I believe that your company operates beside its support revenue and that a lot of companies do it. You don't have to do it right now in Dubb because you own Dubb. But if you had a whole lot of different, link aggregation companies doing the exact same thing, you'd have to sit back and say, well, I'm gonna have to strategize again. So we've really been doing open source for a long time, and it is time to sit back and re strategize open source to achieve some of the things that we haven't achieved.

Okay. So number 1, if the developer does not work for, one of these companies like Google that actually pays developers to do open source, they're probably not compensated. If they don't work for Google, they don't work for your company. And I've had people say to me, well, open source is mostly in companies today. That's a symptom.

It's a symptom of the fact that there's no other way to support your family than working for one of these companies that pays you to be an open source developer. Okay. Another problem that we have is we only program for ourselves, and this is actually a diversity, equity, and inclusion problem is we're great systems programmers, and we make really sophisticated applications for people like us. And thus, the the person on the street may not have heard of open source. They probably heard of blind.

And if you look at what applications they're using, they are using applications on their phone from Apple and Google, and the infrastructure of those things is open source. So Apple and Google, you know, they they consider the customer to be the product, and the main way that they make revenue is surveilling that customer and presenting advertising to that customer. And, so what we see is that the customer is somewhat abused by these companies, and we enable it. The open source community provides all of the infrastructure for it. So here we are with a world where privacy is concerned while open source stands for privacy.

Security is a concern, and and we stand for that too. And why aren't we making the applications that everyone uses? Because the developers want to write for themselves and people just like them. And so, well, maybe we need to pay those developers so that they're right for other people. So I I sat down with these ideas and said, okay.

Maybe it's time to transition beyond open source to something I call post open. And that may not be the permanent name because the permanent name has to be trademarkable. So post open is free for the person that we want to help, which is the common person, the individual, the small business. This is a business with revenue under $5,000,000. End user revenue has to be end user because it's too easy to circumvent otherwise.

You know, when I worked for a film company, they used to tell us, if your film makes a profit, you're doing your accounting wrong. So end user revenue to prevent circumvention. So if you're a company that makes over that $5,000,000 line or you wish to make proprietary modifications or you wish to put the post open software in a product that you sell, whether it's a device or a service or or a piece of software that you ship, then you have to get a paid license. And once you have a paid license, you pay about 1% of your end user revenue. And once a year, you audit what software you're using and you tell us, and that's compliance.

If you do the audit, you write a check, and you're done with compliance for the year. Now this is gonna be really important to companies because right now they have $7,000,000 per year open source compliance departments, and and some of them would actually spend less on post open. So now we've got a revenue stream. Okay. We give that revenue back to developers.

One of the ways that we do it is we instrument their Git repositories and we see who the contributors are. And we've seen from our users what they're using, and thus, we have some idea of how to apportion the money and give it back to the developers. Now in practice, this is more complex because there are people like colonel janitors and architects who might end up having time cards because you don't measure them by lines of code. So we're paying these people. We can also start paying them to write applications for the common person and start to reach that market and maybe displace some of the people who aren't working in the interest of that kind of person today.

The other thing that we can do is post open is a collection. It's all the software that you put under a post open license, and we can offer support for the entire collection because there's a centralized organization behind this. And the centralized organization offer support for the whole post open collection behind the scenes uses the project maintainers to do maintenance, but they aren't talking to the support customer directly anymore, and they'd be more comfortable that way. They're only in the support business to make money. We funnel the support revenue back to them as well.

So this is more complicated. It has PR and trust issues because there is a central organization and everyone has to trust it. If it forks a hundred different ways, it won't work for everyone for anyone. It's a very complex idea. I sat down and I wrote the post open license and it was 325 lines.

And there are actually 4 more documents that go with it. Okay. So there's one for the paid user. There's an operating agreement among the developers, and there's a process for infringers to come back into compliance. So I will end up with well over a 1,000 lines between all of these.

Fortunately, you don't have to read all of them, just the one that applies to your situation. This may be too complicated to ever happen. This may not gain share, but I think it's an interesting idea. And one of the ways that I would win over the current open source developers and companies like yours is you can dual license post open. So you can continue to be open source, but anyone who's paying for post open now is has got your open source under that agreement and you start getting paid the open source, they start getting easier compliance support, etcetera.

So, you know, consider a company like yours, when you started today or tomorrow with PostOpen, you could say, I'm going to invest in developing this software, and I'm going to get a lot of users through PostOpen, and I'm going to get revenue through that paradigm. And all of my software can be disclosed. It can be free for everyone for whom it counts that it's free. You know, once you make over $5,000,000 a year, it's not important that something's free any longer. And, so I think there are a lot of reasons that this is very compelling and I'm actually getting very little pushback on the idea that the pushback I'm getting is, well, today, open source is mostly business, and Bruce doesn't realize that.

Well, that's a symptom. That's not the way it should be. So I'd I'd love to hear, you know, how you feel about this, whether you think it's a total pipe dream.

Speaker 2: Yeah. You and I spoke

Speaker 0: about this, Bruce, for a while. The the show is called Bridging Bites, but I think you just bridged questions. Because I think you actually that was a very comprehensive answer, but it actually was an answer to the next two questions that I was gonna ask. So, that was super, super helpful. Obviously, there's strong alignment with what we've done at Directus with our unique usage grants within BSL.

But before I kinda kinda we chat through that, I'm curious, Steven, what what license are you currently using, for for for Dubco? And I guess just and in response to that, sort of Bruce had kinda called out I think you called it frosted widgets, which sounds like a a really fun cereal.

Speaker 1: Widget frosting. Actually, Eric Raymond made that up.

Speaker 0: Oh, well, we called it icing on the cake model. We actually tried that, And we found we were focusing too much on the icing, which is part the part we sell. And the cake, the open source core, was suffering. And so we actually changed our model to this this new licensing strategy based on having tried that. Again, 2 decades, we've tried a lot of different things.

But, Steven, maybe you could give me your your what what license are you currently on?

Speaker 2: We're yeah. We're currently on AGPL, which basically means that you can own and host your own, version of Dubb and even keep it close, as long as you keep it open source. If you wanna keep it close source and make changes to it, you have to purchase like an enterprise license. And to to respond to the point about like, you know, monetization and open sources, notoriously really, sort of open source maintainers have been notoriously underpaid and under, you know, loved in a way because there are so many packages out there that's just like people just maintaining it tirelessly, especially if you're not getting paid by a company like Microsoft or Vercel. Vercel does a really good job in in the sense, like, for for, you know, open source repos, like, you know, projects like Turborepo, Next.

Js, and a few other projects. But if you're not part of that sort of privileged group of developers, you just generally just go out and compensate it. The way we sort of monetize this, we basically have a SaaS offering that is actually not icing on the cake model. It's 1 to 1 exactly, like if you purchase a plan on that, versus if you self hosted, you get the same exact features, but we're sort of moving towards the direction of what telecom is doing, where if you need, like, enterprise features, like, I don't know, RBAC, where it's like role based access access controls or SAML and SSO, all these different, like, enterprise fee feature features, we will put that behind, like, enterprise license. And if you want to use those features, you will have to, you know, purchase, like, a license key, and that's a very, you know, smart model.

It's sort of an icing on the cake model, but in general, like, there's not exactly discrimination if you're self hosting versus if you're, you know, paying for a subscription. There's also another model that I think is really interesting, which is once.com, the one that's launched by the founders of Basecamp, 37 signals. They're they're doing this model where it's like pay once and use forever, And you it's sort of like that whole story of how software is sort of like a pendulum goes from licensing software to SaaS and now back to licensing. So it's a very interesting model. I personally think it's I don't know how, like, sustainable it is, how scalable it is, but I think there's a lot of potential there.

And I think as the world thinks more towards, like, privacy, owning own data, I think and as people get more technically savvy and have the infrastructure to do so, I think that's, where this kind of model will will flourish. But as of today, like, I I'm that that's why we're going with, like, the SaaS model where if you really want, like, you know, super easy sign up, create a link, you can just use our SaaS product. And then if you're more technically savvy, you wanna own your own data and privacy or whatever, you can self host it. So that's why we went with that.

Speaker 0: Yeah. And that's a that's a really strong model. I mean, we again, we had that sort of gated icing. I've I've listened to to Kyle Poyer, at OpenView, RIP, sort of talk about product led growth and usage based pricing and and also how you can gate those features. He had really interesting ideas around how you really shouldn't gate, the features that people real are gonna resonate with users.

But, you know, people know what SSO is. They they potentially know what RBAC is and how they can leverage it. So to enable those enterprise features at a as a paid offering, I think is a really smart way to do it. It it it's, you know, just really up to you. Like, does that work for your business model or not?

Does that sort of unlock enough commercialization or not? But yeah. No. That's, I think that's really interesting. Do you have any thoughts before I wanna switch into the sort of q and a.

And anybody in the audience, feel free to start throwing some comments or some questions in and then we'll we'll get to them in the the last few minutes here. But, what you had described, Bruce, in terms of post open, you know, name pending, seems almost like a multi tenant version of what we did at Directus. Again, just for those who weren't part of our enormous GitHub discussion where we talked about this in public with the community before we made the license change. We basically said, here's the problem. This needs to be sustainable.

Mouths to feed, you know, as Bruce said with the family. Everyone's got families, that need, to be supported. We said, here's the problem. Here's some solutions. One of which was the BSL license.

And then we used, interestingly, the same sort of model in parallel with what Bruce said. $5,000,000 and up, and you are sort of this commercial entity that most likely can afford to contribute. You know, again, developers and individuals and hobbyists contribute through code and docs and testing. The large enterprises weren't contributing. So it holds them and makes them, you know, beholden to that commercial license while the majority of users below 5,000,000 can actually use it effectively as free and open source software.

We did that in public, you know, with some radical transparency to make sure that everybody understood exactly what we're doing and why. And if there are any other options people had, you know, throw them out there and let's let's consider them. In the end, of course, we went with BSL with that usage grant for if it's under $5,000,000, you're completely good. You know, effectively open source for production, commercial, however you wanna use it. But I'm curious, you know, the model that Bruce described, Steven, would that sort of work for you, the sort of multi tenant?

You use a dual license and then potentially, you know, it's it's sort of a unified system or it's it's one centralized, I don't know if if what you would call it yet, Bruce. But this idea of them collecting revenue from the end user, or or fees and then distributing it. I can imagine it'd be so difficult to have, attribution and, this idea of, like, the composition of who which maintainers get how much revenue. There's a lot of questions to solve there. But any thoughts on that, Steven?

Just because that's what was my question, like the future of open source. Bruce has sort of pitched this grand idea. I wanna give you a second to respond.

Speaker 2: Yeah. I think that's definitely very interesting. We've we've definitely considered that in the past, and I personally have start like, tried to do, like you know, there's this there's this really cool tool called Algora that basically allows you to do, like, what's it called? Like, bounties where if if an open source contributor solves one of the bugs or or reports a bug and fixes it or creates a new feature, you can pay out bounties directly to them using using you just need to, like, mention the bot and say, tip a $100 or something like that, and that's really cool. That's it's a really cool way to do it.

We haven't thought much into, like, obviously, being able to take the end user profits and basically compensate officers maintainers, primarily because we haven't really gotten a lot of, like, contributions so far. I think that's something that we want to sort of encourage and do more in the future. We've definitely got a few really good ones, but I think, as of right now, we haven't invested a lot of introduction to that because of that. But I do think there's also a really interesting distinction between software that you can potentially self host and basically, for example, if you're building, like, I don't know, project management software and that is open source, and you basically are able to take that and just run it on your own instance or whatever, like, a cloud provider that you have versus something that would require a lot of, like, usage based like, I think you mentioned use usage based pricing and stuff like that. Basically, if you're building, like, an AI app that requires, you know, OpenAI, API calls, and that basically costs money to maintain, That's something that's a little bit different because it's like you rely on, like, a proprietary, you know, software, and that's why people are looking into also using open source, providers for LLMs as well, like, Ollama, which is a good one, I think.

So, basically, there's this interesting sort of bifurcation between open source software that you can easily maintain on your own VM versus one that relies on proprietary APIs, and that's sort of the, sort of we we we're actually currently trying to move away from relying on these, like, providers to something that you can truly own and self host. But but as of right now, it's not fully all the way there yet. So

Speaker 0: Yeah. And that's again, I think Bruce mentioned the idea of 80 20 rule. That's something that we we've been using, at Directus for a long time, 10 plus years where we the core software is is aiming to solve 80% of the use case and the functionality. And then the last 20% is, you know, configuration and extensions and and custom code. And that's exactly the problem that was that we were trying to solve is you have these, like, paid API keys and and integration with services that might be paid.

So we make sure those all go into the extensions to avoid that exact issue. So, yeah, it's it's interesting to see sort

Speaker 2: of that

Speaker 0: alignment across all these different things that we've been doing, you know, more siloed. There's a few a few questions here. I think we're over time, but let's see if we can get at least to 1. Alec Bass from Efficient. App had asked a few questions.

One was about, you know, how you figure out what is OpenCore versus maybe, the the gated side. I think we touched on that. So let's ask it go through a second question which was, how do you know if someone is using, you know, say, Dubb or Directus privately within their SaaS or within their system without a license. I'll quickly give my take on that because this is something that we have and continue to talk through at Directus. When we made the change to BSL, much like, of course, that was created by, Maria DB with the original author of the license, Hashicorp and Cockroach and Couchbase and Surreal.

They've all made that change. That usage grant means that people can use an open source under 5,000,000. But if you're over 5,000,000 or otherwise, how do you keep people honest? You know, we today use an honor system where it's like, that's the license. We hope that you honor it.

Typically, if you imagine the people who would be the commercial license over 5,000,000, maybe they're more motivated as a larger company to stay true to the legal document. But we've been also exploring the idea of like a key registration system and telemetry that actually, you know, opt in, opt out for GDPR reasons. But let's understand who's using the software. Let's, you know, error reporting or all these different pieces of information can help you give a sense of who's using your software, how they're using it. But obviously, especially with developer tooling where that network traffic is always monitored and should be, You have to be really judicious in what information you you try to send back to yourself to understand who's using the software or how.

Steve, I guess the question was to you at at Dubb. Do you have any thoughts around how you're doing that now?

Speaker 2: Yeah. That's incredibly I actually had the had a similar, train of thought as well. We currently don't do telemetry for, like, self hosted versions of Dubb, which can get a little tricky. Like, how do you find people who are self hosting? And that's sort of something that we we want to, like, try and do and bake it into our license in the future where it's, like, it's completely anonymized telemetry simply just to detect, like, how much link redirects that you've used within your self hosted version of Dubb.

That's 1. And then secondly, I wanted to point out, it's very interesting. Recently, we found a few, like, clones of doubt. They basically took our repo and just ran, like, a commercial service that's completely closed source, and it's, like, a full violation against our license. So that was something that very interesting that we had to deal with.

We had to, like, I was consulting with my legal counsel, and we wrote, like, a letter to the the hosting provider and say, you know, this is sort of like a DMCA takedown because they're not compliant with the license. So there's a lot of, like, I feel like dealing in open source sort of makes you like a like a legal candidate. You can you can basically, you know, pass the bar now. You know? You learn a lot of these, like, legal stuff, and I definitely learned a lot myself, in terms of, like, evaluating different licenses.

And I think telemetry is a very good point that you that you pointed out, and I think that's something that we definitely wanna go, in the future. Think cal.com does that really well too. They they basically log, the number of bookings in, like, the the open source self hosted versions that people run-in their servers. And if you cross a certain amount, that's when you need to have, like, enterprise license. It's really smart to have that threshold, as well.

So yeah.

Speaker 0: Yeah. No. That that's a that's a huge point.

Speaker 1: Go ahead, Bruce. So my consulting business, helps the infringer come back into compliance. So this is the company that used open source outside the license, usually got caught, and, now they have to fix it preferably without being sued or spending too much money. And one of the things that I really find surprises to companies is the community knows what is in your compiled software, that out in the open source community, not only the developers, but their users will see something comes out and they'll say, oh, well, this functionality looks like such and such an open source program. And they look inside, which is easier than a lot of people realize, and they see it's there.

I have in fact found my name in a number of commercial products. And so, if if you make a distributed product containing open source, you're gonna get caught, especially if it's a consumer product because the consumer products are the ones that a lot of people see and care about. It might not happen quite as often in the b to b In a, software as a service business like Dubb, it's a little harder because you might have to look at things like, well, what are the Internet responses here to HTTP, etcetera, and say, well, that's exactly the way that my software would do it. But it it is much easier to get caught than anyone realizes, and it usually happens. Now

Speaker 0: There will always be workarounds. Right? Like, whatever sort of pricing model or licensing system you put in place or telemetry that, you know, you can always just air gap it, turn off your network, and, you know, it's easy to work around all these things. So you have to incentivize users to do the right thing. And hopefully, you can do that by just having an amazing community and premium software that works well and people want to see continue.

But, yeah, it's a it's a very slippery slope. I think it's it's really interesting to see, like, how this will progress in the future. We touched on post open, Bruce's idea about, you know, how this could be centralized and sort of funded, in a multi tenant way. We touched on, like, the direct us and and to an extent how Dubb is doing it. I can think Dubb is a little bit more, Steven, correct me if I'm wrong, but sort of this, open core model where you're taking the same software, but you also have, paid features that are gated on the enterprise side and trying to identify exactly what goes in that bucket, and selling those services.

And then Directus, we've kinda got that unique BSL license similar to kind of both sides, where we are trying to say, you know, the larger players, let's make sure they can shoot contribute. It's an honor system. But at the end of the day, I think what we can all agree on is whatever license or strategy becomes sort of the the really the holy grail of of open source or post open or or free and open source software, whatever the names and terms are, it needs to have critical mass. I think we've seen that in the naming conventions decades ago. We're seeing it now.

It's really difficult with, you know, the the directest license, you know. It would just be so hard to get, traction there. So whether it's post open or BSL or some, you know, flavor or anything in between, we need we need to get that critical mass. And, of course, that comes with a lot of complexity. We talked about the legal complexity and cost of getting, you know, attorneys to sort of review these documents, trying to make it succinct so people can read it.

Bruce, you touched on having a lengthy license and how do we sort of distill that down to something that, both legal and developers can, you know, if you're not a lawyer, you can still understand exactly the implications of the license. There's so much sort of at stake here and there's so many people working on how we can solve it. But it's really exciting to have both of you here on Bridging Bites talking about, you know, what this could look like. I think it's gonna have to be a little bit of a TBD to see where we end up. Lots of great questions in the, in the audience.

Sorry we didn't get to get to all of them. But hopefully we'll be able to circle back on one of the future episodes episodes and cover some more. And of course, we will start texting some of the folks in here and see if we can give some manual responses as well. But I did want to thank, Bruce Perrons, and Stephen Tey for joining, this episode and talking about the past, present, and future of open source. Thank you everybody for for watching, and we'll we'll make sure that this is recorded so everybody can can catch up soon on, Directus TV.

So that'll be super exciting. Thank you both for joining.