It's interesting, a @pidotdev extension can be built with different attitudes: (a) To be installed as a package: You want other people to adopt, like @nicopreme /pi-web-access (a) is like "I want others to adopt it, so I will try to make it elegant, simple and make it have a good architecture" People install these by npm install ... or pi install ... (or rather, telling their agent to do it) (b) To be vendored: You build for yourself. It is too idiosyncratic of you, and you know others will likely not adopt. But you still put it out there, because it's easier to share them when you mention it to a friend. People (b) is like "This is mine, I don't care what others think about it. If they want to use it, they do whatever they want with it" People install these by pointing their agent and telling to copy it to their own extensions repo And then there is the maintenance dimension: - If an extension poses as (a), - but has not been maintained since 3 months, - and is the sort of package that has to be continuously maintained by its nature (not one-off), then you deem it unmaintained, and still vendor it in... Interestingly, most pi extensions I observe out in the wild appear to be of category (b), because creating (b) is easier than creating (a) This is nothing new, and I am kind of late to the game. Moreover, pi is not the first software of this kind, emacs for example did it decades before But code wasn't cheap then. So people still tried to coordinate effort When you don't have to write any code to extend---a lisp dialect, typescript or otherwise, when extending is 1 prompt away, when you can pump out 10 extensions in an evening, then we enter a new dimension of malleability Before, in the pre-AI era, most users of emacs were not producers of extensions but consumers of them, save for a few prolific authors After, now, every user can be a producer! This is significant! And a lot more messy! And a lot more fun! "A love letter to pi" indeed!