Why You Should Pay for Open Source – Tim White

Hi, I'm Tim White, and I've been an engineer for about 30 years. Mostly software, but a few hardware and firmware projects along the way. If you've been doing this as long as I have, maybe you'll see a few favorite technologies of the past in my timeline there. For most of the 2000s, I built websites for a big telecommunications company. But these days I work for the Motley Fool, a financial news and recommendations firm. So here's why you should pay for open source software. Because open source is not all fun and games. Your team is too small and inexperienced. You're paying for it whether you know it or not, and the alternative is an apocalyptic hellscape. That's really it. Thanks for coming. Okay, you want some more detail. I can do that.

There is a strange obsession in academic literature as to why people contribute to open source tools. There is this impression in a lot of the literature that one of the main reasons is that open source is like a fun game for a lot of developers. And for many developers, that's true. Many open source projects are hobbies for their creators. And even many projects maintained by companies feel like they were just made on a lark. Not convinced that open source software feels like a game for a lot of people? Then why are there these leaderboards? I'm sure you know most of the companies in that center column, but what about those people on the left? What are they working on? Here's the thing, if you treat open source like a game, you'll end up with some pretty big problems. If you make the choice to make your own open source tool or use an open source tool, then you'll find that many projects crumble quickly.

What was a fun hobby project becomes a nightmare. You end up moving from having a few people report bugs and enjoy using your project to hackers targeting your project as an attack vector. You suddenly have to care about whether your project runs on Windows. Not so much fun now, hmm? Even super popular projects that everyone depends on end up with major issues. So major that the problem becomes more well known to most people than the project itself. But hey, the best thing about open source is that it's open. Your team can just change it if you need to, right? Except that your team is too small and inexperienced. Even in huge companies, the size of the team dedicated to any given project is usually five people or less. And those people probably don't have that much experience with what you're actually building. And in startups and nonprofits, the size of the teams is even smaller.

I think this Textar's chart makes it pretty clear that most companies fail once they get their fifth employee, so you should definitely stick to four employees. But what about those organizations that are winning the open source game, as seen by the leaderboard here again? The ones at the top of that leaderboard, most of them have bigger teams than you, and they can also hire the best of the best. And they build their own tools that they are very familiar with. I mean, your team is all super experienced experts in the tools you're using, right? And they'll be around forever in your company to maintain whatever they built for you. How are things going competing with the biggest tech companies in the world for those tech hires? Okay, Tim. So if open source isn't fun and games and my team isn't big or experienced enough to change it, then I assume you want me to buy my software instead?

Well, let's talk about that. Yeah, the last content management project I worked on with closed source software ended up costing two million dollars. And no, we were not paying the developers on that project team too much. In fact, 50% of that was licenses and vendor-provided training and consulting. Half of it straight to the vendor. Vendor name withheld, but uh clue provided. So let's contrast that with the $20,000 for the first enterprise wagtail implementation that I did. A tenth of one percent of the price. And yes, that project was a similar initial scope. Most of the credit, of course, on this project goes to front-end developer Lindsay Hartfield, who really knocked it out of the park with lightning speed, but still. a tenth of one percent. The crucial part is that none of the money on that project went to pay for the software that was used to build a project.

Or for training. Or for consulting. Fine, I admit it, we did spend twenty dollars on a Django course on Udemy. So $20,000. That's how much I should have spent as thank you donations. If you figure a project has half software costs, that's how much I should have donated to the open source projects that I depended on. But I didn't, and a lot of big efforts don't. And yeah, I feel guilty about it. So let's see some numbers related to ongoing costs Even with a very experienced team of Java developers, my last closed source project had an average ramp-up time of almost two weeks. An average meaning there were some people who took a lot longer before they could really do much of anything. This eventually went down a little once in-house documentation and training got better, but onboarding new developers was always terrifying.

So to me, this is the biggest contrast. Instead of 60 hours of ramp-up time, I had six hours of initial development time. Admittedly, I had great requirements, a lot of content management experience under my belt when doing this. and I spent a few hours doing the Wagtail tutorial ahead of this. But that was before I'd even started working here, much less started the project. And here's the thing. I could do that on my own time without having to wait for someone to get me a license for the software or send me to a training class. And obviously I had to do more work after this initial six hour implementation for the final product. I mean, Lindsay didn't do everything. The Clarion Call of Closed Source Software is support. You always have someone to call. Well, a generous average of seven days is what it took to get answers to most questions with paid support on our closed source CMS project.

and the first two days were always spent going back and forth with that support team discussing why we were doing it wrong. Seven minutes is about how long it takes me to get an answer about something with Wagtail. And no, that answer isn't, oh, here's exactly how to do what you need, or yeah, everything's perfect now. That answer can just be, yeah, it's really broken, or there's no way to do that. But that lets me move on and get on with the next thing I need to work on. So let's talk about what happens when you get successful. With closed source software, you have to wait until you get another license in order to expand the number of servers you have. And if you get a sudden surge in demand or you get really popular very quickly, that means going back to procurement to buy more licenses. Buying more licenses can not only take a long time to get through the procurement process, as I can definitely attest to, but of course it costs more money.

