tea.xyz

Tea is the catalyst that shifts open source from a labor of love to a sustainable revolution, ensuring that the creators behind our digital infrastructure receive the funding they deserve. In this episode, we sit down with Max Howell, the visionary mind behind the Tea Package Manager, and explore his journey from building the widely popular Homebrew (Brew) to embarking on a mission to fix open-source remuneration.

Max shares his vision for Tea, a groundbreaking solution aimed at reshaping the funding landscape for open-source projects. He walks through the intricate workings of Tea, where voluntary donations are replaced by a unique investment model that rewards stakeholders with a stake in the system. By leveraging blockchain technology, Tea creates a direct link between funding and open source, ensuring that those who contribute receive their fair share. Don't miss out on exploring the power of blockchain technology and its capacity to transform the world of open-source software. Tune in now!

---

I’m happy to introduce Max Howell, Creator of Brew and Tea. Max, welcome to the show.

Thanks very much. I’m pleased to be here.

First of all, one of the benefits of me doing this show is I got to legitimately thank people for projects that I type into my command line multiple times a day. First of all, thank you for Brew. It’s legitimately something I use many times a day. Interestingly, the reason I have to do that is possibly the reason for the projects you’re working on now. Do you want to give us a bit of background about how Brew started? I’m curious to know because the available package managers back then were functioning on a Mac, but they were fairly painful.

It was 2009. I had only been a professional developer for a couple of years at that point. I went to Bristol University and did a Chemistry degree. I discovered when I went into the chemistry industry that I didn’t enjoy chemistry. I just enjoyed academic chemistry, but not practical chemistry. This was quite depressing for me because I figured that that was going to be my career path. I started exploring things that I’d had as hobbies. Programming had always been a hobby that I picked up when I was pretty young. My dad taught me, and I’d always make games, little tools, and things with it. I never considered it a real career.

In 2009, programming wasn’t cool. It was about to become cool because the iPhone had just released the App Store, and everyone would suddenly want to make an app. It led to an explosion in how many developers there were and the perception of them in general. I fell on it as a hobby, and I’m going to open source that way. I downloaded Linux and stored Linux, and started hacking on some of the user-facing application layers. I was doing the KD desktop environment, which was going to be the next desktop, which never happened in the end. That got me a job at a London startup because they liked the work I had done. I managed to get myself into the industry without a Computer Science degree or any real formal training in it.

That was writing C code, was it?

C++, which I do not touch anymore. I hate C++ now. At the time, as you were saying, it’s amazing how much tooling we’ve created over the last decade and a half. That’s all open source. Open source was only becoming something that was making a massive impact all over the place. Web 2.0 caused that, and then the mobile boom furthered it. We were making apps. There were six platforms, Mac, Windows, Linux, Android, iPhone, and the Blackberry app, which was a short-lived thing.

The tooling to handle all that different open source across all these different platforms, because what we built was open source as well, was lacking. I basically got the idea for Homebrew from using the tooling. This is how a lot of dev tools start. People find that what they have doesn’t quite match what they need. With a bit of ingenuity, you can figure out how to fix that gap. I started working and what became Homebrew and open-sourced it a few months later. After a few months, it managed to get some attention because I was doing a bit of evangelism for it. I wasn’t famous at the time at all, but with some people who were famous on Twitter, I managed to get their attention with it. It then became huge because of that.

People find that what they have just doesn't quite match what they need. And with a bit of ingenuity, you can figure out how to fit fix that gap.

Over the first year, it exploded in popularity. It was the biggest repo on GitHub within 9 or 10 months. It stayed that way for a long time. GitHub was pretty new at the time. Homebrew, as it was, manipulated the novelty of GitHub’s approach to open source collaboration. As a result, it became very large. I quit my job to work on it full-time after a few months because it was way more interesting than anything else that I can think of working on. It was amazing to have created something so interesting to so many people, and I wanted it to be the best thing it possibly could be.

