ivabus/www
1
0
Fork 0
mirror of https://github.com/ivabus/www synced 2024-11-22 14:45:05 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions

Adding content from Medium

Browse source
This commit is contained in:
tsmitty11 2023-05-18 14:33:59 +02:00
parent e0bdbc710b
commit 6f98ce2d47
4 changed files with 54 additions and 147 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

52
src/content/blog/dev_diary-finding-the-fun-2.md
View file

@ -1,52 +0,0 @@
---
title: "dev.diary—Finding the Fun"
date: 2023-01-23
draft: false
featured_image: "/Images/techcrunch-gen-art.jpg"
---
When building any kind of product it takes a little time before you figure out its shape. Famous games developer Sid Meier described this process as “finding the fun”. He would iterate compulsively on his ideas until those little changes in the little details would uncover something sufficiently new and engaging that he had the basis for a new game.
This is the approach I take with my products. From my childhood writing toys in BBC Basic, to working on the amaroK music player for KDE in the early 2000s, to making the Android version of TweetDeck in 2010, to how I approached making Homebrew and now with its spiritual successor: tea.
We released tea/cli a couple months ago. At that point I felt the product was “ready enough” for general consumption. We had a number of compelling features coupled with a good mission statement and together to me that seemed enough to present it to the community and start gathering wider ideas and interest.
Which is a key differentiator between developing most products and developing open source: you bring your userbase in before you’ve “found the fun”.
Before launch I jokingly would say that tea was not a package manager. I was being flippant. But also I wasn't being flippant. Package Managers as a class of tool haven’t evolved since their inception in the 90s. They are very much in the what I call “egotistical tool” category: that being: you *will* learn how it works thank you very much because the package manager is a very important tool and you are lucky to have it. I’ve not a fan of this attitude.
I believe tools are a special class of utility. A well written tool completely eradicates entire classes of tedium enabling its users to reach new heights in productivity. A well written tool enables functionality that before was either too tricky to accomplish or completely impossible.
At launch we said tea was a universal interpreter, a universal environment manager, a unified dependency manager and it could run executable markdown.
Changelog rightly called me out on this, saying “might Max and the team be thinking too big this time around?”
The truth is we hadn’t yet quite found the fun.
Two months of passionate early adopter usage later and a few things were becoming apparent. tea’s real super powers were the underlying rethinking about the nature of package management, specifically that with tea the package manager disappeared. So I decided to experiment with doubling down on that.
At launch you could type tea -X npm startand tea would look for npm and run start , but if it didn’t find npm it would fetch it first. This was in fact a very near launch addition by me but it was a truly wonderful reduction in friction for using the open source ecosystem. And fundamentally what this feature said was: the package manager needs to get out the way.
tea doesn’t install packages—at least not in a conventional sense. In the above example npm is not available unless you type tea -X npm otherwise it is “stowed” in ~/.tea . This is important since I want using tea to complement your system. tea is not an operating system, it is a complement to whatever system (Mac, Linux, Windows, etc.) you are using.
Soon after a passionate early adopter of tea suggested that symlinks to tea should behave as though tea -X foo bar was called. So we implemented that and immediately it was apparent that this was a seriously cool feature. I used this to create a symlink from tea to bpb (a tool that makes signing your git commits trivially easy) and immediately knew that forever more I would not have to piss about for an hour getting my git-signing set up whenever it stopped working or a had to set myself up on a new machine, remote server or when clean installing my OS.
A developer at tea realized that you could make the shell’s command-not-found handler call tea -X . Command not found handlers have been used by the package manager before. For example, Ubuntu uses it to suggest packages that may satisfy whatever you typed. The idea made me laugh because it seemed so ill-advised! But we added it to the README as a hack that users may want to try out—for fun.
But I got to wondering… had we in fact found the fun? I decided to add the command-not-found handler to my shell and see how I liked it.
After a few days I stopped laughing. I started getting excited. This hack wasn’t a hack. It was awesome. It completely delivered on tea’s promise and significantly simplified our narrative.
How do you use tea? You don’t. You use the tools that the open source ecosystem provides. If you read a blog post about a new tool then just type the commands you read into your Terminal and try it out. There’s no “figure out the package name and then install it step”. There’s no “will installing this break other stuff on my system” concerns. If you don’t like it then don’t worry about it—it’s already gone.
tea still is a “universal interpreter” but that just falls under the general banner; we don’t have to explicitly name this feature; tea just knows how to make what you throw at it work. Be that a command or a script, tea makes it possible for you to get on with what matters: making your app.
And so I dropped executable markdown completely. Part of the reason I added exe/md was the desire for tea to be a tool that makes development a dream. And we have achieved this because now if you want to use executable markdown to run the script build you just type xc build and tea installs xc transparently. Whatever “task runner” your project needs is transparently available. Having this feature in tea itself no longer made sense.
When it comes to making great products you need to be able to drop entire features without ego or the sunk-cost fallacy holding you back. What matters is the entire product vision no matter how cool you think something is. I still think exe/md is a cool idea, and didn’t know about xc before writing it. I’m very glad someone else thought the same and built it. UNIX tools should do one thing and one thing well.
tea 0.19 lives up to the UNIX philosophy and thanks to Changelog for reminding me about that. I revisited every part of the CLI and retooled it towards this purpose. Check out the new README for the deets, the caveats and what comes next:
https://github.com/teaxyz/cli

