> people run kaneo on setups i never imagined:
> behind corporate proxies
> ...
> in kubernetes with custom networking
It's OP's project so they're welcome to support whoever they want but I definitely would not offer free support to customers who are obviously using the product commercially, especially in large enterprises.
It's FOSS, so they can use it for free if they want, but if they need custom support or features, they're a great user to tell, "Sure, I'm happy to help you with that if you purchase a $500/yr support contract." You'd be surprised how many customers like that don't care because they have a corporate card and that amount is too little to require approvals or much process.
In much of corporate America expenses under $100 give or take don’t even require documentation, so a $50/month support subscription is easily purchased.
Just need to find the person with the purchase card.
Firstly, you need to clearly define what is included, and even more so, what is not included. How many hours is $500? Who decides what us should bug? Can they get new features because they have support? How many installs does the support cover? And do on.
And if they start with things like "supplier agreements" etc, just walk away.
Yes, some companies have a threshold where managers can just "spend money". Some managers may even use that to support you. But taking any money changes the relationship you have with the user.
Right now, it's completely inside your control. Direction, Priorities, Scope, Pace, levels of effort etc. I'm a huge fan of getting paid, I write software for money, but make no mistake - taking money changes things.
- the second 'start' button overlaps the list items
- tapping that button darkens the whole page but doesn't display anything new
- even before I get to that stage, it's not clear what you're selling at each price point
Also, look at Gitea. People got paranoid and forked the project after the original author did exactly that.
I feel like it shouldn't be poor form to say on this site - a site that predominantly has been about building tech companies and revenue streams - to get over it and charge them.
500/hr more like.
The thing is if you agree, now you have to deliver. Be sure it’s something you want to do. If the project is open source because you don’t want to be a business, then be careful about letting a little quick cash change your mind.
You may not hear about them here or on your socials but it is possible you are not hearing everything. For example, do you have a presence on Mastodon or Lemmy (for example)?
There are a lot more channels too (you mentioned blogs).
Just like the roads you drive on seem to repair themselves sometimes (sort of), FOSS keeps on rocking along with minimal fuss, driven by a vast army of people who do what they can when they fancy it.
Look at the evidence: There is a vast, publicly accessible, free and open source, pool of software for you to download and play with. It gets larger daily but individual stories are immaterial - they might be described or not.
Look at the community: Along with all that software, often there will be a community. Arch, Gentoo and many others are legendary in providing resources to engage with.
>maintaining an open source, self-hosted project is:
> more work than building it > different fun than building it > more rewarding than you'd expect > harder than you'd expect > worth it
I'd say the title is not misleading: what they don't tell you is that is more rewarding than you'd expect and worth it. (Because yes, we mostly hear the "it's too much work and not worth it" story.)
> every feature you add is a feature you maintain forever.
This.
Keeping a framework/app/SDK “pure” is very important, in my experience.
Could you elaborate?
For example, if the framework provides text storage, adding text processing might be a mistake. Instead, make another framework that can be strung onto the text storage one.
It increases the granularity, and the usefulness of the modules. You could have multiple processing frameworks.
In addition, it allows you to refine discrete functionality domains (which can also be personnel assignment domains), and reduces the places for bugs to manifest. You can devote more tests to each framework.
> > every feature you add is a feature you maintain forever.
... until it becomes a security flaw.
Log4shell (IIRC) goes back to a feature to do an indirect lookup of a string over jndi in a beta version of the library. https://issues.apache.org/jira/browse/LOG4J2-313
On the other hand, software is never done. Even simple features, like headphones, regress these days. (I missed a meeting today because my phone decided to send audio notifications into the black void of the heat death of the universe because I didn't unlock my phone after plugging the headphones into the USB-C port of my iPhone -- the audio didn't come out of the speaker, nor out of the bluetooth of the car I was driving. No sound worked until after the phone was unlocked.)
At least with open source software I can fix the bugs I care about, but the fun goes away once you have to deal with other people to get things merged.
Is there a community of software Luddites I can go live with where we build simple technology that works and works well?
I don't know why but this amused me. Is this a feature one can get when buying a backhoe?
The third party transport links feeding my company's network have suffered 2 lengthy outages due to backhoes hitting buried conduit with fibre installed. Underground outages tend to be the longest outages since repairs can be quite involved. One of the outages was due to a large municipal construction project (LRT) where the buried conduit's location had been properly marked and yet was still hit anyways. They managed to pull on the fibre hard enough that repairs extended to a total of 4 manholes since the splices in the adjactent manholes were completely destroyed.
The other more recent underground hit occurred due to a process failure since the locates were issued before the carrier had installed their conduit and fibre, with the end result being that the other party doing construction had an all-clear from a locate completed before the fibre was in the ground. Ooops!
Dump truck hits are far more common around Ottawa. I'm aware of at least 8 in the past 5 years around where our network exists, which is only covering about 30 km. Thankfully when they have hit the poles we have fibre on, our fibre / strand was not damaged. The incumbent's fibre on the lowest strand on the pole was not so lucky. By my estimates there must be at least 1 near miss by a dump truck per day in the city. It's not surprising given the abuse dump trucks take.
If we had more fibre installed I'd love to have a proper ring to make these physical outages non-service impacting.
I channel that into my gardening during the appropriate seasons, but now that it's November, all that woodworking equipment in the garage is lookin' mighty appealing.
I'm sure there are other people out there frustrated with the software grind. My point is that change is always an option. There are interesting problems to solve in the world that exist outside of large software projects that most folks here have the required skill sets to tackle.
People like GP - and other hardware monkeys* - are the reason your computer works. Don't be rude.
* Said with much love <3
Take a look: https://press.stripe.com/working-in-public
If you do not spend a lot of time explaining things at length, people will link back to how much an asshole you are.
[1]: https://github.com/mickael-kerjean/filestash/issues/661#issu...
I'd at least make sure the cert is up to date.
I'll also point out the supportive comments in that thread; sure there's always gunna be some negativity, but there's also positive people. Focus on those.
Your response is where it should go when things get rude, but you don't want to start there.
Tons of open source exists as only source code and a license, nothing else. No docs, no issue tracker, nothing. People who need it use it, learn from it, remix it, whatever, but there need not be any engagement at all from the given repo's maintainer.
Instead of seeing it as "users of X platform", I think it's more useful to divide user groups into:
1. Completely non-technical users who, at worst, wouldn't know how to download anything, and at best only know how to install from an ".exe" file;
2. Middle-ground users who, at worst, are not willing to learn your preferred way of installation, or at best, are new to non-common installation methods;
3. Technically proficient users who, at worst, have arbitrary reasons for disliking your preferred way of installation, or at best, have legitimate reasons for disliking it;
4. Your ideal technically proficient users.
FOSS is often geared towards the fourth category, and for good reason. But if you want your tool to be adopted more widely, you have to learn more about those other user groups, and how to support them beyond documentation.
And here I'd say it's also fair to look for good reasons or funding for that extra support, because if it's not rewarding work, it doesn't have to stay free as in free beer (even if it's FOSS).
Honestly, this is a GitHub thing. You wouldn't get that issue on sourcehut, bitbucket or self hosted.
GitHub is the lowest common denominator for users.
It's what is taught in every school, bootcamp, youtube channel and corner of the internet. Anyone that had an idea on a random weekend to "learn to code" signed up for GitHub.
GitHub is less of a software forge and more like a Facebook for software.
> it's not better. it's different
> automation isn't lazy. it's sustainable
> it's not about gatekeeping. it's about making debugging possible
This is everywhere in the article.
I wouldn't be certain of it but I can definitely believe it.
I do hate that if you publish anything online these days, someone will accuse you of having used AI to write it.
We're at the point we need to coin a law for it. With tongue firmly in cheek, we could call it Turing's Law perhaps?
"Any person who publishes any text on the internet will be mistaken for a robot"
Noticing this too. Sabine said something a while ago in one of her videos that stuck with me [0]. about people expecting proof of suffering by next year. She was talk submitting an essay, but it might as well be anything ai could have done.
The author very thoroughly uses AI for everything. If you want further evidence just look at the commit messages for the site. They are almost all AI messages (compare against the author's commit messages for any project pre-2025).
Not saying that the article is bad because it's AI written (or at least heavily AI assisted). After all you enjoyed it! Regardless you're definitely looking at AI prose.
You understand that you can prompt an LLM to do things, right? This was screaming LLM-generated at me the whole way through. Adding "Use only lowercase" to the prompt does not change that.
> automation isn't lazy. it's sustainable: [bullet points]
A software developer did not write that. I would bet my entire net worth on that if the bet could be arbitrated objectively, at virtually any odds, because it would be free money.
> the people using kaneo aren't just users. they're: [bullet points]. they're not demanding. they're engaged. that's a *gift*.
This vomit-inducing sappy "gift" line, too.
> them kaneo
> cloud-hosted self-hosted (your data, your server)
> closed source open source (you can read every line)
> feature-rich minimal (does one thing well)
> subscription free (as in freedom and beer)
Wow, this looks just like the completely unnecessary comparison table you get any time someone prompts an LLM for a comparison! How much money would you feel comfortable betting "open source (you can read every line)" was written by a human software developer?
> someone stars your repo → feels good
An entire paragraph of these ultra-terse "x -> y", under a bold header "the emotional reality", also reeks of LLM output.
The evidence is overflowing, you simply aren't familiar enough to recognise it. Which sounds like a nice state of being, admittedly. Ignorance is bliss. I, personally, am absolutely sick of seeing this LLM spam on HN.
See e.g. my comment on the commit messages: https://news.ycombinator.com/item?id=46054935
Back in the day, with different technologies, most of it would have been "strange compilers and environments" that had to be supported.
Once the initial enthusiasm fades, it becomes difficult to maintain the project.
Sure, but you're also not obligated to do... well, anything. And people are also allowed to read documentation and code and put in the effort to build and install things themselves. What happened to the oldschool hacker spirit that rewarded learning and helping yourself? If you show up to a group of people and say "how do I make this work?" while showing zero evidence that you've actually done anything, you'll be politely told to fuck off. I promise it's okay to say no to people, especially people who haven't demonstrated that they've put in their own time to understand something.
But this is immaterial anyway. I don't know how to better explain that you don't owe your time to strangers on the internet, some portion of whom are probably not even human. Alternatively, you could get them to pay you, especially the organizations "behind corporate proxies". If they can afford a corporate proxy, they can certainly afford your time, as long as you value it appropriately.
So yeah. Stop working for free, and stop treating every last internet stranger as relevant.
> they're not demanding. they're engaged. that's a gift.
100%!
Open source maintenance is a difficult and sometimes thankless job. It requires a lot of communication, careful balancing of the project's vision and user requests; tolerance, patience, honesty, transparency, gratitude, humility, but also confidence, sternness, and above all else, dedication to improve the project for everyone, not just a select few. It seems that the author gets quite a few of these right.
A few notes from my own experience:
- Documentation is important, and they're right that it is never "done". That said, you also have to assume that it's written for a specific audience. If a baseline level of technical proficiency is needed for your project, then you shouldn't need to explain topics that bring people up to that level. Sometimes it's a better use of your time to address the occasional support question, than to add documentation that would be irrelevant for the majority of your users. Besides, if those support questions are visible to the community (e.g. they're on a discussion forum), then your answers there can serve as unofficial documentation for people who need it.
- Speaking of which, a discussion forum is crucial when building a community around an open source project, or any project, for that matter. It is another source of information for users, you can use it for announcements, etc. And once you have power users and people passionate about your project, the community itself can help out with support duties. Definitely make this as accessible as possible, make it public, and don't use a closed platform like Discord. A real-time chat platform could be useful, but an async searchable old-school forum is much better for discussion and support.
- Code contributions are a double-edged sword. On one side, it's incredible that some users are passionate about the project enough to invest their time and effort in improving it, and are willing to share their improvements with everyone else. But on the other, when their code is merged into the mainline project, it becomes an additional maintenance burden for core maintainers. Those contributors will hopefully be acknowledged for their work and everyone will appreciate it, but if there are issues with that part of the code, it will be the original maintainers' job to fix it and improve it, not the contributors'. The article mentions this already, but this is another reason to be extra vigilant and judicious about which code to accept, and which not. Most contributors will understand.
Kudos to the author, and best of luck with the project! It's certainly on my radar now.
BTW, looking at Kaneo's web site now, the "free forever" next to the Cloud link is not a good sign. Maintaining infrastructure is a financial burden. Nothing should be "free", and definitely not "forever". Please: add a commercial tier where people can pay you for the resources they consume. This is orthogonal to open source, and you should be compensated, not just for the infrastructure you maintain, but for your work. Everyone will understand this, as long as you keep it fair. In fact, it serves as assurance for any potential users that the project is in a healthy state, and that it will likely continue to be maintained.
I'd be happy to discuss this further and offer any guidance if I can. My contact info is in my profile.
If you've got "200 users" who rely on your tool so deeply that a migration glitch would seriously hurt their business, you're past the point where this is a casual side project. That's the point where you should at least have some path for people to pay you.
In my head there are three phases of an open-source project:
* Toy – "I scratched my own itch and threw it on GitHub."
* Product – "People actually rely on this. Now I owe them migrations, docs, and not breaking stuff."
* Infrastructure – "If this dies, someone's company explodes and I'm on the front page of Hacker News for the wrong reason."
This post is basically the story of moving from (1) to (2).
What I rarely see is a maintainer explicitly saying which phase they're in. Users see "kanban board, nice site, good docs" and instantly a user is going to map this to, "Jira replacement!" And the author is thrilled to be compared to a polished SaaS!
But then both will be "shocked" to realize that one person can't match an entire product team, support team, design team, etc.
I think there's a lack of honesty in a lot of open source projects. I'd love to see more READMEs say things like:
* "Hobby project. I reserve the right to disappear for a month."
* "No guarantees, no SLAs. Use at your own risk!" (or even more blunt, "If you use this in production, or for mission-critical business practices, you're a fucking moron.")
* "If you're a company depending on this, you should be sponsoring it."
Anyway, seen this countless times... And the real tension starts when the author's excitement about having users surpasses the amount of work generated by those users. As long as the author wants to avoid working on a team, with business rules, and other stakeholders... it'll never actually scale.
Worse, the difference between users and customers is that there's no barrier to entry. Users expectations drift upward -- whether they are paying or not. Users don't just want fixes -- they want roadmaps, guarantees, backwards compatibility, and custom migration help. The code is open-source, but the longer the project goes on, the more the expectations drift towards enterprise-grade.
Boundaries matter. "No, that's out of scope." "No, I won't support your forked schema." "No, I can't chase down your custom patches." Those aren't signs of being unhelpful -- they're what keep the project from collapsing under its own weight. And when you have to start saying things like this, you've past the point of needing a bigger team... which means you're also past the point of where you should have started charging money for your product.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Why should random people take on more responsibility for clearly 0 gain? If you want people to bear the cost for their externalities due to their shit software it has to be regulation.
I think something like this has to happen eventually, we can't keep using the same unix programs forever.