I ran out of money, and that began this cycle for me in my career. As I said, I was only a few months into professional dev, and my open source seemed like, actually, that’s what I wanted to do. I didn’t really want to do the profession. I needed the money, and that was the problem why I kept running out of money and having to get contracts, so I did a lot of contracting over the years. 6 to 12 months, I saved up money and quit to work on full-time open source. A lot of that was Homebrew over the years.

That’s a crazy thing to hear because, probably 90% of people that owned or that developed on top of OS X, it became a critical part of their workflow, and you still weren’t able to make a living working on it.

No. Partly, I think it was timing-related. For some reason, hadn’t I created Homebrew until now, it would be different. It would require there never to have been a Homebrew. Nowadays, people understand the importance of how open source buoys up all this infrastructure. Everything is software-related. It might have been different. I might have been able to get funding for it or maybe sponsorship to a certain extent. I’ve never had sponsorship, I’ll be honest. Earlier, some of the companies that used it and found that they became dependent on it did send me a few things to say thanks, but it wasn’t money. Square sent me this iPad. I think it was Square, but it might have been Stripe. I get it mixed up. It was a very generous gift, but it didn’t help me with the things I needed.

You can’t eat an iPad.

I wasn’t struggling, I had jobs, but what I wanted was to work on open source full-time. That’s where I’ve always felt the passion and the drive. That’s where you make the most difference. Let’s face it. In a lot of corporate positions, you can make those kinds of contributions that impact the world. Google sent me a blanket once, which is always a source of amusement for everyone at the company that I work at now and outside there. It feels like a very token gesture.

In a lot of corporate positions, you can't make contributions that really impact the world.

They sent you a blanket. That’s a very weird gift.

It was a nice blanket. It was very strange. It’s as though they realized that I couldn’t afford heat, so they tried to help me.

That dovetail into one thing that I wanted to ask you about because I recognized your name from a famous tweet before we do this, which I’m sure you know the one I’m talking about. I’m going to read it out for those of you that don’t know what I’m talking about, and then you can give us the backstory, Max. The tweet reads, “Google, 90% of our engineers use the software you wrote, but you can’t invert a binary tree on a whiteboard, so fuck off,” which I believe is the one-sentence summary of a job interview.

It’s a good story. I’ve almost deleted this thing several times because I don’t feel it’s very fair. I was living in Chicago. At the time, I had a part-time work where I taught people who were in iPhone development at this bootcamp, and then I spent the rest of my time working on open source. It was this ideal scenario as far as I was concerned. I enjoyed the teaching, even though we can debate the value of a bootcamp ad nauseam. It was a great gig. I enjoyed it, and I learned a lot, frankly. It helped me to build better open source, watching people who had no idea about computers or how to use them but they wanted to understand how to.

The bootcamp started to do less well, and they had to let me go, so I suddenly found myself in this situation where I didn’t know what to do with myself next. I didn’t want to go back into contracting. I wanted something significant if I was going to have to get a job again. My wife at the time said, “Why don’t you reply to one of those Google recruitment emails that you always get?” This was 4 or 5 into Brew, and it had become indispensable by this point, so I turned up on recruiters’ radars. Google, every few months, would send me an email that said, “Let us know if you’re interested yet.”

I replied. I spoke to the recruiter and said, “You understand that I don’t have a Computer Science degree, right? You wouldn’t be trying to recruit me and then assume that I would be able to do your standard gauntlet of tests.” I wasn’t ignorant about the fact that they were famous for their full day of interviews that were pretty hardcore Comp Sci. I was like, “I’m good at building large infrastructure, making things that people need, use, and find useful and usable. I’m good at architecture. You should test me on those things.” They said, “Yes, no problem.” They even didn’t do the phone interview, which they usually do to check if I was the right kind of person. They’re like, “We don’t need to. This is Max Howell. He’s got the biggest project on GitHub,” etc.

