Episode 277 - Open Source Sagas with Max Howell
Max talks to Homebrew creator Max Howell about open source software, package managers, and his new project tea.xyz.
Max Howell
Max Howell: Website | LinkedIn | Facebook | Twitter
Links
Transcript
Max Sklar: You're listening to the Local Maximum episode 277.
Narration: Time to expand your perspective. Welcome to the Local Maximum. Now here's your host, Max Sklar.
Max Sklar: Welcome everyone, welcome! You have reached another Local Maximum.
Hope you enjoyed last week's episode on the Dictator of Easton as much as I did. I always like tapping into my past creativity to see if there's anything I can revive there and in this case, there was. If anyone saw that episode, I would like to hear your thoughts about it. Head to the localmaximum.locals.com, or email us, localmaxradio@gmail.com.
We're going to talk today about open-source software, who works on it and why and how you can join an open source community, and how exciting it really is. And not to mention some developments coming around recently. We're gonna get into web3, all that.
My next guest is an open source software developer and he is the creator of the famous Homebrew package manager, which, if you develop on a Mac, like myself, you've probably been using it for years. He's also going to tell us about his latest package manager t.xyz, the revenge of web3. This guest also has a great name. Max Howell, you've reached the local maximum. Welcome to the show.
Max Howell: Thank you for having me.
Max Sklar: It's a pleasure. Very excited to have you on the show today. Let's start with the idea of open source. Well, first of all, before we get into open source software, why don't you tell us a little bit about yourself. Maybe, maybe a little bit about your background and some of your earlier projects, Homebrew in particular? What attracted you to open source software in the first place?
Howell: I didn't know what I was going to do with myself at school. I have many interests and I was good at quite a few of them. For some mysterious reason, I chose to do chemistry. So went off to university to do a chemistry degree. I did a master's, in fact. I really enjoyed aspects of it. And with hindsight, I realized the aspects I enjoyed were the ones that were so more similar to programming.
So I went off and did a year in industry and discovered that I hated working in industry for science, in general. I can see it extrapolates the whole science. And so I quit and fell into a depressed funk where I didn't know what I was doing in my life.
Sklar: What were the problems that you had with it when you were in science and industry?
Howell: I really enjoyed the first three months I was in industry working with the big machines
Sklar: Sure, that’s what I think because we’re just typing all day. But yeah, sorry. Go ahead.
Howell: Many ways wished I picked a career that involves not sitting at a desk all day but that's another story.
The big machines were fun. It was fun talking science for the people. Then after three months, went home for Christmas, came back and I realized when I got back that I would be using the same machine that I've been using for those three months for the next 10 years. That was my career trajectory. There was no way that I could advance in science without becoming an expert in one very niche area of it. And it depressed me.
I realized that everyone I was working with was happy with the status quo. Nothing really changed. Nothing was moving very fast. I wasn't going to change the world. So yeah, those sort of things, really. In my depressed funk, I discovered open source and Linux.
Sklar: You'd think that someone who's been in software for a long time, you kind of imagine science as being, maybe just as fast, just as innovative. But I guess that's not the reality.
Howell: Well you know, I only did it for a year so I'm sure that there are places where it can move fast. Sadly, my impression was that it doesn't. I felt that way when I was at university towards the end anyway, when I was working with professors and they'd spent years working on tiny little pieces of problems. And when I would talk to them about how this could be used in the real world, they were like, “Oh, I don't care about that.” They didn't care about applying. It was just the pursuit of knowledge.
Sklar: It sounds interesting, the pursuit of knowledge. But I feel like sometimes, application is a lot harder than people give it credit. It's almost sometimes the hardest thing.
Let's go with open source software. What attracted you to open source specifically? How does that actually work in practice? Maybe we could even start with a basic what is open source?
Howell: Hm, what is open source? I find myself asking that question a lot over the last 18 months.
Open source is the desire to fix problems but also the desire to do it with a bunch of other people. The knowledge that it requires all these other people working in different ways to improve the system. It's all about improving the system. We built this elaborate machine that we call Unix, Linux, Windows, Extent through Linux. Over the last 25 years, we've been building on top of every piece that we built before and all of us have to do this together. It's a kind of super intelligence, all of us coming together to try and build this machine that will do the things we need it to do.
There's lots of pieces to it and there's lots of factor offshoots that go all over the place. But all these pieces come back and integrate with each other and build on top of each other and become better by being the sum of more than just their pieces. And it's addictive, being part of that.
I think a lot of people don't even realize that working with large groups of remote people with different agendas and different desires is actually super fun. Find this super fun. I didn't expect to like that. I have to say, it wasn't what attracted me to it in the first place.
What attracted me in the first place was I was bored and depressed and I'd heard about Linux, so I installed it. And then when I installed it, I discovered that it was shit. But it was also super great in so many ways. I could see how I could improve it. I could see how I could get in there and just the bits I didn't like, I could fix it. That was the mantra. That was all you ever read on my Slack Blog, which is what I used to read back then. It was 2004-ish. People will complain and then the comment immediately afterwards that was rated plus five insightful was, “Well, it's open source. Why don't you fix it yourself?” Which is kind of like a passive. It's like the learn-to-code things that people are always saying.
Sklar: Yeah. right. You don't expect anyone to actually go in and take that seriously but people do.
Howell: Well it's vital that some people do. Which is kind of why I started this company, which we'll talk about later. It's vital that some people do.
Sklar: Yeah, I want to get into that in a minute. But when it comes to open source, I guess the question that I want to ask, which I kind of feel like you just answered, but I sort of want to ask it more explicitly is like, how do you know what to work on? And how do you know? Isn't it the same with anything when you're trying to be like, am I solving the right problem? Or, I guess in the case of Linux, were you thinking of more “Okay, there's some bug that everybody knows is a bug, that everyone's deals with so of course fixing that is a good idea.” Do you have any strategy in terms of picking your projects?
Howell: I often say to people that getting involved with open source is the fastest way to become the kind of programmer you want to be. When I'm talking to people who are still trying to figure out where they're going, and how they're going to learn all the things they need to learn. It’s super valuable. That's how I got into it. I didn't do a computer science degree, I did a chemistry degree and then managed to get myself into the industry via open source because it was like a fast track.
What would you get involved with? Certainly, something that you need is completely essential. If you don't want it, then you're not gonna do it. This is part of the problem with developers with 20,000 side projects, right? All 20,000 of them.
Sklar: I feel seen with that, but yeah, go ahead.
Howell: So the reason none of them ever get finished is because they're not really things that that person really wanted. It's a nice idea. I think a lot of the time people come up with nice ideas. But if you don't personally need it, you're definitely not going to make it with open source.
Now, maybe you can make business out there and that's motivating because you're gonna make some money. But with open source, if you don't personally need it, it's just not gonna get built. Or it's like something that you use and it has like a bar or you can see a feature that you personally need or it's a bug that personally pisses you off then that's a great way to get into it. But pick the right kinds of projects.
I think a lot of people will see VS code and see something which could be improved or has a bug because it always has bugs. Like they fix a bug, they make a bug. It’s just how it works with Microsoft, I think. But have you seen that codebase? No one wants to go in there. That's not a good choice. It’s too big, not really architected as much as evolved.
Pick a project that's small enough, preferably new enough. New is good because when you get involved with a new project, they go, “Hey, do you want to get involved more? Because we don't have anyone who is involved more yet.” With Homebrew, the people who turned up in the first six months were the people who were still there four years later. They were the ones that everyone was turning to and saying this is the expert in this project because I've been there since the start.
Sklar: Yeah, that almost reminds me. There's some companies where, not every project is like this, but you're working on something that you use every day. Those are always the most fun because then it's like, you don't even need to. It's like, even if it's not open source, sometimes it is, but all the employees are like, oh, let me fix this, let me fix that because they know what the problems are.
Let's get into the main event. What's the idea behind t.xyz? And just to give a little adversarial question, wasn't your package management solved with Homebrew? Why do we need this new one?
Howell: I’m not sure how many times I’ve been asked in the meantime.
So Brew. I made Brew in 2009. It was a project I needed personally like I was just saying.
Sklar: It blows my mind that that only existed. I guess 2009 is a long time ago now but I guess it blows my mind that it's not even that new or that old. I don't know.
Howell: When you start looking, it's a completely different conversation.
Sklar: Like when I was in school it didn't exist.
Howell: Yeah, some of these projects are a lot newer or a lot older than you think. They become indispensable over time, a period of years. Homebrew, I'd say it took about three to four years before people considered it indispensable then it's been another 10 since then. It’s a huge monolith at this point.
So I made it in 2009. I was challenged by a coworker to stop moaning about this tool that I wanted to build or didn't exist, to do something about it. So I did. It was just like that, really. I just did. One weekend, I just started, quote, programming it. The name was because I came up with the idea in a pub.
Drinking was actually kind of revered in programming at the time. This was very early work too. GitHub used to boast about how they had a tap on their programmers' floor. You could just pour yourself beer. Can you imagine GitHub boasting about that now? Certainly not.
It seemed like a cool idea for name and theme and I built it, and it was good. So I open sourced it and then the rest is history really. It got attention quite quickly. Hacker News went crazy all over it, which is probably the first and last time they've liked anything I've ever done. Hacker News is just a source of toxicity really, isn’t it?
Sklar: How did you know that this tool was needed? I don't even know. How did people do package management before then?
Howell: Well, there were other package managers. There was two major ones actually for Mac. MacPorts, which was a fairly literal, literal ball of ports from FreeBSD to Mac. And Fink, which I don't know as much about.
Sklar: Am I crazy that I’ve never heard of these in the industry for however long?
Howell: MacPorts still exist. It's better than it used to be, certainly. But it didn't capture the imagination nearly as much as Brew. Homebrew really just exploded.
So yeah, there was tools but they weren't very good and they lacked the things. And what I really wanted which was one that was more hackable, more developer-focused. I got into open source years before that, at this point. I've done a lot of packaging because it's just necessary when you're working with Linux and open source and you're trying to help other people to install your source code.
So I came at it from the perspective of I want it to be easier for everybody, developers and users alike, to get the things they want. Because that's the attitude I've always had with my package managers. They're kind of an unsexy, boring tool and what you want is for them to get out of the way so you can get on with what you really want to do, which is use some tool or app or library or framework or integrate something, get all the dependencies set up, and then bugger off. That's what you want. So I came at it from that perspective.
Timing was great because Mac was just becoming the choice for developers. Before that really wasn't. It was a mix between Windows and Linux. And because OSX came along and decided to be Unix rather than Mac OS, which was what they called it before it was its own custom thing. It attracted a lot of Linux guys over. It just was the moment and I built it in Ruby. Ruby and Rails just became something that was super popular. It captured a lot of mindshare and interests and just took off.
But why do we need another one? That's the question. Is Brew good enough? That's the thing, it is good enough? I don't want to shit all over my creation too much but worked on it in a long time. Like 2015, 2016? I burned out because I did do a lot of work on it. Tens of thousands of hours easily. I quit jobs regularly in order to work on it full time. And then when I had a full-time job, I had two full-time jobs, because one was Homebrew.
It’s a huge amount of contributions to manage, massive community formed and I loved working on it. I was very proud of it. And I wanted it to succeed, completely determined.
So yeah, I eventually burned out and I passed it to the community, which had formed. I was part of governance until a couple of years ago. Still, honestly, I didn't really participate a huge amount. I felt like I was done. It was good enough. And that's the thing, it's only good enough.
There's so much more that can be done at the package manager layer and that's what we're trying to do with T. We're splitting the tool into two. This is news. By the time this podcast comes out, it'll be live. So we got a command line interface and a graphical interface. And the graphical interface is where I think a lot of the innovation will happen over the year. Though, the CLI itself is still awesome. We have what we call magic, which makes it so you don't even think about installing packages. You just type the commands you want and it finds them, installs them, makes it work.
It seems a bit archaic, really, the whole managing packages business. It's the kind of tool that someone who really loves what they built forces down your throat. “I am so proud of this. You're going to have to think about it. You must think about how to manage your packages. How dare you even consider the idea that you shouldn't.” So you don't have to anymore, with T.
Everything's isolated developer environments. I think Docker had the right idea with making it so you can have little containers. But I think they had the wrong idea in that you have to spin up a whole frickin virtualized Linux instance. Developing inside of Docker is a pain in the butt. So we've got containerization, like thin containers, essentially, at the development layer.
And, yes, scripts are cool but they suck because you can't get the packages. So with T, you can just get all the packages. You put the YAML front matter at the beginning of scripts, and then when you execute it, it just installs and stuff.
And the GUI is gonna be cool. I won't go into the features. We're going to roll them out this year. So it's just there's so much more that could be done and nobody did it. Package managers are stagnant. They haven't really changed since the first one 25 years ago. Slackware, I think, came up with it.
Sklar: So why do you think that is? Is it because there just isn't demand for this innovation? Or is it some problem with the fact that everyone's working for free, essentially?
Howell: Yeah, I don't know. I wondered about that.
Sadly, if I had known how tedious packaging was going to be before I wrote Brew, I might not have done it. There's an awful lot of frustration involved in packaging up the software but you get good at it. And now I'm good at it again because it took me probably 12 months to get good again after starting T to remember all the tricks and then learn all the new ones. A lot of stuff changed.
It's frustrating and it's not sexy. No one really likes-. I get a lot of people come up to me and thanked me for Brew and they love it, they say, they claim. At least that's what they say to my face. But really stop the act, right? Stop the act.
Sklar: People don’t complain about Brew. No, no, people are not complaining about Homebrew behind your back. I don't think, I don’t hear any.
Howell. Well, it has problems
Sklar: Every piece of software has people complaining about it though.
Howell: Homebrew became really slow over time. And they sped it up a bit recently for certain operations, but still slow. T is five to six times faster, we've done the measurements. It's clunky, Brew. It's not the same as it used to be. It doesn't work as well as it used to. But when I was more actively working on it, it was a simpler set. There were less packages in it, less platform supported so I understand.
But T navigates with a cross-platform. We support Linux and Mac, both first classes. And then Windows WSL2 is because it's Linux, the same. But we're working on the Windows native version as well. We think that you should be able to use whatever platform you want. And then the package manager, we’re trying to essentially build the universal package manager. So people can be enabled to do everything they need to in the world, whatever their profession.
Sklar: Gotcha, gotcha. Is there like a… It's my understanding, what's the web3 portion of this work? Is that something that you to-. I heard there was a token involved. Is that true? Explain to me what the deal is with that.
Howell: So the web3 part is the whole reason I did this because after I stopped working on Brew all the time, I didn't stop taking notes about features I wanted to add to it, things I wanted it to do. But I didn't have the motivation to do it again. I moved on to, I did a lot of iPhone apps, did a load websites, went with a bunch of different startups. And I didn't even have the time, I wasn’t gonna spend another 10,000 hours on a project.
But I still wanted the tool. And that was when I started looking into web3 stuff with the last bull market run. I had a friend who was always trying to get me into crypto. I had a friend who was trying to get me into just about everything at one point or another. And crypto never really appealed.
I think I'm a bit unique in the web3 space, in that, I never really saw the point until I started looking into it a little bit more carefully. Bought an NFT, sold an NFT, sold the smart contracts at 10% of what I sold it for to the original artist. I had a moment of inspiration about it. I saw how I can use smart contracts to do the same for the open source ecosystem.
People have tried to fund open source since its inception, really. It’s only the last 10, 15 years, I'd say, that it became the foundation of all modern software. Before that, Microsoft had quite a monopoly and a lot of stuff ran on Windows. But open source proved that it was a better value proposition and a better innovation platform and so Windows fell aside. But in the process of that happening, all the people building open source didn't take all that money that Microsoft were raking in. They didn't get that share, it didn't come to them.
People like me would find that they wanted to work on open source, but they couldn't figure out how to do it. So many times I tried. I had a Patreon for a bit. I tried to run a blog where I posted things you could subscribe to or content. And it was just not part of what the work I wanted to do. I didn't want to sell myself, have to market myself so I stopped both times when I didn't have anything near enough to live on.
Sklar: It's hard work. It’s possible and there are a lot of projects that do that but it's hard work.
Howell: I know people who do and I talked to them about it while I was trying to do it. And they would spend years on it, I think as well as also part of the problem. But I'm not a crater economy kind of person. I'm a I want to build cool stuff kind of person. Everything else is tedious.
Even documentation, which I know is so important so I do a good job of it. But I do a good job because I know it's vital. Marketing myself doesn't feel vital.
Sklar: I wonder if there's anyone who really loves writing documentation?
Howell: I know one and I’m desperately trying to hire him.
Sklar: Okay. Yeah, I can see that.
Howell: Maybe I have better luck with it than anyone else can. Because web3’s got a huge stigma and I found it hard to hire some people who I know are great. I understand why it's a huge stigma, there's just so many scams. So many scams, people trying to get your money.
But people say that what we're building is like the first time they've seen a use for crypto that makes sense. There’s a genuine utility and that makes me feel good about it.
The idea is to fund open source, obviously. The way we're going to do it is by building the package manager graph into the blockchain. So the registry, the information about all open source software, put it all online. Then this information allows us to float open down that dependency graph. So if a token enters at the top for something that people actually know about and care about, like an app of some kind, or a top-level framework, then all the dependencies all the way down to lib C, end up getting a little piece of that token. So it breaks off every time a little percentage all the way down. One of the big differentiators between us and what people have tried before is the idea of funding the whole graph. Not just the tips, not just the points.
Sklar: Would you be funding the whole graph? Because you'd be… The way I understand it, and correct me if I'm wrong, is you're saying is if we're funding the top-level project, but that project uses like five other projects, then each one of those is going to get a cut, and then maybe those use other projects, and so on and so forth?
Howell: Yep, a cut. A little cut all the way down powered by smart contracts and the fact you can divide the crypto into such small pieces.
Sklar: This might be a question that goes nowhere, but the only thing that popped into my head was what if there's a circular dependency?
Howell: Yeah. So we've taken that into account. We're using Google's PageRank algorithm, essentially. It was always the idea that it would use something like that but one of my staff pointed out there was a natural fit so we've been using that. PageRank has a mechanism for preventing circular dependencies from increasing the rank exponentially. It just works, in other words.
Dependencies are more complicated than that. We've had to figure out if a build dependency is as valuable as a runtime dependency. Because if you build a tool that uses rust, it only uses rust when you build. It doesn't use it when you run it. But it’s equal as far as we're concerned.
Once the system works, it will incentivize open source in whole new ways like allowing people to identify areas that are getting too much more than they deserve. And seeing that that means there must be a niche there to create some kind of new library that fulfills something that's more specific or even more generalized, perhaps. That'd be up to them to figure it out.
Sklar: The edge of the graph, where does that funding come from? Like, who's going to have to pay for what on the end user?
Howell: We got a proof of stake network, which pleases people who think proof of work is bad for the climate, which I don't think they're wrong about. I don't think it's hugely bad when you compare it with things. But yeah, it's proof of stake.
So you, as someone who's interested in open source will stake against the projects that you use. And T CLI or T GUI will be able to tell you what those projects are because we're integrated with your system, we know what you're using. This would be great for companies like Microsoft who could just pull all the T instances installed to get their entire graph staked to them.
So staking systems give you rewards every epoch like every, whatever two days, I think. And that reward will be distributed to the person who's staking and to the things they're staking against. And then it flows down.
So people who are interested, who believe in the value of open source can be rewarded for that. They identify projects that are worth staking, then they’ll be rewarded in proportion to that. Also, they'll be able to fund the open source ecosystem, a sort of a double bonus for them.
We're not going to charge a micropayment for installing packages or anything like that which is something people often think we’re going to do. I came into this knowing that it had to be an innovation that didn't change how people fundamentally use open source currently. I could build a package manager that said every time you install it's going to be point one cent. But it just wouldn't take off. People say they want to fund open source, but actually they don't. Which is why we've created a system where it's more like investing.
Sklar: Yeah so it's more like investing. So if I stake against an open source project, what incentive do I have to do that?
Howell: Because you’d be paid stake rewards
Sklar: Okay. Is it somehow like a… I guess I'm trying to think, it kind of makes me want to read more into this. How does it actually… Does it fund the project itself? Does a portion of the staking rewards go to the developers or something like that?
Howell: Yeah so it's a good question because it's complicated. Every open source project is different. They have different people who are active and maybe they also want to try and fund people who do pull requests and things like that. And that's another beautiful thing about building some crypto. We're building it with EVM-compatible blockchain so that people can write their own smart contracts on top of that. We're going to encourage that.
So every project will have a wallet, which is where the funds go. And we encouraged you to be multisig about that. But we will then insist that you form a DAO, a decentralized autonomous organization for that wallet. So you’ll spin up a smart contract. We’ll give you a bunch of templates. That contract will describe how the token is distributed and who it is distributed to. So you could have one where it only goes to yourself. And I'm sure some people will do that, even though they have a project where they have multiple people working on it. But if you are the sole maintainer, that makes sense.
You can pick one where a percentage is set aside to fund pull requests. So other participants can receive token rewards for their contributions. Or you could fund translations. There's so many options, I'm pretty excited to see what people will do with it.
So yeah, we're launching a few template options, suggesting you go one of these different types and then we'll see what the community uses. Because every project is different, every project has a different situation.
Sklar: Do you have any specific projects that are examples that want to build off this or are building off of this currently?
Howell: None of the big ones I've approached have shown a great deal of interest. And I'm not surprised. The big ones have already figured out their funding methodology or they’re content enough with how things are going.
What happened a lot over the last 10, 15 years was companies would hire the people working on these projects. Which, it sounds like a great solution but I think, actually, it's been quite negative. So you can get paid to work on your project full time but then the company ends up putting some of your time towards other things as they need you or they have an agenda. Open source is for everybody, not just for Microsoft or Facebook or Google. Recently, Kubernetes is falling apart because Google have been doing that with the staff that work on it that they hired.
Sklar: Is it that they make demands on their time? Or is it that they kind of subvert the project to their ends?
Howell: It’s a bit of both. Nothing's that nefarious, I make it sound like these are villainous people. It's impossible for there not to have been some consequences that end up shaping the project. It’s good for people to see that things are bad, and then they spin out more and there are no alternatives and that just propagates all over the place.
To answer your question, big projects, probably one, at least initially. But the smaller ones, now I get a hell of a lot of interest from those. The ones where it is like someone's side project that turned into a bigger project that turned into a bigger project. And they're working on it, like all these hours that they don't really have, and they have a full-time job. They would love to work on these projects full-time or even spin up a couple more open source projects and try to make three of them work for them.
I want T token to represent the genuine value of open sources. That's what its potential is. The market cap for T token could be that of the entire open source ecosystem’s value. And if it does become that, then it will be easy for it to fund people's salaries or to pay equivalent to a fang position.
Sklar: That would sound Amazing. Do you have any more specific examples of anyone you've spoken to? First of all, what's the status of T XYZ? Can you use it today? Are certain projects on it already?
Howell: The package manager is up. The CLI, as we call it, it's been up since November. It's getting some great feedback. It's a cool tool, worth checking out, honestly, it's better than Brew.
Sklar; Well I hope so. If you did it the first time, I hope you learned something over the last 10 years.
Howell: It's a lovely thing. I really like it. It's my finest work. That's getting good growth. By the end of the year, I reckon we'll have a million users which is good. But Brew never did a million in a year but this time around, I got my fame which is helping.
And then we're launching the GUI in May. So probably by the time this podcast is up, people will be able to grab that. I think the GUI is super awesome. Every day, I look forward to the new nightly builds to see what my developers have put into it.
The protocol or the blockchain component, we're launching that later this year. So we'll have a tester app, hopefully by Q4. And then the blockchain main net, probably end of the year is pushing it, so probably early next year. If you have the CLI or the GUI installed, then you'll be ready to use the protocol both as an open source developer with projects or as someone who's just interested in participating, getting those stake rewards based on the value of open source software.
Sklar: Very cool. Very cool. Where can people learn more about this? And do you have any like, last concluding thoughts about this whole discussion?
Howell: Yeah, so t.xyz is our domain. It was the only T domain that I could get. And I was like, I want a three-letter domain. I actually really like it with hindsight. It's got good SEO. There's no other T XYZs out there.
It's got all the info, you can go to GitHub, you can install the CLI. We got a one-liner batch installer like every dev tools project. Or it's a single binary download. You don't need to install it, you can just download the binary, put it wherever you want and it will work because I know people hate those installers. Although ours is fine, just like everybody else is. I did wonder for a while if there was a way to work around that. The GUI makes it simpler actually. Anyway, I’m getting off-topic.
Sklar: No, I'd be interested to see what that looks like because I feel like it could kind of point you in the right direction to your projects. And maybe you could do things like, I mean, I don't know if this is a bad idea or a good idea but if you had a graphical interface that could include things like recommendations. I don't want to turn it into a whole news update. But productivity recommendations, you know?
Howell: Yeah, totally. Like I say, there's so much potential with the package manager layer. There's all this wonderful open source software and half of it no one's ever heard of because there's just so much haven’t discovered that. The place to do it is some app that knows what you've installed and can recommend other pieces. So we're totally, really excited about what we can do over the course of this year after we've released the first iteration of that.
I’ve never really done this before. For sure people have made GUIs for package managers but it's literally just a copy of the interface into the GUI with no real consideration for what could be done that's different. And so as a result, download never caught on because what's the point? You didn’t add anything.
Sklar: Yeah exactly. It just slows you down.
Alright, this sounds really cool. I'm looking forward to check it out. The website is t.xyz. Max, thank you so much for being on the show. I'll give you the last word. If there's anything else that you want to add before we head out.
Howell: Yeah, well check out T and we're always looking for people to get involved with the community. This is a good time to do so because it's new. Like I was saying, the time to get involved with open source is when the projects is new because then if you do like it, you become a vital part of that piece of software and the community that evolves.
Sklar: All right, awesome. Great advice. Thanks a lot.
Howell: Thank you.
Sklar: All right. I hope you enjoyed that and also last week's episode on the Dictator of Easton. After a few weeks of those kinds of episodes. I think I have some commentaries to get off my chest, some issues that need airing. So maybe we'll spend a few episodes hearing from me and maybe Aaron on that. Have a great week everyone.
Narrator: That's the show. To support the Local Maximum, sign up for exclusive content and our online community at maximum.locals.com. The Local Maximum is available wherever podcasts are found. If you want to keep up, remember to subscribe on your podcast app. Also, check out the website with show notes and additional materials at localmaxradio.com. If you want to contact me, the host, send an email to localmaxradio@gmail.com. Have a great week.
