Just the idea of it. Whether or not code was open source was totally irrelevant.
Had 10 minute conversation with him about the side project, with a few days, got up in middle of night and built {{[[TODO]]}} and {{[[DONE}}, which opened door for {{diagram}} and {{table}}.
Conversation
org-mode style TODOs in Roam is one of the most promising ideas I've struggled on:
1. todo.rip (which I attempted to connect to graph.global)
2. michaelkarpeles.com/essays/univers
3. Look at this mess: graph.global/?id=317
1
2
Fact that you could combine single markdown escape hatch for arbitrary display / interactivity - from
And STILL build off all the filter and backlinks power Roam already had...
That was the novel insight
Chet inspired {{todo}}
Rich hickey inspired {{[[TODO]]}}
1
6
So much of the hard work in design comes with figuring out details of the workflow and conceptual model - often only by months of working with users.
Open sourcing actual code for consumer tools is red herring, ignores other contributions to commons
Quote Tweet
Replying to @mekarpeles @RoamResearch and @AthensResearch
Open source was totally irrelevant - at least for me.
Never needed to read your code, definitely was never going to use.
What mattered was you pushed the conceptual frontier.
2
9
I agree there are many valuable forms of contribution:
One not needing a resource is not grounds for justifying it be closed. The world is built on resources I, in my privileged position, don't need and which others do.
All things equal; show work, share, & enable.
1
All things are never equal though mek.
2
4
I sympathize with Conor here—it's already so hard to get a tool like this off the ground; adding more constraints (i.e. on production flywheel) seems like asking for trouble. I love that we've found some models that work (e.g. open core); I'd love to see a playbook collection.
1
13
I struggle with this in my own work. It's obvious that if it's to succeed in the long term, Orbit wants to be an open standard with OSS implementations. But it's also obvious that there are enormous path dependencies; it's not at all clear when and how it's best to move to open.
1
9
My current inclination is to rapidly publish sources under restrictive "source available" licenses, then slowly move modules to open licenses from the bottom of the stack upwards as I better understand my path to sustainability. But who knows…
2
9
Would your answer change if we were talking about academic research? Where the work is material to the final product? Is there an inflection along the gradient where closing source is better for users? Because e.g. the org is more focused?
1
What matters is whether sufficient funding is available to produce the insights you care about. In some domains (often tools for thought because of insight-through-making), this requires funding a $$$-skills team for years. If an academic grant lets you do that, great—OSS away.
(of course the other thing that matters a lot here is that dollars are not fungible; grant dollars push you around differently from VC dollars / bootstrap dollars / Patreon dollars…)
2
4
I feel I'm trying to specifically understand the nature of funding (e.g. the ability for a group to execute on a product) and the quality of a codebase being open source.