I went there. The first interview was the binary tree one. I don’t think it was actually a binary tree. With hindsight, someone pointed out that I got it wrong, but I didn’t know that stuff. I gave it a reasonable attempt, I thought, considering it was not the sort of thing I’d ever had to do. A lot of people agree with me, and a lot of people don’t. It was an interesting tweet for that. I don’t think you need Computer Science for most application-type development.

I agree with that.

Mostly, it’s software architecture or engineering, designing components and making them work together. Understanding that side of things is far more important for building the vast majority of software. Yes, some people have to know Computer Science for sure. Over the years here and there, I’ve had to get my knees into it, and I can’t do it. It’s not what I particularly liked, so I’ve never focused on it. Some of the interviews were good. Some people understood that I didn’t know that. They gave me software engineering-type questions, and I did well with those.

‍

After the tweet, someone emailed me and said that the debate was intense about whether or not to hire me. Half the people who’d interviewed me were like, “He clearly knows how to do these things, which are important things, and we could use that.” The people who were die-hard, “You have to know Comp Sci or you’re not worth anything,” were against it. A week later, I got the call, and it didn’t surprise me. Suddenly after I hung up, I had this moment of anger where I was like, “Surely, Google could have found something for me to do.”

They’re not a small organization. I remember seeing this tweet from a discussion or debate on The Hacker News, which is probably exactly the same proximity as the one that Google has internally. I’m very much of the opinion that software is very much more about engineering than it is about the software, at least, it is in my experience and my world. Google wrote its own file system because it needed to make its search queries faster in 2007. That’s what you do. You write your own file system. Obviously, I’m not going to be able to write my own file system, but most people don’t need to write file systems in their job.

I totally understand they do need some people that can write file systems. They probably have the best in the world for that, but that’s a very specialized position. I’m pretty sure that would turn up in interviews. They’d probably expect you to understand how the file system works. Do I understand? Yes, I understand bits of it, but I’ve never found that particularly compelling enough to be interested in it.

When those articles turn up on The Hacker News, I don’t often click on them. If it’s about the history of UNIX or how the UNIX philosophy emerged and how it still applies, things like that, I’ve studied in great depth. I love the history of open source. It’s fascinating and very instructive about things that are important to me. I was sure that they could find some, even if it were just to make Homebrew more useful at Google. My tweet was 90% user. I’m sure that was an extreme over-exaggeration, but it probably wasn’t far off 50%.

The ones running on a Mac would have definitely. Brew was always, to me, interesting because it didn’t rely on an existing package repository. You started stuff literally from nothing in terms of the dependency graphs and all that stuff. What was the first Homebrew package that existed?

It was Wget, which is one of the reasons the Brew homepage still features Wget because that was what was in the original ReadMe and it was in the original website. Probably because it was easy. I stepped into doing package management partly because of all the open source I’d done and all the problems everyone had were package management related. I worked on this music player called Amarok for a few years, and it’s probably the favorite thing I ever worked on, honestly. It was so much fun. The people were all over the world and we were super passionate about music before Spotify. We all downloaded a lot of music illegally. We had big collections and we wanted something better than iTunes, which was the standard at the time.

All the problems we’d have in the IRC channel were people trying to compile the thing, and then there were packaging problems every step of the way. It used auto comp and auto make, which are these old build system generators that GNU made. Everything GNU made was always convoluted. It could work, but best of luck getting it to work. Those things are still extremely common. I became very knowledgeable about how build systems work, how packaging works, and how all the different tools work together. That knowledge helped me to understand how to build a package manager from scratch.

When you become very knowledgeable about how build systems work, how packaging works, and how all the different tools work together, it can really help to understand how to build a package manager from scratch.

It started the registry from scratch, but all the package managers that have ever existed started from scratch. It wasn’t unique in that respect. One of the unique things Homebrew had that the competition on Mac at the time didn’t is that I relied on what Apple provided with the system as the base layer. Probably I did this because it seemed an easier route to success, but it also turned out to mean that it was better, which was a nice coincidence, like if you tried to install something with MacPorts, which was the major one at the time. Our motto for a while was, “MacPorts driving you to drink? Try Homebrew.”

