Well said. I'm not arguing its utility--I've used it and I think it's a great app. But I do think of it as "fractal sketching" rather than spatial research.
1,633 karma · joined August 3, 2007
Guess my point here is that Muse is not an attempt to translate paper into the computer, other than some superficial elements like using a stylus to ink. IMO software and computers can go so much further than that.
In the meantime, one enterprising customer has already written a Muse bundle (zip/json) to HTML converter: https://twitter.com/jimmyhmiller/status/1449761294589087752
> In an ideal world, a software subscription will let you pay just when you’re getting value from a product, and stop paying when you aren't getting value any more. In practice, many subscriptions feel bad because they are hard to cancel; or worse yet, they require you to pay forever to keep accessing the content you’ve created in the app.
> Muse is different. We never want to hold your data hostage. You should pay for it only when you’re getting active use out of the app.
> Once you cancel your membership (after a month, a year, or ten years) all your cards will still be fully accessible. You can still navigate around, doodle on your boards and PDFs, move cards, and export a subset or all of it as a Muse bundle or PDF. You can search by label, change labels, edit text.
> The only thing you can’t do? Add new content.
> You never need to worry that your data is locked up. We want you to pay for the value you’re getting from the tool, not for the data storage.
I have an iPad I use for testing that cost me $250 on Amazon back in 2019! But watch out for Pencil versions, not all are compatible with every iPad model.
There are still some apps that do this, Things is a good example. But that creates all kinds of other challenges when a big part of the product is a service (like ours) if you want to support all versions of the client in perpetuity.
Free trials are another solution, but time also ends up being a bit arbitrary.
In the end, storage is a good metric that doesn't require complex feature gates. We borrowed this model from Notion: they had 1000 blocks free in their original product, but once they started getting those sweet enterprise dollars they were able to give more away for free to individuals. Dropbox and GitHub are two other examples.
Our service still does a lot of work proportionate to data size, so in that sense it's still SaaS and has the same cost dynamics at work. But in the end the real cost of software is engineering salaries, not infrastructure, so that whole discussion is sort of a red herring.
Obviously it remains a problem to solve that our industry can't find a pricing model that is both (1) healthy and sustainable for the business and (2) people find amenable.
In the Apple ecosystem that's tough because they roll out breaking API changes in the OS every few years. So if you buy a new computer, upgrade your OS, or otherwise try to keep up with a changing world your software will stop working.
My thoughts on software longevity and why it's a problem for our industry: https://museapp.com/podcast/49-software-longevity/
GoodNotes is great, hope they can make the one-off payment model sustainable. But the reality is that cost needs to match with value over time, and the industry is moving to subscriptions because that's a sustainable model for productivity software.
And yeah nested boards[1] and a zooming UI (ala Jef Raskin[2]) is one of the big elements that makes Muse different.
We tried implementing Apple sign-in but found the experience pretty weak, both for the end user and for us on the business side.
In the future would like to implement some kind of disconnected mode to remove this friction. But email is needed for the sync aspect, which is one of the biggest selling points (and wow moments) of the product.
It does export a Muse bundle which is a ZIP archive containing a JSON with the position of the cards and, more usefully, flat files for all the media. PNG, TXT, PDF, SVG for the ink, etc. I regularly drop backups of this into Dropbox or iCloud.
Version control would be tricky because one of the big features is realtime streaming sync. Could be an interesting research problem to find a way to combine Figma-style realtime documents with something that can be checked into Git.
Muse is built local-first; all your data is kept locally on device, with the sync server merely a second-tier backup. If we go out of business, you keep all the data on your local device.
That said, apps in the App Store tend to stop working if they don't get regular maintenance[1]. This problem and the one you name is a big one for our industry to improve on IMO. Mark and I talked about that in depth in our podcast on software longevity[2].
[1]: https://9to5mac.com/2022/04/24/apple-now-removing-outdated-a...
> Unfortunately we're not going to be in a position to open source or license the syncing software in the short term. As you noted there's inevitably overhead with that and we can't take that on right now as such a small team. Also I still feel like we need to prove out our approach more in production, starting with rolling out the sync capabilities to the full Muse user base and scaling that userbase up a bit. I'm open to considering open-sourcing in the future but that'd probably be a ways off.
> I was speaking with another developer at an early-stage company recently and he mentioned that he'd been having good results with Automerge, which has come a long ways in the last ~2 years since we looked at it deeply. Importantly the Automerge[2] team is now tackling the storage and network problems in earnest, making it a more viable production option. So you might look into that project if you haven't yet.
But sorry to hear this means you get left out. We do have a free version that's extremely capable and a lot of people use for years, mainly by archiving older boards to a backup location.
Quoting from https://museapp.com/memos/2021-06-pricing/ :
> You might be used to software from growth-at-all-costs startups: free at the start (funded by venture capital) but eventually your attention in monetized with ads, your personal data is monetized by selling to third parties, or the personal product takes a back seat to the “enterprise” product.
> Muse is following a different path: personal software, made for you and your unique tastes and needs, and funded by direct payment from you and other members. Because our funding comes from you, the customer, rather than investors with their sights on mass-market adoption, our incentives are better aligned with yours.
> By paying for Muse, you help us stay niche, opinionated, and focused on your needs over the long term.
I think it's worth thinking about where the products and services we consume in our daily lives come from and how the incentive models work. And that definitely includes software.
Some other apps in the "spatial canvas" realm I can recommend are Kinopio, Clover, and FigJam. But most are paid with some sort of freemium setup.
On paying for software, here's some rationale: https://adamwiggins.com/making-computers-better/pay
Hey all, I'm one of the five folks who built this. We just released a 2.0 version[1] which includes local-first sync.
A little backstory: I’m one of the authors of the 2019 essay Local-first software[2]. (Past HN discussions[3][4].) The thesis is to reclaim some of the ownership over our data that we’ve lost in the transition from filesystems to cloud/SaaS. So I’m excited to bring CRDT technology “out of the lab” and into a commercial product as a chance to prove the value of local-first in real-world usage.
As a developer and computing enthusiast, I care about abstract ideas like data ownership. But for most users I think the benefits of local-first will surface in how it feels to use the software day-to-day. One example is ability to work offline or in unstable network conditions: any changes between devices will be automatically merged when you reconnect to the network, no matter how long you’ve been disconnected.
Another area is performance. The sync backend was written by my colleague Mark McGranaghan who has written extensively about software performance[5][6] and why we think the cloud will never be fast enough to make truly responsive software.
A few technical details:
– Client-side CRDT written in Swift, streaming sync server written in Go
– Sync server is generic, doesn’t have any knowledge of the Muse app domain (cards, boards, ink, etc). Just shuffles data between devices
– Transactional, blob, and ephemeral data are all managed by this one single state system. For example ephemeral data (someone wiggling a card around) for example, isn’t even transmitted if there are no other clients listening in realtime.
More in this Metamuse podcast episode.[7]
We draw heavily on research from people like Martin Kleppmann, Peter van Hardenberg[8], and many others. A huge thank you to this wonderful research community.
Even if you have no interest in the Muse concept of a digital thinking workspace, I’d encourage you to try the free version just to see how local-first sync feels in practice. My opinion is that is fundamentally different from web/cloud software is well as from classic file-based software—and an improvement on both. Would love to hear what you think.
[1]: https://museapp.com/memos/2022-05-dive-into-big-ideas-with-m...
[2]: https://www.inkandswitch.com/local-first/
[3]: https://news.ycombinator.com/item?id=19804478
[4]: https://news.ycombinator.com/item?id=21581444
[5]: https://www.inkandswitch.com/slow-software/
[6]: https://news.ycombinator.com/item?id=18506170
A bit of nuance on the "terrible experience of trying to run Ruby apps" bit. I'd argue that the setup process for Ruby/Rails in 2006 was not all that much worse than other web stacks at the time e.g. Java/WAR or Perl/cgi-bin. (Although PHP+Apache+mod_php deserves a nod for being notably smoother than most others.)
What inspired us to start Heroku was that once we switched from building apps in other languages and frameworks, development time was reduced by a factor of 2 or 3; but deployment time stayed the same. That is, before Rails we'd spent maybe three months developing the first version of the client's project, and then 4-6 weeks on deployment. (This was usually buying and installing a rackmount server into their office or colocation facility, but sometimes also waiting for a managed hosting service to do the same for us. For small projects we could use Slicehost but those were infrequent because our clients usually needed a powerful database server.)
Once we were developing with Rails, we found v1 could be done in a month or even less. It felt incongruent to spend a month on developing the app (the differentiated part of our work) and then longer than that getting it deployed (the undifferentiated part).
There's many other inspirations that were part of the story (end-user programming / citizen developer, which led to the web IDE you talked about) but this was the "deployment pain" part of it. It sticks in my mind because we frequently had to answer the question from prospective investors: "Is Rails really that hard to install?" And we'd say, no, the game has changed--development is so much faster and joyful now, that by comparison our existing ways of deploying feel slow, error-prone, and boring.
Muse is an iPad (and soon, Mac) app for deep thinking.
This job is to help build the local-first syncing infrastructure using Go, CRDTs, websockets, and Postgres. Knowledge of Swift/iOS development a bonus.
Yes, boards and cards are a key abstraction. Boards are just a type of card that can contain other boards--think of boards like folders/directories on a filesystem.