This is a foreign position to me. I open sourced my code not to make money but because I saw that others can benefit from it. I never made money from open source. If I did my mental model would be that these are charitable donations, not an income stream I can rely on.
I've "made money" from my relatively limited open source contributions primarily by being moved straight past coding stages when interviewing a few times. That's enough payoff for me. Other than that it's mostly a "why not?"
There are some - very limited - pieces of code I keep private relating to my consulting business, but I've seen more downside in keeping code private over the years than not. E.g. lots of code I've written that are locked up in companies that no longer use it that I wish I could still use.
The proportion of code I have that would create a moat that makes it worth holding the code back is miniscule.
> Some OSS will keep going - wealthy devs doing it for fun or education. That's not a system, that's charity.
I'm all for non-monetary motives, but the reality is that most people have to work for a living, leaving quite limited time/energy for volunteering. The scale of OSS that we have today would not (perhaps sadly) be possible without OSS development paying the bills.
Wealthy devs context is also foreign to me. I started to open source my code way before I was making any money. I just did it because I saw no reason for it to be closed sourced. It would only benefit me. But in the open it can benefit many people without taking anything away from me.
> Some OSS will keep going - wealthy devs doing it for fun or education. That's not a system, that's charity.
I read that. That statement is technically true but I don't like that they put a negative connotation around it. Apologies if they didn't intend it like that.
But I'll say that there is nothing wrong with charity. Some devs will do open source with hope to monetize. Some will do it for charity. Both are equally valid motivations.
I worked for 13 years on open source software and I definitely did it to make money. Nothing wrong with trying to make money on open source software, it's just a different business model than proprietary. More consulting oriented than product oriented.
Nothing wrong with making money on your work, and if you work on open source, even better I think. I have been spending hours a week for decades working on FOSS, never got paid, so yes, that was (and still is) intentional charity.
That's cool, and I'm happy for you that you are in a position that allows you to get income from other sources, so that you can write OS code in your spare time.
Not everyone can or wants to go this way, though, and we got a number of fantastic tools and libraries thanks to people who tried and succeeded in making money from open source. Some folks live off donations, some are paid by their employers to write OS, and some added extra features that allowed them to both offer their tools for free and to monetize them at the same time. It's sad that the last path starts to disappear, at least for some tools. In the end it probably will result in fewer OS libraries, because some number of authors will have to either find another income stream, or abandon their projects.
It would not, actually, maximize my usefulness to others. They way you do it is making your work maximally available and exapndable so others can build on it. The end result is greater than the sum of its parts. So... open source.
My point is that I don't see a reason why someone making money off my work that I donate should bother me. But again, this is MY stance, clearly it's not an universal outlook. What I wanted to challenge was underlying assumption that someone making money off your code and not giving you any back is a problem or that is _should_ be a problem. It might bother some, but it's not an universal assumption.
To extend your all you can eat analogy. It’s similar to how all you can eat restaurants allow you to eat all you can within the bounds of the restaurant, but you aren’t allowed to bring the food out with you.
Another analogy is that it’s a takeout but anthropic is insisting you only eat at home with the plastic utensils they’ve provided rather than the nice metal utensils you have at home.
Another analogy is that it’s a restaurant that offers delivery and they’re insisting you use their own in house delivery service instead of placing a pickup order and asking your friendly neighbor to pick it up for you on their way back from the office.
The all you can eat buffet analogy makes way more sense to me, because it speaks to the aspect of it where the customer can take a lot of something without restriction. That's the critical thing with the Anthropic subscription, and the takeout analogy or delivery service don't contain any element of it.
It's not really a fair analogy. Restaurants don't want you taking food away because they want to limit the amount you eat to a single meal, knowing that you'll stop when you get full. If you take food out you can eat more by waiting until the next meal when you're hungry again.
You don't "get full" and "get hungry again" by switching UIs. You can consume the same amount whether you switch or you don't switch.
> You don't "get full" and "get hungry again" by switching UIs. You can consume the same amount whether you switch or you don't switch.
This is actually a compelling argument for Claude Code getting the discount but not extending it to other cases. Claude Code, being subsidized by the company, is incentivized to minimize token usage. Third parties that piggyback on the same flat rate subscription, are not. i.e. Claude code wants you to eat less.
Of course, I don’t believe at all that this is why Anthropic has blocked this use case. But it is a reasonable argument.
Claude Code does a lot of work in optimizing context usage, how much output is included by tools and how that's done, and when to compact. This very well may make the cost of providing the subscription lower to Anthropic when Claude Code is used. It's well within the realm of possibility if not likelihood that other tools don't have the same incentive to optimize the buffet usage.
Not sure where that goes in the analogies here but maybe something about smaller plates.
The UI absolutely could influence the backend usage.
Think about a web browser that respects cache lifetimes vs one that downloads everything everytime. As an ISP I'd be more likely to offer you unlimited bandwidth if I knew you were using a caching browser.
Likewise Claude code can optimize how it uses tokens and potentially provide the same benefit with less usage.
Not really. At a buffet restaurant, if you could take the food out with you, you'd takeaway more food than you can eat at one sitting. OpenCode users and Claud Code™ CLI users use tokens at approximately the same rate.
This is more like an all-you-can-eat restaurant requiring you to eat with their flimsy plastic forks, forbidding you to bring your own utensils.
Claude Code does a lot regarding optimizing context usage, tool output, sub-agent interactions, context compaction, and stuff like that. I don't imagine OpenCode has the same financial incentive to decrease the token cost Anthropic takes on under the subscriptions.
If anyone is excited about, and has experience with this kind of stuff, please DM. I have a role open for setting up these kinds of tools and workflows.
I’d be lying if I said I never ripped photos from listings on a certain popular online auction platform when selling stuff online (before the ubiquity of digital cameras and smartphones)
I was in a similar situation a few years back. I wasn’t only focusing on CRUD, but it was a large part of my work too. Mostly working on web-based SaaS projects.
I started learning infra via AWS CDK (TypeScript). And by osmosis learned a lot about cloud native application architecture. Which changed my way of creating web apps entirely and rejuvenated my love for software. Still going strong 5 years later. Now with much stronger focus on platform engineering and not working on features much.
Looks like I'm in that path you've already passed. From January I have to learn CDK because my current job requires me to do. Also planning on to obtain those AWS Cloud Certificates.
I loved the original promise of Dagger and it’s still 90% great.
But one flaw (IMO) that it can’t export artifacts and import into other steps without breaking the cache.
Eg if you provide monorepo as input, and then on some step narrow your build to one specific dir, then even when files change outside of that dir then caching still is invalidated.
Which makes it extremely verbose and maintenance nightmare to keep multiple narrow inputs and keep all those paths up to date.
You can filter input directories before they are loaded, to avoid this. There's no reason you shouldn't be able to get precise cache invalidation in a large monorepo. If you want, DM me on the Dagger Discord and I'll help you out!
reply