Once Homebrew was overwhelmingly the number one choice, we dropped because it seemed like it was rubbing salt in a wound at that point. When we were new, we were the up-and-coming rebellious package manager, so it was acceptable then. MacPorts would compile everything from libc++ upwards. It could take six hours to set up a dev machine. While if you used Homebrew, half the time, there were no dependencies. Brew shipped and didn’t have dependency resolution initially at all because all the packages I packaged pretty much didn’t have that. It is just a few, like FFmpeg and ImageMagick. Even ImageMagick, you don’t need any dependencies. It’s very raw without any.

Was there something that was the catalyst for the project suddenly exploding in popularity?

I’ve been thinking a lot about that lately like, “What were the conditions?” A lot of them were just good timing, honestly.

With regard to iOS development and things of that nature?

Mac had been gradually becoming the choice for developers. Certainly, in 2009, it wasn’t 100% like it typically is now. I remember the job I had in London. It was 50% of the devs were on Linux, and 50% were on Mac. The Linux guys acted as though the Mac people were just sellouts like, “We loved Jobs. We licked Apple’s lovely devices before we went to bed,” and things like that. It was considered Fat Boy essentially, but it was up and coming.

There was a position for people who were switching to Mac to try out because they were trying new things by switching, so they would try out a new package manager as well. I built on Ruby because I wanted Brew to be super easy to install. I initially could just clone it, and that was a working installation right there. You could edit the packages in the clone and then push them straight to GitHub. There wasn’t any idiom surrounding how you contributed, which a lot of open source screws up. A lot of open source is so difficult to figure out how to participate in the project, which a lot of people never do.

It’s because OS X ships with a Ruby runtime. To create a new Brew package, you could literally clone the repository and write the package, and then run it.

I wanted it to be that trivial with no extra steps. That was partly born of the fact that a lot of open source at the time was super tricky to get working. Even though part of the reason package managers existed is because you needed experts for every single package to help you to get it going because you wouldn’t want to do it yourself half the time. It’s super easy to get into, and then GitHub was relatively new. That was one of the first projects that understood the virality and that gamification of open source that GitHub we’re creating with the community additions and the focus.

Before GitHub, it was SourceForge. SourceForge was such a raw view of a source repository, like a token bug tracker and the ability to download things. It was terrible. SourceForge used Subversion, which was nowhere near as good as Git. Git is super complicated, but Git enables decentralized development in a way that matches open source, while Subversion didn’t. It was timing and choice of language because Ruby on Rails was also starting to peak in popularity.

I had all these people who loved Ruby and were like, “A package manager built with the programming language that I love with a nice DSL. The guy understands Ruby.” That was luck, honestly. It was the first project I’d written, Ruby. I’d studied a bunch of other projects and then tried to emulate how they worked. I focused hugely on usability and error handling being good and trying to help people to fix their own issues. All that buoyed it up, and then I managed to get the right influences to be passionate about what I was making. It is always important to have a good ReadMe and a few jokes in it.

As I recall, Brew originally preferred to compile stuff from source, and then there was a change in the direction of that from a community point of view. I do remember that whenever there was an OS X upgrade, you always had to be sure that you’d got the X code installed as well. Otherwise, you’d start getting weird errors that it couldn’t find weird libraries, shared object files, and things like that. Since then, it has changed to more of a binary.

It was 2013, the Bottles and binaries. It’s relatively quick afterwards. I remember when Brew started to become popular, I saw some tweets from people saying, “I can’t believe it compiles from source in 2011.” I compiled it from source because I didn’t know how to store binaries on the internet. This was way before AWS. There weren’t decent ways to do it. Every other open-source project that had binaries you’d download had to beg for hosting from other companies to get it. There was no way I was going to start that way.