And then your demand may go down and you've got those licenses and Servers sitting around. It can't just downscale them. So the solution to that, of course, is to buy more licenses than you actually need at the beginning and hope that demand will eventually ramp up to fill them. Nothing like overpaying before you even get started. And of course, if you take like a rocket, open source costs you no more for the tools than it did when you started. No more vendors holding you hostage while you desperately try to get more licenses. So Tim, if open source is so cheap, then why are you telling me to pay for it? Well, let's talk about that. You are already paying. just not the way you might think. You are paying these organizations at the top of the open source leaderboard already. You are surrendering any voice in how things are built to the biggest tech companies in the world, who don't have the same needs as you do.

They love complexity. Kubernetes anyone? Are your employees spending their time contributing to open source? Are you sure? Maybe they're not working on it during the day, are they working on it at night? But think about what contributing really means. Are they reporting bugs? Are they asking questions on Stack Overflow that help other people use it and make the tool seem more popular? Even if they aren't submitting code changes, those things that they're doing to interact with the product online really help the biggest tech companies in the world make their products better. That's why they make them open source. So let's talk about how to pay for your open source in a better way, especially for smaller projects. So there's two big ways you can do this. You can donate to the projects that you want to succeed, the ones that you depend on, and the ones that may not be directly backed by

giant companies. Hard problems take time and resources to solve. If you want to avoid the pitfalls of treating open source like a game, you need to make sure that the tools you depend on have the resources they need to deal with the slings and arrows of being an open source project in the real world, including Windows. Donations are a great way to vote with your money. Even small donations can add up. Contracting with the teams that build your favorite tools is another great way to get some control over your destiny and help slowly build up the capability of these tools over time But why? There's got to be some alternatives other than just, you know, throwing money at these teams that already give me something for free. I mean, they gave it to me for free. Why am I paying for it? So here's some alternatives that I considered and that I have actually done in previous projects and on this project to try to figure out how to get better products, get enhancements, get the things that I need.

If I pay my own team or I pay someone else to build something just for me, then that thing only works for me and it never gets any better without me paying for it directly. In addition, maintaining that thing is my problem forever. Whereas if I pay for it to be added to an open source project, it can become the community's problem and it can ask hard questions about, hey, this feature seems to be a need. What's the right way within the context of this project to add it rather than the way that Tim or one of his random contractors decided to build it. That's one of the reasons I decided to contract directly with Torchbox to enhance Wagtail. And I think it's worked out pretty well. So here's how we're spending our free software budget with Torchbox. If you think about that, 50% of the cost is software.

We're not spending nearly that much, but still a significant amount more than we were, which was nothing. And here's what we're building. A page workflow, an editorial comment system, Postgres phrase searching, enhancements to tagging, better ways to lock pages, and a reporting framework. Enterprises love reports. And then of course we helped make the Google Docs importer better and enabled automatic transfer of content between Wagtail instances and then have been working on a two-way data sync with Airtable, which is a in-the-cloud spreadsheet product that makes it easy to To edit data in large groups. So the Motley Fool 's been working with Torchbox for the last year to help Wagtail close the enterprise gaps, right? The things that the big closed source CMS did out of the box that Wagtail wasn't quite ready to do yet.

And you know, the Enterprise CMS did have ten years of a head start on Wagtail, so I think it's not that surprising that Wagtail didn't have those features yet, but I really don't want to go back to the apocalyptic hellscape. I'd rather make Wagtail better So let's talk aloud a little bit of philosophy here. And my philosophy is simply this: when you can contribute, you should. And how you contribute is really going to depend on your circumstances. Right. If you've got the money to spend on a big project, then you should spend some of it making the tools you like better. But maybe not until you know what the gaps are, right? You don't want to spend a bunch of money closing gaps that may not even be real problems once you get going. So you don't have to do it from the beginning. But once you get to the point where you find gaps and you really want to close them, why not close them in the community? In the supported tool so that everybody can not only benefit from them, but build on them.

So if I build a core workflow system, maybe someone else will eventually contribute some modules to make that even better. just in my company and will never get any better unless I pay for it. So when you start with open source, you start at the bottom of the spiral, consuming it, using it. And then maybe you contribute to it both adding code but also answering questions or even asking questions. Then you create some open source of your own, perhaps. We have a few Motleyful projects that you can check out on our GitHub. And you may even create some whole features yourself. But then there's that last step, which is the one that I think a lot of people don't even think about, which is you can commission teams to build inside your open source platform and make it better for everyone who uses it. And then those people can commission stuff to be built on top of that as well.

And the whole tool just gets better and better over time. Especially for those hard projects, the things that aren't fun in games, the things that enterprises really need, but don't really make developers super excited and like, ooh, I want to build that. Those are the kinds of things that it's worth throwing a little money at and trying to make them better for everyone. So why not direct your payment to where it does the most good? So hopefully that all makes sense and you understand why open source projects are really built for a lot of different reasons. But when it comes to solving hard problems, problems that aren't as exciting or fun or much of a game as other things. things. Things that don't have debates raging day or night about how to do them, but are just like, oh yeah, I guess we should build that. Those are the things that it's really worth building a foundation that can get stacked on by other people.

And I hope that with the stuff that we've built for Wagtail that you're all thinking, wow, I'd like to make the workflow that they commissioned better, and I hope you do too, because then I can benefit from it. Supported for only a few months, that also really helps. So something to think about and I think I can answer some questions at this point