A week or two ago, I started a post on the ontology of software systems. I started looking at backend systems, but I planned to write up a client app post after since that's where I spend most of my time. Our discussions today about adoption for wiki, and its purpose made me think about what I was going to say in that post. Ten or eleven years ago there were a flurry of blog posts about emacs and vim. I think the impetus was the development of docker, and peoples' need to use a non-graphical editor with a docker shell. The keywords of extensibility (emacs) and composability (vim) rose to the surface. Two design ideas which the ensuing decade of software development have focused on erasing. Most tech professionals spend their time working on products, and by definition a product is something that people give you money for. People only really give money for things that solve a problem, and in the world of tech that usually means a computer thing that removes something that is tedious, time-consuming, or dangerous from what humans need to do. The marketing book Crossing the Chasm that we talked about is about marketing products, and its advice is to focus on _one_ problem, and devote all resources to solving that problem and then informing the havers of that problem of its solution. The question though is what are you making when you aren't trying to get people to give you money? Life is too full of false dichotomies to say something either is a product or it's not, but in n-dimensional space, the set of things that are not products is probably larger than the set of things that are. Which brings us back to extensibility and composability (fed wiki has several design ideas that are quite awesome, but I'm going to just focus on these two). The plugin pattern in wiki makes it both extensible, and composable, and these two properties makes it so that someone like me can use it to do pretty much anything people might want to do (this isn't an invitation Marc!). Building a web-based UI/UX that is extensible and composable is very hard™, which is why I'm glad Ward, Paul, Eric, and Nick built it so I didn't have to. Trying to think of what extensibility and composability mean I thought of the metaphor of an artist who has just three colored pens: red, blue, and yellow. If they then want to draw trees, they can purchase a green pen (extensibility), or combine blue and yellow (composability). Over time the artist collects more and more pens. The composability seems to wane. And then some weirdo with a wizard's hat talking about aliens and spaceships shows up with a bag full a markers, and now there are two artists, and they can make so much more stuff so long as they're willing to share the pens and markers. And though this is a metaphor, I don't think it's that far off from what, ontologically I believe the federated wiki, and Planet Nine to be. They are media--not social, not news, but artistic media like clay, and oils. They are the substances through which the artists of code work. So then I got to thinking...how do you get people to notice some new artistic medium? You make something awesome from the medium. And those somethings are what Marc wants to do, and Thompson, and Robert, and David, and Viki, and probably a whole lot more I've missed. I think what Brian M. has run up on is that while the medium is good for many things, it is not good for all things. Specifically that wiki's UX isn't the best for long-form writing. As the most prolific multi-media creator on the call (I think), it's not all that surprising that a general-purpose UX is behind more specialized tools. Fwiw, I also find wiki's UX a little rough for my stream of conscious writing style. Since the extensibility and composability exists, it's well within the realm of the possible to transform wiki into something more conducive to the use case. Not adopting those changes into wiki's core minimizes the cognitive load on existing wiki users, and I think is one of the things that keeps it from becoming a "platform." The onus then shifts to the user as to whether the work involved in creating the plugin is worth it to get the rest of wiki's features, or whether it makes more sense to use existing tools. There is no _correct_ answer to this, and that's the beauty of the art. And now I've prattled on too long again. So I'll wrap for now.