Tea, which we’ll talk about in a minute, is the spiritual successor to Brew. It doesn’t, by default, component source at all. You have to install another package in order to do, build, and type operations in order to make the binaries that then installs. It’s a different time. There was no way I was going to have all that complexity. Compiling from source is hard. Brew did so many tricks in order to make it so that compilation environments were standardized so that there would be less bug reports. I was always after, “Let’s get the number of bug reports down.” That’s an indication that we’ve made something that works. It’s robust. It’s less work for us.

It was Mike McQuaid, who is still the core maintainer of Brew. He was a friend I had from the KD days. After Brew started getting some attention on The Hacker News, he turned up and was like, “This is a cool project. Can I join?” I was like, “Of course, it’s open source.” He’s polite. We ask each other for permission, so that was that.

At this point, he’s been more important in Brew’s history than I have, I’d say. I created it. I invented all the things it does. I designed all the pieces of it, but over the years, I became less interested because I like making new things. Once brew became mature, I handed it over to the community, and there was a huge community. It was fabulous. People showed up and were passionate about what we were building.

Let’s talk a little bit about Tea and what you’re working on now. It is probably fair to say that when you started Brew, maybe you did know how much you were biting off in terms of the scope of where it would end up. If you were to do that a second time, you’d be intimidated or excited by that. There’s a lot that’s been written about “Never scrap everything and start again.” Especially in the context of a package manager or something, that seems like some factorial combination of that wisdom or whether it’s true or not. You must have taken a very big mental deep breath to go, “I’m going to this again.”

You’re right. For years, I didn’t want to make another Brew. People would ask me, “Are you going to make another Brew?” It’s because people in our industry are especially always excited about the next new thing. Truthfully, after I stopped working on Brew altogether, I’d say 2015 full-time, it was on and off for years, but there was one set of features I added. I felt the friction from the other people in the community about it, and I knew that it was time to quit. At that point, I handed it over to the Homebrew organization on GitHub. For a long time, it was on my username. It was MXCL/Homebrew, the biggest repo on GitHub.

I was like, “This is cool. I like it.” I go and check out the trending every now and again. I was always up there. It fueled my ego a bit. I never stopped making notes about what could be done better, but I didn’t feel the desire to do it again. Partly, it’s like what you say. You shouldn’t start again. I’ve never believed in that. For me, in order to redo something, you have to have a compelling reason. There has to be something special and something new. From a product standpoint, I’ve always been a bit of a product person. I build software that is designed to appeal to a user base and a set of people and not just to fix a particular goal.

‍

To appeal to people, you need to have new stuff. It’s the truth. You got to have something compelling, so I didn’t think I’d ever do it. Over the years, I forgot how painful it is to make a package manager. It’s the truth. In the last year and a half that we’ve been working on Tea, all the frustrations that are building the entire open-source ecosystem have come back. They’ve been painful, but we’ve got over most of those hurdles again now. The reason that I decided to build Tea is because I had this moment of inspiration in between jobs when I was trying to work on open source again. For years, I’ve been trying to figure out how I can work on open source full-time.

Very few people succeed, partly because I kept getting contract positions. It meant that I was always starting a bit again with my open source, and so it became difficult to escalate that when I started Patreon, for instance. I couldn’t get the Patreon above $800 a month. I needed at least $2,000 to pay for everything, and then I’d be living pretty poorly as well. I was willing to accept it. I tried other things. I tried writing a newsletter where I talked about what I was working on and what was cool in open source and things like that. I couldn’t get any traction.

I had this moment of inspiration at the end of the last crypto bull run. I had a friend who’s been trying to get me into crypto since 2013 or so. Honestly, it never interested me like many because I’m interested in the things you can do with technology, and crypto just seemed cool. If you read the Bitcoin white paper, it is a very impressive and cool technology, but it still is just money. The thing I would use potentially in the future is what I thought if it caught on as an actual currency. I didn’t see myself working in it, but he was trying to get me to look at it again, so I was in between things. I looked into it.