52
src/content/blog/dev_diary-finding-the-fun-3.md
View file

@ -1,52 +0,0 @@
---
title: "dev.diary—Finding the Fun"
date: 2023-01-23
draft: false
featured_image: "/Images/techcrunch-gen-art.jpg"
---
When building any kind of product it takes a little time before you figure out its shape. Famous games developer Sid Meier described this process as “finding the fun”. He would iterate compulsively on his ideas until those little changes in the little details would uncover something sufficiently new and engaging that he had the basis for a new game.
This is the approach I take with my products. From my childhood writing toys in BBC Basic, to working on the amaroK music player for KDE in the early 2000s, to making the Android version of TweetDeck in 2010, to how I approached making Homebrew and now with its spiritual successor: tea.
We released tea/cli a couple months ago. At that point I felt the product was “ready enough” for general consumption. We had a number of compelling features coupled with a good mission statement and together to me that seemed enough to present it to the community and start gathering wider ideas and interest.
Which is a key differentiator between developing most products and developing open source: you bring your userbase in before you’ve “found the fun”.
Before launch I jokingly would say that tea was not a package manager. I was being flippant. But also I wasn't being flippant. Package Managers as a class of tool haven’t evolved since their inception in the 90s. They are very much in the what I call “egotistical tool” category: that being: you *will* learn how it works thank you very much because the package manager is a very important tool and you are lucky to have it. I’ve not a fan of this attitude.
I believe tools are a special class of utility. A well written tool completely eradicates entire classes of tedium enabling its users to reach new heights in productivity. A well written tool enables functionality that before was either too tricky to accomplish or completely impossible.
At launch we said tea was a universal interpreter, a universal environment manager, a unified dependency manager and it could run executable markdown.
Changelog rightly called me out on this, saying “might Max and the team be thinking too big this time around?”
The truth is we hadn’t yet quite found the fun.
Two months of passionate early adopter usage later and a few things were becoming apparent. tea’s real super powers were the underlying rethinking about the nature of package management, specifically that with tea the package manager disappeared. So I decided to experiment with doubling down on that.
At launch you could type tea -X npm startand tea would look for npm and run start , but if it didn’t find npm it would fetch it first. This was in fact a very near launch addition by me but it was a truly wonderful reduction in friction for using the open source ecosystem. And fundamentally what this feature said was: the package manager needs to get out the way.
tea doesn’t install packages—at least not in a conventional sense. In the above example npm is not available unless you type tea -X npm otherwise it is “stowed” in ~/.tea . This is important since I want using tea to complement your system. tea is not an operating system, it is a complement to whatever system (Mac, Linux, Windows, etc.) you are using.
Soon after a passionate early adopter of tea suggested that symlinks to tea should behave as though tea -X foo bar was called. So we implemented that and immediately it was apparent that this was a seriously cool feature. I used this to create a symlink from tea to bpb (a tool that makes signing your git commits trivially easy) and immediately knew that forever more I would not have to piss about for an hour getting my git-signing set up whenever it stopped working or a had to set myself up on a new machine, remote server or when clean installing my OS.
A developer at tea realized that you could make the shell’s command-not-found handler call tea -X . Command not found handlers have been used by the package manager before. For example, Ubuntu uses it to suggest packages that may satisfy whatever you typed. The idea made me laugh because it seemed so ill-advised! But we added it to the README as a hack that users may want to try out—for fun.
But I got to wondering… had we in fact found the fun? I decided to add the command-not-found handler to my shell and see how I liked it.
After a few days I stopped laughing. I started getting excited. This hack wasn’t a hack. It was awesome. It completely delivered on tea’s promise and significantly simplified our narrative.
How do you use tea? You don’t. You use the tools that the open source ecosystem provides. If you read a blog post about a new tool then just type the commands you read into your Terminal and try it out. There’s no “figure out the package name and then install it step”. There’s no “will installing this break other stuff on my system” concerns. If you don’t like it then don’t worry about it—it’s already gone.
tea still is a “universal interpreter” but that just falls under the general banner; we don’t have to explicitly name this feature; tea just knows how to make what you throw at it work. Be that a command or a script, tea makes it possible for you to get on with what matters: making your app.
And so I dropped executable markdown completely. Part of the reason I added exe/md was the desire for tea to be a tool that makes development a dream. And we have achieved this because now if you want to use executable markdown to run the script build you just type xc build and tea installs xc transparently. Whatever “task runner” your project needs is transparently available. Having this feature in tea itself no longer made sense.
When it comes to making great products you need to be able to drop entire features without ego or the sunk-cost fallacy holding you back. What matters is the entire product vision no matter how cool you think something is. I still think exe/md is a cool idea, and didn’t know about xc before writing it. I’m very glad someone else thought the same and built it. UNIX tools should do one thing and one thing well.
tea 0.19 lives up to the UNIX philosophy and thanks to Changelog for reminding me about that. I revisited every part of the CLI and retooled it towards this purpose. Check out the new README for the deets, the caveats and what comes next:
https://github.com/teaxyz/cli

