As someone who wants to write open source but needs to be able to capture some financial value from doing that to be able to make it sustainable, what model do you prefer?
My current thoughts lean towards a fully functional open source product with a HashiCorp style BSL and commercial licensing for teams above a size threshold.
I think the open core model is fine, and the most financially sustainable. Just be up front about it from day 1. I don't think the honor system for licensing will get you the results you're wanting.
it depends strongly on why you want to write open source. if you like the idea of putting source code out into the world for other people to use and benefit from then go ahead and use whatever mix of open source and proprietary code you like, just be up front that that's what you are doing.
if you want to promise open source software simply to attract the mindshare and users who habitually ignore anything that isn't open source, trying to capture financial value may well be infeasible unless some rare confluence of stars lines up for you. the key is in the word "capture" - capturing the value implies making sure it goes to you rather than to someone else, and that means imposing restrictions that will simply piss those same users off.
I can't imagine that works very well for relatively small, simple, functional or intuitive projects though. Incentives wise, is it possible to sell reverse support: extracting payment for all the times the product works so well that support isn't needed?
It will be, eventually, unless a maintainer is able to maintain during the day. It doesn't matter what the source of free time is however: retired, rich, runs a company from their open source project, paid by somebody else, etc., but full time job + open source maintainer = dead project, eventually.
I don't think open issues is a fair way to judge project liveness. TypeScript also has hundreds of open issues going back years with no traction. Is TypeScript dead?
Yes, issues that are years old show me the commitment level. Not a knock against HTMX but a clear sign of priorities. Carson is free to meme all day and talk about other projects. It's very clear where he stands and that's fine
this year I created and released fixi.js, created the montana mini computer (https://mtmc.cs.montana.edu), published an paper on hypermedia via the ACM, got hyperscript to 1.0, released 3 versions of htmx, reworked all the classes that I teach at montana state and am planning on releasing a java-based take on rails that I'm building for my web programming class
i am also the president of the local youth baseball program and helped get BigSkyDevCon over the hump
i think you'd be surprised at how little time i actually spend on twitter
as always, my issue is never with how you spend your time. you are a giver of gifts and I wish more people that relied on HTMX stepped up to make it better. in no way should anything be expected of you. How you spend your time is obviously your call. MIT is MIT
It was a rhetorical question; the answer is no, old issues with no updates don't necessarily indicate anything about the health of the project. Different people have different project management styles. You use your style for your project, and Carson uses his for htmx. There's no one correct way to manage an issue backlog.
source is MIT, do what you want. The team found certain plugins to be anti-patterns and support burdens. You can find the old plugins in the repo source, feel free to fork from there!
I had been tracking Datastar for months, waiting for the 1.0.0 release.
But my enthusiasm for Datastar has now evaporated. I've been bitten by the open-source-but-not-really bait and switch too many times before.