They rebranded it as Web 3.0 at this point. They were talking about how other technologies and all these decentralized properties. I could see the decentralization aspect very clearly as the embodiment of the UNIX philosophy and the thing that the web was meant to be all along. The web was meant to be more decentralized, not more and more centralized, which has been happening.

While playing around with OpenSea, I had this moment of inspiration when I sold this NFT I bought because the digital contract forced the sale to pay the original creator of the NFT. There was no way around that. You didn’t need a lawyer and banks to do a load of stuff. It was automatically funneling the money back to the person who originally created it. I was like, “Could we use that to fund open source in some way?” I found out my friend, and we started a company essentially.

By building the package management on top of blockchain technologies, we can make it so that there are a bunch of digital contracts that funnel all the tokens to open source and all the dependencies all the way to libc++. If some money ends up going to node, then a percentage of that will go to open SSL. A percentage of that will go down to libc++, so all the packages, even the ones that people never even heard of anymore.

There’s a famous xkcd cartoon.

We try it out all the time, that comic, because it’s codependency and it has a tower of blocks. It says, “These blocks represent all modern digital infrastructure.” At the top, there are lots of little ones. At the bottom, there are some bigger ones. Right near the bottom, there’s a tiny one that looks like it’s holding up the whole stack and there’s an arrow, and it points to it. It says, “This project has been maintained by someone in Nebraska thanklessly since 2003.” That could collapse and then bring the whole internet down with it.

You do see examples that Log4j before. It was a great example just as we were raising money, so it was perfect. There was this tiny dependency that caused huge security problems for the vast majority of enterprise internet. We don’t get any funding, so maybe some of these enterprise vendors that make money off the top of this stuff could give us some money. As far as I know, they’re still extremely underfunded because open source is not a charity. If you build it as a charity, then it’s not going to get funding. It doesn’t work. I hate to say it, but it’s a difficult business to get voluntary donations to go to people.

It's a difficult business to actually get voluntary donations to go to people.

Our model’s different, and it could only be done with blockchain tech. Essentially, what we are building is a bank where people put money into the system as an investment. Periodically, we reward the people who’ve put money in with an interest rate, essentially. It’s a stake reward for staking into the system, so we are inventing money out of thin air. You can’t do that with regular currencies, unless you’re a bank, and then those rewards get funneled to the open source projects. The reason we’re doing this because it sounds complicated is because I don’t want to change open source fundamentally. I don’t want to make it so that when you use Tea, the package manager, it costs you a tenth of a penny to install node because that wouldn’t work.

That would be weird.

No one would use Tea. That’s a question I get a lot. “Are you going to charge for packages now?” I’m like, “No.” If you believe in the value of the open source ecosystem, and let’s face it, it buoys up the entire internet. Web 2.0 have made huge amounts of money off the top of open source. It’s worth a lot of money. If you believe that’s worth some money, then invest that money into the Tea network and that will fund the open source that you depend on as well as give you a reward in proportion to the amount you stake and in proportion to the general belief of the ecosystem in the value of open source.

‍

You are also able to publish and be completely transparent about all of that money and where it’s all ended up.

An important piece is that the company doesn’t take any of that money. We’re going to launch this autonomous system onto a blockchain, and then Tea steps back. We build open source, so we’re hoping that the open source we’re building is going to get staked against so that we get paid for doing that. Everyone else who’s participating in it. Tea’s not taking a percentage of a percentage of the remuneration parts. You, as someone who’s interested in the tech, can go and read all additional contracts and see that it’s fair and equitable, and the money is going to the people who need it and nobody else.

How does the guy in Nebraska prove that he is the custodian of that library that’s holding up the internet?

This is stuff that we’re still finishing up on the design belt. Essentially, you’ll have a wallet on our blockchain and you have to sign a commit in the Git repository that you say that you have control over with that wallet. That’s proving the connection between your ability to control that source code and the wallet. What we’re going to very strongly encourage is that people don’t sign it against an individual’s wallet, but instead, they sign it against what Web 3.0 calls a DAO, which is essentially a way for a group of people to have voting rights over something.