41
src/content/blog/dev_diary-finding-the-fun.md
View file

@ -6,47 +6,52 @@ tags: [open-source, homebrew, programming]
draft: false draft: false
featured_image: "/Images/techcrunch-gen-art.jpg" featured_image: "/Images/techcrunch-gen-art.jpg"
--- ---
When building any kind of product it takes a little time before you figure out its shape. Famous games developer Sid Meier described this process as “finding the fun”. He would iterate compulsively on his ideas until those little changes in the little details would uncover something sufficiently new and engaging that he had the basis for a new game. When building any kind of product it takes a little time before you figure out its shape. Famous games developer Sid Meier described this process as “finding the fun”. He would iterate compulsively on his ideas until those little changes in the little details would uncover something sufficiently new and engaging that he had the basis for a new game.
This is the approach I take with my products. From my childhood writing toys in BBC Basic, to working on the amaroK music player for KDE in the early 2000s, to making the Android version of TweetDeck in 2010, to how I approached making Homebrew and now with its spiritual successor: tea. ![](https://miro.medium.com/v2/resize:fit:1024/1*Y25rtCmwlRMmcRlef-mlFA.png)
We released tea/cli a couple months ago. At that point I felt the product was “ready enough” for general consumption. We had a number of compelling features coupled with a good mission statement and together to me that seemed enough to present it to the community and start gathering wider ideas and interest. This is the approach I take with my products. From my childhood writing toys in BBC Basic, to working on the amaroK music player for KDE in the early 2000s, to making the Android version of TweetDeck in 2010, to how I approached making Homebrew and now with its spiritual successor: `tea`.
Which is a key differentiator between developing most products and developing open source: you bring your userbase in before you’ve “found the fun”. We released [tea/cli](https://github.com/teaxyz/cli) a couple months ago. At that point I felt the product was “ready enough” for general consumption. We had a number of compelling features coupled with a good mission statement and together to me that seemed enough to present it to the community and start gathering wider ideas and interest.
Before launch I jokingly would say that tea was not a package manager. I was being flippant. But also I wasn't being flippant. Package Managers as a class of tool haven’t evolved since their inception in the 90s. They are very much in the what I call “egotistical tool” category: that being: you *will* learn how it works thank you very much because the package manager is a very important tool and you are lucky to have it. I’ve not a fan of this attitude. Which is a key differentiator between developing most products and developing open source: you bring your userbase in **_before_** you’ve “found the fun”.
Before launch I jokingly would say that _tea was not a package manager_. I was being flippant. But also I wasn't being flippant. Package Managers as a class of tool haven’t evolved since their inception in the 90s. They are very much in the what I call “egotistical tool” category: that being: you \*_will_\* learn how it works thank you very much because the package manager is a **very important tool** and you are lucky to have it. I’ve not a fan of this attitude.
I believe tools are a special class of utility. A well written tool completely eradicates entire classes of tedium enabling its users to reach new heights in productivity. A well written tool enables functionality that before was either too tricky to accomplish or completely impossible. I believe tools are a special class of utility. A well written tool completely eradicates entire classes of tedium enabling its users to reach new heights in productivity. A well written tool enables functionality that before was either too tricky to accomplish or completely impossible.
At launch we said tea was a universal interpreter, a universal environment manager, a unified dependency manager and it could run executable markdown. At launch we said `tea` was a universal interpreter, a universal environment manager, a unified dependency manager and it could run executable markdown.
Changelog rightly called me out on this, saying “might Max and the team be thinking too big this time around?” [Changelog rightly called me out on this](https://changelog.com/news/491E), saying “might Max and the team be thinking _too_ big this time around?”
The truth is we hadn’t yet quite found the fun. The truth is we hadn’t yet _quite_ found the fun.
Two months of passionate early adopter usage later and a few things were becoming apparent. tea’s real super powers were the underlying rethinking about the nature of package management, specifically that with tea the package manager disappeared. So I decided to experiment with doubling down on that. Two months of passionate early adopter usage later and a few things were becoming apparent. tea’s real super powers were the underlying rethinking about the nature of package management, specifically that with tea the package manager disappeared. So I decided to experiment with doubling down on that.
At launch you could type tea -X npm startand tea would look for npm and run start , but if it didn’t find npm it would fetch it first. This was in fact a very near launch addition by me but it was a truly wonderful reduction in friction for using the open source ecosystem. And fundamentally what this feature said was: the package manager needs to get out the way. At launch you could type `tea -X npm start`and tea would look for `npm` and run `start` , but if it didn’t find `npm` it would fetch it first. This was in fact a very near launch addition by me but it was a truly wonderful reduction in friction for using the open source ecosystem. And fundamentally what this feature said was: **the package manager needs to get out the way.**
tea doesn’t install packages—at least not in a conventional sense. In the above example npm is not available unless you type tea -X npm otherwise it is “stowed” in ~/.tea . This is important since I want using tea to complement your system. tea is not an operating system, it is a complement to whatever system (Mac, Linux, Windows, etc.) you are using. > tea doesn’t _install packages_—at least not in a conventional sense. In the above example `npm` is not available unless you type `tea -X npm` otherwise it is “stowed” in `~/.tea` . This is important since I want using tea to complement your system. tea is not an operating system, it is a complement to whatever system (Mac, Linux, Windows, etc.) you are using.
Soon after a passionate early adopter of tea suggested that symlinks to tea should behave as though tea -X foo bar was called. So we implemented that and immediately it was apparent that this was a seriously cool feature. I used this to create a symlink from tea to bpb (a tool that makes signing your git commits trivially easy) and immediately knew that forever more I would not have to piss about for an hour getting my git-signing set up whenever it stopped working or a had to set myself up on a new machine, remote server or when clean installing my OS. Soon after a passionate early adopter of tea suggested that symlinks to tea should behave as though `tea -X foo bar` was called. So we implemented that and immediately it was apparent that this was a seriously cool feature. I used this to create a symlink from `tea` to `bpb` (a tool that makes signing your git commits _trivially easy_) and immediately knew that forever more I would not have to piss about for an hour getting my git-signing set up whenever it stopped working or a had to set myself up on a new machine, remote server or when clean installing my OS.
A developer at tea realized that you could make the shell’s command-not-found handler call tea -X . Command not found handlers have been used by the package manager before. For example, Ubuntu uses it to suggest packages that may satisfy whatever you typed. The idea made me laugh because it seemed so ill-advised! But we added it to the README as a hack that users may want to try out—for fun. A developer at tea realized that you could make the shell’s command-not-found handler call `tea -X` . Command not found handlers have been used by the package manager before. For example, Ubuntu uses it to suggest packages that may satisfy whatever you typed. The idea made me laugh because it seemed so ill-advised! But we added it to the `README` as a hack that users may want to try out—_for fun_.
But I got to wondering… had we in fact found the fun? I decided to add the command-not-found handler to my shell and see how I liked it. But I got to wondering… _had we in fact_ **_found the fun_**? I decided to add the command-not-found handler to my shell and see how I liked it.
After a few days I stopped laughing. I started getting excited. This hack wasn’t a hack. It was awesome. It completely delivered on tea’s promise and significantly simplified our narrative. After a few days I stopped laughing. I started getting excited. This hack wasn’t a hack. _It was awesome_. It completely delivered on tea’s promise and significantly simplified our narrative.
How do you use tea? You don’t. You use the tools that the open source ecosystem provides. If you read a blog post about a new tool then just type the commands you read into your Terminal and try it out. There’s no “figure out the package name and then install it step”. There’s no “will installing this break other stuff on my system” concerns. If you don’t like it then don’t worry about it—it’s already gone. How do you use tea? You don’t. You use the tools that the open source ecosystem provides. If you read a blog post about a new tool then just type the commands you read into your Terminal and try it out. There’s no “figure out the package name and then install it step”. There’s no “will installing this break other stuff on my system” concerns. If you don’t like it then don’t worry about it—it’s already gone.
```
# want to see if bun will run your node project?$ bun run starttea: stowing bun^0.4bun: start$ which bunbun not found# ^^ it’s not in your PATH!$ bun --version0.4.0# ^^ but tea surfaces it for you
```
tea still is a “universal interpreter” but that just falls under the general banner; we don’t have to explicitly name this feature; tea just knows how to make what you throw at it work. Be that a command or a script, tea makes it possible for you to get on with what matters: making your app. tea still is a “universal interpreter” but that just falls under the general banner; we don’t have to explicitly name this feature; tea just knows how to make what you throw at it work. Be that a command or a script, tea makes it possible for you to get on with what matters: making your app.
And so I dropped executable markdown completely. Part of the reason I added exe/md was the desire for tea to be a tool that makes development a dream. And we have achieved this because now if you want to use executable markdown to run the script build you just type xc build and tea installs xc transparently. Whatever “task runner” your project needs is transparently available. Having this feature in tea itself no longer made sense. And so I dropped executable markdown completely. Part of the reason I added exe/md was the desire for tea to be a tool that makes development a dream. And we have achieved this because now if you want to use executable markdown to run the script `build` you just type `xc build` and tea installs [xc](https://github.com/joerdav/xc) transparently. Whatever “task runner” your project needs is transparently available. Having this feature in tea itself no longer made sense.
When it comes to making great products you need to be able to drop entire features without ego or the sunk-cost fallacy holding you back. What matters is the entire product vision no matter how cool you think something is. I still think exe/md is a cool idea, and didn’t know about xc before writing it. I’m very glad someone else thought the same and built it. UNIX tools should do one thing and one thing well. When it comes to making great products you need to be able to drop entire features without ego or the sunk-cost fallacy holding you back. What matters is the entire product vision no matter how cool you think something is. I still think exe/md is a cool idea, and didn’t know about `xc` before writing it. I’m very glad someone else thought the same and built it. UNIX tools should do one thing and one thing well.
tea 0.19 lives up to the UNIX philosophy and thanks to Changelog for reminding me about that. I revisited every part of the CLI and retooled it towards this purpose. Check out the new README for the deets, the caveats and what comes next: **tea 0.19** lives up to the UNIX philosophy and thanks to Changelog for reminding me about that. I revisited every part of the CLI and retooled it towards this purpose. Check out the new README for the deets, the caveats and what comes next:
https://github.com/teaxyz/cli [https://github.com/teaxyz/cli](https://github.com/teaxyz/cli)

56
src/content/blog/something-new-is-brewing.md
View file

@ -4,12 +4,11 @@ date: 2022-03-23
draft: false draft: false
featured_image: "/Images/techcrunch-gen-art.jpg" featured_image: "/Images/techcrunch-gen-art.jpg"
--- ---
I created Homebrew nearly 13 years ago out of sheer necessity. I found the tooling available to developers at the time haphazard and difficult to tease into shape. After complaining about it at the pub one evening, I was met with an exasperated “Max, quit whining and do something about it”. So I did. (Thanks Jono). I created Homebrew nearly 13 years ago out of sheer necessity. I found the tooling available to developers at the time haphazard and difficult to tease into shape. After complaining about it at the pub one evening, I was met with an exasperated “Max, quit whining and do something about it”. So I did. (Thanks Jono).
From the start, I designed it to be delightful where other tools were not. I have always firmly believed when building anything, especially open source, that the tooling should get out of your way because you have much more important work to be doing. From the start, I designed it to be delightful where other tools were not. I have always firmly believed when building anything, especially open source, that the tooling should get out of your way because you have much more important work to be doing.
I also intentionally designed it to go viral. I was lazy, you see, in the way all the best developers are. I needed you — all of you — to help me build it. I did this so well that Homebrew became one of the biggest open source projects of all time. I also intentionally designed it to _go viral_. I was lazy, you see, in the way all the best developers are. I needed you — _all of you_ — to help me build it. I did this so well that Homebrew became one of the biggest open source projects of all time.
Not long after starting, I quit my job to work on this project I felt I was put on the world to make. However… within a few months, the task was long from complete, and I found myself skint. I still remember going to the bank and asking what would happen if I overdrew the next day to pay for rent. They didn’t care much. Not long after starting, I quit my job to work on this project I felt I was put on the world to make. However… within a few months, the task was long from complete, and I found myself skint. I still remember going to the bank and asking what would happen if I overdrew the next day to pay for rent. They didn’t care much.
@ -19,13 +18,15 @@ Eventually I burned out and quit maintaining Homebrew. I handed the reins to the
A few times a year someone would ask me if I would make a brew2. I always said no. What would be the point? brew is good, and I’m not going to reinvent the wheel. A few times a year someone would ask me if I would make a brew2. I always said no. What would be the point? brew is good, and I’m not going to reinvent the wheel.
### A Wild Timothy Appears ## A Wild Timothy Appears
I met Timothy in Chicago in late 2013. We clicked and worked together on many projects. We were both passionate about what people can build in open environments that encourage and incentivize contribution. Eventually I moved away but the friendship stuck. Timothy caught the wave of crypto while I moved on to become a top mobile developer. I met Timothy in Chicago in late 2013. We clicked and worked together on many projects. We were both passionate about what people can build in open environments that encourage and incentivize contribution. Eventually I moved away but the friendship stuck. Timothy caught the wave of crypto while I moved on to become a top mobile developer.
Every year or so he’d hit me up and talk to me about what was new in crypto, trying to get me to bite. I always declined. I admired the bitcoin white paper but I felt crypto was just money and, for me, money was the least interesting consequence of work. Every year or so he’d hit me up and talk to me about what was new in crypto, trying to get me to bite. I always declined. I admired the bitcoin white paper but I felt crypto was just money and, for me, money was the least interesting consequence of work.
### A Change of Heart ## A Change of Heart
My partner and I were trying for a baby last year and in September, she showed me the positive test. We were overjoyed, but the next morning I woke up in a cold sweat. How was I going to provide for my family? Open source was not paying the bills.
My partner and I were trying for a baby last year and in September, she showed me the positive test. We were overjoyed, but the next morning I woke up in a cold sweat. How was I going to provide for my family? _Open source was not paying the bills._
I went back over all my old ideas looking for a startup idea I could turn into a business. Eventually I came back to my ream of notes about “brew2”. Despite previously snubbing the idea of making another, I am an obsessive note taker and had been recording my thoughts as they came to me for years. I went back over all my old ideas looking for a startup idea I could turn into a business. Eventually I came back to my ream of notes about “brew2”. Despite previously snubbing the idea of making another, I am an obsessive note taker and had been recording my thoughts as they came to me for years.
@ -35,49 +36,54 @@ Timothy phoned me to catch up and once more pointed me to what he was now callin
I sniffed around the top of the rabbit hole. I sniffed around the top of the rabbit hole.
While learning about web3 I bought and sold a few NFTs. The process was mostly uninteresting except for when I sold one and saw the automated, unavoidable 10% royalty enforced by a digital contract (with no need for a legal structure) that compensated the original creator for secondary sales. I felt the sting of inspiration. While learning about web3 I bought and sold a few NFTs. The process was mostly uninteresting except for when I sold one and saw the automated, unavoidable 10% royalty enforced by a digital contract (with no need for a legal structure) that compensated the original creator for secondary sales_._ I felt the sting of inspiration.
web3 enables indirect compensation. _web3 enables indirect compensation._
I wondered if we could apply this concept to helping distribute value to open source. I wondered if we could apply this concept to helping distribute value to open source.
I dove down the rabbit hole. I dove down the rabbit hole.
### The Nebraska Problem ## The Nebraska Problem
It’s a well-known problem. Developers make fundamental improvements to the nature of the Internet. Their contributions are grabbed by the community with both hands and inserted into the tower: It’s a well-known problem. Developers make fundamental improvements to the nature of the Internet. Their contributions are grabbed by the community with both hands and inserted into the tower:
![](https://miro.medium.com/v2/resize:fit:770/0*TTqemZPUKyxK8mgo)
[https://xkcd.com/2347/](https://xkcd.com/2347/)
https://xkcd.com/2347/
Once a block is placed it’s rarely removed. The maintainers become charitable volunteers. Once a block is placed it’s rarely removed. The maintainers become charitable volunteers.
Solutions like sponsorship and bounties exist. Both unfortunately reward only the top of the tower, the visible packages. Beneath them lie tens of thousands of vital packages that most people don’t even know exist. Solutions like sponsorship and bounties exist. Both unfortunately reward only the top of the tower, the visible packages. Beneath them lie tens of thousands of vital packages that most people don’t even know exist.
Recently Log4J hit the news with a zero day that impacted most of the Internet. They fixed the bug and endured abuse while pointing out that they receive no funding from the myriad of unicorns that use them. They probably still don’t. Most of these hyper profitable corporations didn’t even know that Log4J was a vital brick in their tower of open source built by people they don’t even know and have never even paid. Recently Log4J [hit the news](https://www.cnet.com/news/privacy/log4j-software-bug-cisa-issues-emergency-directive-to-federal-agencies/) with a zero day that impacted most of the Internet. They fixed the bug and endured abuse while pointing out that they receive no funding from the myriad of unicorns that use them. They probably still don’t. Most of these hyper profitable corporations didn’t even know that Log4J was a vital brick in their tower of open source built by people they don’t even know and have never even paid.
CoreJS is another famous example, downloaded 30 million times a week. Their README is depressingly laced with genuine need for funding to help them keep every Node.js application that exists afloat. CoreJS is another famous example, downloaded 30 million times a week. Their [README](https://github.com/zloirock/core-js/blob/master/README.md) is depressingly laced with _genuine need_ for funding to help them keep every Node.js application that exists afloat.
### Let’s Brew a Fresh Pot ## Let’s Brew a Fresh Pot
Tools like Homebrew lie beneath all development tools, assisting developers to actually get development done. We know the graph of all open source, which means we’re uniquely placed to innovate in interesting and exciting ways. This is exactly what tea will do. We’re taking our knowledge of how to make development more efficient and throwing innovations nobody has ever really considered before. Package managers haven’t been sexy. Until now.
Tools like Homebrew lie beneath all development tools, assisting developers to actually get development done. We know the graph of all open source, which means we’re uniquely placed to innovate in interesting and exciting ways. This is exactly what [tea](https://tea.xyz/) will do. We’re taking our knowledge of how to make development more efficient and throwing innovations nobody has ever really considered before. Package managers haven’t been sexy. Until now.
Most importantly, we’re moving the package registry on-chain (relax, we’ll use a low-energy proof of stake chain). This has numerous benefits due to the inherent benefits of blockchain technology: Most importantly, we’re moving the package registry on-chain (relax, we’ll use a low-energy proof of stake chain). This has numerous benefits due to the inherent benefits of blockchain technology:
* Packages will be immutable (no more left-pad incidents) - Packages will be immutable (no more [left-pad incidents](https://www.theregister.com/2016/03/23/npm_left_pad_chaos/))
* Packages will always be available (we’ll use decentralized storage) - Packages will always be available (we’ll use decentralized storage)
* Releases will be signed by the maintainers themselves (rather than a middleman you are told you can trust) - Releases will be signed by the maintainers themselves (rather than a middleman you are told you can trust)
* Tools can be built to fundamentally verify the integrity of your app’s open source constitution - Tools can be built to fundamentally verify the integrity of your app’s open source constitution
* Token can flow through the graph - Token can flow through the graph
Token flowing is where things get really interesting, but first let’s set things straight: we’re not changing the nature of open source. It’s still free. web3 has enabled novel new ways to distribute value, and with our system people who care about the health of the open source ecosystem buy some token and stake it. Periodically, we reward this staking because it is securing our token network. We give a portion of these rewards to the staker and a portion to packages of their choice along with all the dependencies of those packages. Token flowing is where things get _really_ interesting, but first let’s set things straight: we’re not changing the nature of open source. It’s still free. web3 has enabled novel new ways to distribute value, and with our system people who care about the health of the open source ecosystem buy some token and stake it. Periodically, we reward this staking because it is securing our token network. We give a portion of these rewards to the staker and a portion to packages of their choice _along with all the dependencies of those packages_.
Note that no portion goes to us. We’re not like the other app stores. Note that no portion goes to _us_. We’re not like the other app stores.
## What is tea?
### What is tea?
Founded by Max Howell, the creator of Homebrew and Timothy Lewis, famous web3 evangelist: Founded by Max Howell, the creator of Homebrew and Timothy Lewis, famous web3 evangelist:
tea is a delightful product suite that you will adore. **tea** is a delightful product suite that you will adore.
tea is the home to a DAO that will ensure the open source maintainers that keep the Internet running are rewarded as they deserve. **tea** is the home to a DAO that will ensure the open source maintainers that keep the Internet running are rewarded as they deserve.
tea is our revolution against a failing system. **tea** is our revolution against a failing system.
Stay in touch: https://tea.xyz & https://linktr.ee/teaxyz Stay in touch: [https://tea.xyz](https://tea.xyz/) & [https://linktr.ee/teaxyz](https://linktr.ee/teaxyz)