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.
Conversation
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.
1
1
8
(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 can appreciate an argument that VCs may be less willing to fund a project whose code is open source, though I have a hard time imagining this being a/the deciding factor.
1
Venture funding requires that projects be able to produce (lots of) revenue. It is of course possible to produce revenue with OSS, but it's not the norm, and it requires thoughtful strategy. If you have such a strategy, great!
1
2
You also need to explain why your future closed-source competitor, which can leverage your work for free, will not simply eat you. There are approaches for this, too, but again, you'd better have an explicit strategy.
Are you making the argument that in an ideal world competitors have open cores with lossless import/export of user data via an open standard, eliminating friction in users iterating across products?
1
There is hyperbole in my comment; I believe people have every right to make a living. And I see why someone ripping one off is worse than not sharing. At the same time, locking progress to obtain a monopoly is also harmful. Especially hypocritical for projects which rely on FLOSS
You and MN said that the hard work of TFT goes in developing the interface β they're not "hard-tech". Less true that closed has an asymmetric advantage over open here.
How quickly is Athens catching up to Roam? Hard to say who ships faster long term β private team vs ecosystem
1
1
It doesn't matter who ships faster; what matters is who produces transformative insight. It also matters whether Athens could have existed prior to a for-profit Roam having existed first. Path dependence rules everything around youβ¦
2
1
5
Show replies