We’re going to say, “Everyone who’s part of this project should be in the DAO. You, as someone who controls the project to a certain extent, will decide the nature of that DAO.” You’re the king of the DAO, or it is going to be, “There are a few core contributors.” How then will the rules that you get flow into that open source project? Will the core contributors get all of it, or will a small amount be set aside and stored on chain for people who do pool requests or submit security reports against those projects?

It’s probably what it should be, but every open source is different. Every project’s different. We’re going to give the community a series of suggested templates, the digital contracts associated with those, and instructions for how to set it up with a Multisig so that control of that project can be passed onwards to different people as time goes on.

It’s mad how those concepts and paradigms that sprang up in the last few years slot almost perfectly into place and map almost perfectly onto the problems that you’ve been talking about for the whole time. As an application, it uses almost perfectly all of the things that a lot of these projects have struggled to find a reason for being. Everyone understands everyone, but you understand, “That could be useful, but why would it be useful?”

One of the things that I did when I was researching this was I looked at what people thought about the idea. I was wanting to ask you because The Hacker News’ responses were insane. On The Hacker News dial, it was dialed up to eleven in terms of furious condemnation of, “How could anyone think such a thing?” It’s an absolute shithousery. It’s interesting because you talk about the timing of Brew. This was in this whole maelstrom of nonsense. You were floating along with all these very sensible applications alongside people selling silly cartoon frogs for $8 squillion. Was that annoying?

I agree that the timing is right. When I had the idea and the more I thought about it, it was like, “This is the right use for this technology. The timing is right, and we can build it and fix a fundamental issue.” When I was building Brew, I had this feeling at the back of my mind before anyone knew about it that it was going to be a big success. I couldn’t explain it, but I knew, and that drove me to keep working on it, even though I was the only one using it. It then became a big success. Honestly, I had the same feeling about this project. It’s harder this time because, as you say, people are so skeptical about crypto. I don’t blame them. I was exactly the same. I felt that it was scams and stupid images of lions, pandas, apes, and things.

That’s because predominantly it is.

It’s like 97% scams and BS. The rep is deserved, but this time, we are actually building something with genuine utility, and it will do good for our industry and humanity as a whole. In time, people are going to see that. The couple of times we’ve been on The Hacker News, the level of hate was unexpected.

You must have been thinking that you’re going to get a certain percentage of people who are assholes about it.

That’s what I thought it would be. Some people were very difficult to convince. The same with Brew. There were a lot of people like, “Why do we need this? We have plenty of other things. What’s the compelling advantage?” There are always some people who don’t see what something is going to be. They need to see it become successful, and then they will adopt it. I thought it would be like that. It’s a bit much, but I like a challenge. This is the biggest one I’ve ever had where it has made me up my game in terms of how good the tooling that we’re trying to produce is. The spiritual success of Brew, the package manager is nice. Best thing I’ve ever made. It’s a lovely package management solution for developers or people who need that tooling on the computer.

There are always some people who don't see what something is going to be. They need to see it become successful and then they will adopt it.

I don’t think there is a better one that can be made, honestly. It’s the pinnacle. We then released GUI Compliment, and a lot of people are like, “Why is there GUI? I don’t understand it.” We released it very early. It’s just a compliment now. It’s nice to install it, and it’s great for seeing what’s new in open source now. You can browse that new packages page. You get the dopamine hit of updates getting push notified to you. You can click a button and get those updates, and it’s lovely. I released libt, which is infrastructure for packaging.

You can node-install libt, and then install anything in open source inside of your node application. No need for you to install tea-cli or anything. All the Tea packages are relocatable, so you can install them anywhere. That’s powerful. We’re about to start seeing what people can do with that kind of stuff. Now, I’m going to keep going. I’m going to keep releasing incredibly interesting and potentially important and powerful pieces of infrastructure for the packaging ecosystem until people on The Hacker News can’t do anything apart from, “I don’t know the crypto part, but this is cool. Maybe the crypto part is a good use for crypto. Maybe we can fix open-source remuneration. Maybe I need to give it a chance.”

This is why I didn’t quite understand the reaction because, at the same time, there are constant stories, and it’s well understood within anyone who’s been working in the industry for any period of time. There’s a ridiculous imbalance between the value that open-source projects create and the amount of remuneration that those open-source maintainers receive. The obvious reply is, “What’s your idea? Have you got a better idea for fixing this problem?”

They don’t. The way I see what’s happened is it was gradual. We got to this point gradually. It used to be that the whole software industry was built on top of Microsoft and Oracle. Some of these other huge businesses had a lot of money and could afford to maintain all that infrastructure, but then open source began to prove its value. It is the fact that you can have people from around the world who use a tool, and they all have slightly different ways that they need it to work, and then they come together and make it exactly what they need. It’s free and freely available, and you can put it on any system you like. Even the base is free.

It became an indispensable piece of software infrastructure as a result of over time. We’re now at the peak of that where the people who built all that stuff are starting to quit or starting to hand it over to people, and the people they’re handing over to can’t maintain it properly. It’s become flaky. We’re going to see more examples of that, I feel, over the next few years. That’s where I want Tea to come in and start making it. Some of these indispensable pieces of infrastructure have the funding they deserve because when we switched from everything being built by Microsoft to everything being built by people for free in their own time, that transfer of wealth didn’t occur because it was so gradual and we let it happen. We need a real solution. If it’s not Tea, someone better be working on something else.

‍

Whenever I get in a new rental car, I always do that thing where I find the open source list of projects, the ones that are licensed, and they have to say, “This car makes use of something.” Quite often, it depends on the manufacturer, but you go to settings and about and diagnostics or something, and then you get a huge scrollable list of open-source projects, the code of which is in the entertainment system that you’re using to look at them. I always think how absurd it is that that’s what you get for having a bit of software that helps empower the car. Some manufacturers don’t do it, and they don’t bother.

They’re meant to. A lot of these licenses insist on that. Things like Tea help you to show that. These car companies probably donate nothing now. With Tea, we’re automating the process of making sure the products we depend on are funded. I’m hoping that is enough of a usability hurdle that we’ve overcome that the community will put huge pressure on the people using this software. It won’t even necessarily be the people developing it. They just have to appeal to their user base and say, “Hyundai uses this project and has never given us a cent, and when it goes wrong, they blame us,” which keeps happening.

A classic one of that was the OpenAI, Sam Altman. There was a bug in ChatGPT, and he was like, “We found the bug in one of our open-source projects that we use.” Punting the blame onto people that they probably don’t even fund is classic. I’m hoping that you make something easy enough, and then the hurdles that were there disappear. Part of what we’re doing with Tea Community can put large social pressures on these companies that milk these open-source projects because we’ve made it super easy for them.

Max, that’s been a fascinating conversation. I’m glad we got to talk over these subjects and you didn’t shirk over any of them because it’s a tremendously important subject. It’s great. It’s very unusual. The people that I’ve spoken to, most people shirk away from taking on this challenge and this problem. I thank you for Brew and for putting your head down and charging into this problem because we need more projects like the one that you’re building.

Thank you. Your audience can help support us by visiting Tea.xyz and checking out what we’ve done, just participating in what open source we produced using it or otherwise. Blockchain component, we’re aiming for the Testnet to be out in 4 to 5 months, I reckon. Testnet is when open-source projects should begin to participate. It will show them how valuable participating in the Tea Protocol could be.

That’s great. I’ll be sure to check it out, and I’ll be following where things go. If you’ve got any good swearing tweets coming up, I’ll keep an eye out. Thanks, Max.

Great. Thank you.

‍

Important Links

• Brew
• Tea
• MXCL/Homebrew
• Patreon - Max Howell
• xkcd