> maintaining kaneo means helping people debug their setups. and honestly? it's taught me more than i expected.
> 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.
This is not as simple as it sounds. Just yesterday I had a call with the Delft university of technology in Netherland, they want me to add some features on the free version of my FOSS product [1] but they did not want to pay anything. Over the last month, I was in contact with a 800B publicly traded company for a 1.8k per year invoice, once we agreed on the general direction they kept adding expectations, first was to sign tons of paperwork with their security checklist, legal stuff which took a few days but when they start asking for things that would take potentially weeks more, I invite them to do extras on a contracting basis, since them I have never heard back and of course they never paid a dime. I have literally tons of stories like this from governments to F500. In my bubble the paid support plan mostly work with US entities.
Universities are a special case. They generally don’t spend money because of the red tape.
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.
In my experience, having MIT and UCI as customers, US universities are much easier to deal with small to no process for simple cheap things. On the other hand, I was contacted by a well known engineering school in France (ENSEEIHT), they wanted support but were laughing at the idea to spend 20$ per month for the privilege, left the impression they wanted to use my time for way under minimum wage, same yesterday with a deutch school who wanted help but not willing to spend a dime, and some other universities who have deployed my software in prod but did not upgrade in the last 5 years. Even in China, I stumbled upon a fork maintained by the university of Shangai, of course they never reached out in the first place to ask for any kind of support, just took the code and went their own way. This kind of behavior haven't happen with US universities which are more likely to reach out and pay for support
> I stumbled upon a fork maintained by the university of Shangai, of course they never reached out in the first place to ask for any kind of support, just took the code and went their own way.
It is very hard to find a person with that purchase card.
As a developer in corporate environment I won't get anywhere close to be able to influence anyone to buy a support, or a subscription for an open source or closed source product. This is my third corp, and it was true in all of them.
The most what I got is the approval to do some PRs for such projects during company time.
It's actually pretty simple. For the former case, you do nothing. Tell the university to find someone to make the improvement, or do it for fun. In the latter case, you should be charging 5-10x that, for starters... You send a Statement of Work, and only do what's in that, and only after they pay.
You're too cheap. Anyone that won't pay for a proper enterprise support contract you should tell to pound sand. You'll be surprised that when you start charging more people will actually take you more seriously and will be more inclined to sign up. It's counter intuitive from your side, but perception is reality. A 20k/yr enterprise support agreement is more believable to provide results than a 2k/yr deal.
Quite. I remember one of my first corporate customers who was very suspicious of $2K/week, because nobody could do that for that cheap they said. It was nothing extraordinary, just some integration work, tests etc for the project, they wanted it to work with their other suppliers' systems
I agree, it's not as simple as "$500 per year". In some cases it can be, but mostly it's not.
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.
But the company wants a proper invoice. And not every single developer is interested in founding a Limited and getting the tax office breathing down their neck every year.
Also, look at Gitea. People got paranoid and forked the project after the original author did exactly that.
> But the company wants a proper invoice. And not every single developer is interested in founding a Limited and getting the tax office breathing down their neck every year.
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.
Depending on the local laws, that's easier said than done. E.g. in Germany, a private entity (read: person) can't just bill a company. And you can't just write something that resembles an invoice either. Especially, you're not allowed to make it look like a business invoice by putting net sums on it.
A German business on the other side of the transaction rarely will pay anything if there's not a proper invoice (listing net sums and VAT separately) on file. And they usually also require the (business) tax ID of the other party.
To be fair, founding a business is a matter of filling in some form, paying a small fee, and a few days of time (depending on the workload of your local trade office). But still - if this is a one-off thing and you don't even know whether there will be more... I'm not sure I'd want to go through the hassle. Especially if it means having to hire an accountant with monthly costs, when I don't even know whether there will be more income.
In case it wasn't clear from my other comments up and down this comment chain, I don't really care about the specifics of Germany. If it's hard for you[1] to do it in Germany, then suck it up and figure it out.
More than enough has been written about how the ecosystem in various EU countries stifles entrepreneurship. It's not new information, but it's not a problem for the vast majority of people reading this site. This site is also focused on supporting entrepreneurship, we should be supporting the default approach of getting paid for your work.
Germany needs to change, not the stance of this site or the argument of charging for your work/time/etc.
Germany doesn't need to change, just Germans need to change talking lot of bullshit.
I registered a private SW development entity in Germany easily, without any costs. You just need to declare it as System SW, not Applications, or you'll have to pay Gewerbesteuer and Kammermitgliedschaft. Which is a lot and not needed at all. Your yearly taxes are trivial, no need for an accountant.
Especially a site that frequently champions, shall we say... more creative forms of running a company in its early stages (like how Spotify started out charging money for pirated music). If it's okay for OpenAI to launder copyright, it's okay for you to send a net-30 PDF to a Fortune 500 company.
Alternatively, people could just stop complaining about it.
Well the laws are like spider webs that only catch small bugs. It's "okay" for a Spotify or OpenAI because they can hire lawyers and expect to blitzscale. Harder to take those risks for a random solo developer who just wants to make things.
At least where I live you can hire an accountant from an accounting company for $n/hr so you can ask them
>"hey, can I do this?"
<"no, you'll need fields from forms X,Y and the price needs to be at least Z with them"
Same goes with a law-person. Then if you're lazy you'll just look at how much they cost you in some timeframe and add that to the price, and find that you've lowballed so hard you'll get laughed out of the bidding
You aren't wrong on either; Germany's tax law is insanely complex but also many people don't want to change the tax law as they can deduct a million and one things.
Since Hacker News also centers on entrepreneurship: I know quite some entrepreneurs in Germany who think this way about the bureacratic chicanery that companies have to handle, and already thought about whether hiring a hitman for these politicians would be a good idea. The hate for the political caste in Germany among many people is insane.
These laws may very well be terrible, but no need to mention on an internet forum you want to help (hire?) someone to mass murder people involved in making them. Jokes and sarcasm don't always land as intended.
As to a more constructive path: bureaucracy all over EU is definitely considered a big problem (for startups, and for many others) and there are a bunch of movements aimed at addressing them at all kinds of levels. For example look at the eu acc movement.
One should hire an accountant to handle the bureaucracy, and of course charge enough to make that viable. And you should stop airing your murderous dreams in public, that's disturbed no matter your feelings towards politicians.
Startup founders dislike any regulation that doesn't let do heinous stuff to earn some money, so I'm not really sympathetic with their plight honestly.
You should definitely charge enough to hire an accountant to handle the bureaucracy. This might be multiples of the payment for the technical bits but probably still cheaper than a hitman/woman.
Come on, stop with this slave mentality please. You can make invoices without funding any company and without the tax office getting in your hair. It's not illegal to charge for your services and never has been. You can declare that income just fine, or skip it. The tax office won't bother you.
This is entirely jurisdiction specific, so I can't say for certain, but in almost every country I've looked into it for, there is a set of paperwork that an individual can use to independently invoice for work, without the effort of setting up an incorporated company. You will definitely need to record the income you received, and declare it on the relevant tax forms.
There is often a scale variance too - in Australia, "hobby" income is treated differently from "business" income. [0]
In Germany, there is the concept of the "Freien Berufen" ("liberal professions"), in which you can freelance without a company. [1]
> ... the client also will demand...
The client may also demand these things of you.
They are certainly capable of dealing with sole traders, and will have some services provided by people who do not have those things. (Your boss does not check if the receipt you submit for the new bookshelf for the office comes from a registered company or a sole trader carpenter.)
Depending on the scale of the services you are providing, they may prefer to deal with a registered entity, but for small one-off things, that may not be necessary.
If you are regularly working with large businesses who are funding your work, it's worth looking into the most effective tax and legal structures for you. But if you just need to send the occasional invoice off to someone who wants something quick done, it's useful to know what your options are.
One final thought - even when dealing with organisations who prefer to deal with registered businesses, you have options. You can choose to be employed by a company which does that on your behalf. Either a business which you have a good relationship with, and is willing to enter into a casual employment contract with you and bill for your services, or a dedicated contractor management company. Either way, you give up a percentage of what you bill, but in exchange, they take the paperwork and liability overhead.
> There is often a scale variance too - in Australia, "hobby" income is treated differently from "business" income. [0]
I have an ABN and I am registered for GST for side hustles beyond the hobbyist income threshold. This costs me about 10 minutes of extra admin per year when I do my tax return.
All I need to do is give the tax office three figures: How much money I earned, how much GST I charged, and how much I paid (ie how much they need to give back to me.)
You don't seem to understand the power balance here. The client is in no position to demand anything, since the article author can just tell them to scram, and they can solve their own problems.
Working with corps is not a problem. Unless you have a slave mentality that is, and let them bully you and stomp all over you. If they have their wits with them, they will fully understand what negotiating position they are in, and not make unnecessary demands on the software creator.
I have a company in Estonia for cases like this. The amount of paperwork is nearly zero, the corps are happy they’re working with an actual company, and you can do things like holding money there (for business purchases) and paying no taxes in your home country (unless they have a CFC rule, notably US and Japan, in which case eh good luck).
It depends. Sibling thread has some horror stories about Germany, for example.
Estonia has been trying to get foreigners to open their businesses there for a while now: https://e-estonia.com/ But I don’t think that helps US residents too much (ask your tax advisor about CFC rules; I have only a vague understanding that it’s a PITA).
It also mostly doesn't help EU residents. If you live in another EU country, your tax office will treat your Estonian company as a local one since that's where the business takes place in truth.
Not sure about elsewhere but ot took me 15 minutes to setup my LTD in the UK and I paid a monthly fee for accountancy which was about £100 and another yearly fee of about £100 for them to do my tax return (as I am lazy and didn't want to do it).
Unless you are getting paid in cash or monero, HMRC will absolutely know if you are getting paid under the table.
The IRS will definitely bother you if they figure out you have unreported income. Will they find out? Maybe not if it’s a few hundred or even a few thousand dollars. More than $10K? Then it gets more likely. If a client sends you a 1099 then they’ll certainly know.
They’ll know because in the US and abroad the banks send the balances and transactions to the IRS. I get letters every year/6 months that I’m subject to additional withholding because they haven’t gotten any $$ but they show I have.
Reporting income from freelancing is no more difficult than reporting income from your day job. So we're left still mystified what mbirth was talking about.
If a company is unwilling to jump through its self-imposed barriers to paying for things it wants, then it obviously doesn't value those features/items. This is definitely a case of 'voting with [one's] dollars'.
Do you think GP is like, lying to you? Or maybe managers are just silly and are indeed willing to draw $500 for a pizza party but are unwilling to drop the same for a year of support for software they depend on. This is absolutely believable to me.
I mean you might have to negotiate a bit but yeah, a simple professional statement like “My rate for custom enhancements is $X/hr” is not going to ruffle any feathers. They might not bat an eye.
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.
I wouldnt worry about the license, unless you licenses yourself into a corner. MIT is great for this.
Secondly, yes. The biggest challenge I have seen is getting on "VENDOR LISTS". Vendor approval is a huge PITA. master agreements, proof of insurance, etc.
You don't have to deliver a result or continued service. You are paid per hour not per feature. If you can only offer an hour support you can only charge one hour. If you have too many clients you can decline new work until you have time. Per hour work is limited for total pay but clients expectations are limited by time.
This is actually nice and balanced, but the title is misleading. I feel like ALL I hear about maintaining an open source project is how hard it is and how people burn our. I almost never read a blogpost or comment declaring how rewarding it is. So, this was a nice (slightly) more balanced view.
There are a lot of happy open source projects rocking along ... happily.
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.)
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.
I see. I follow the same approach; with my interns I try to force them to define logical boundaries and think / design their software as libraries / components that compose together nicely.
This is why I like building outside plant. You put the fibre up on poles or pull through ducts, splice it, bring it into the building, hook it up to the equipment, make sure it's working and.... you're done. It works until something breaks, usually for a very clear reason (power outage, drunk driver, rodent, vine, lawnmower man, fibre seeking backhoe, dump truck, direct lightning strike, thermal cycling of a marginal splice, failure to seal a gasket properly resulting in water intrusion that stresses fibres when the water turns into ice, ...), but those become quite rare if you're done your job properly.
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?
You're talking about being a tradesman on a forum dedicated to software and maybe making a company out of said software? If people liked the idea of being outside in the weather, doing manual labor as you've described, there is a very large chance they would not be on this forum.
It's very often that people here lament the fact that they're not outside being outside, in the weather, doing manual labor. How may of us don't dream, at least once a week, of walking out into the woods, or taking up woodworking instead, or wondering how long it would take to retrain as a plumber?
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.
Yeah people have thoughts like this but then you hear a story about lying on your back in a muddy 3’ crawl space cutting into a blocked sewer line to install a cleanout and hoping you can roll away when the liquid starts pouring out.
Then your desk job writing code starts to sound a little better.
Most of my career has been in software development. Running an ISP / carrier is more fun as there's more of a variety from day to day (as is the case for anything entrepreneurial) while still involving technical skills. There is a need for with some programming from time to time, but it is usually tied to solving a particular business need.
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.
For anyone interested in this (and certainly for OP) I highly highly recommend the book Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal. When I was raising my profile on my open source farming robot, this book really helped me understand the types of projects one might want to foster, how to think about users, and generally gave me very helpful guidance on becoming an open source maintainer!
In the words of Lizzo: "Let 'em say what they gonna say. They gonna feel how they gonna feel." Back in the day, we called this "feeding the trolls", and the advice hasn't changed: ignore them. You don't owe every single person online any part of your short, precious life. Issues have delete buttons (and there are other hosted SCMs besides GitHub). I encourage liberal use thereof.
Simply ignore users like that. If someone actually important brings up that instance as you 'being an asshole', then explain your reasoning then. If that doesn't calm them down, they're probably not someone worth working with.
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.
Ya OP is shadow boxing. There is absolutely no need for any of these things.
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.
Seriously. If I throw something up somewhere, you get a tarball, a README, and no way to get in touch with me. If the code helps you, fantastic! If it doesn't, then I hope you at least got something out of the experience. But "as-is" means what it says on the tin. I'm not sure why people are so hellbent on treating every message from every stranger as important.
Because open source is not just about the code and the license. It is first and foremost about a community of people who want to make software better for everyone, not just for themselves or a select few. The code and license are ancillary to this goal.
I won't get into this discussion again. I'll just say that if you think otherwise, whatever good you think you're putting out into the world, is not much better than keeping the software proprietary.
You have this entirely backwards. Open source is, definitionally, the code and a license. It is "first and foremost" those things. The community of people cannot exist without the code and the license. The code and the license can and often does exist without dedicated communities.
Everything else in open source is a cultural projection entirely ancillary to the code and the license.
> I'll just say that if you think otherwise, whatever good you think you're putting out into the world, is not much better than keeping the software proprietary.
I have never seen someone so entirely miss the point of open source. This is not a house party, this is not a community support network. There are genuine disagreements about open source philosophy, if it should be more focused on user freedoms or developer convenience, but they are all incompatible with the idea that open-source licensed code in and of itself "is not much better than keeping the software proprietary".
Stallman did not invent the GPL because he wanted an issue tracker and complete documentation from HP. He invented the GPL because he needed to fix his printer drivers.
A ton of very important open source code was thrust into the world, created immense value, but was never further supported or developed by its original developers. Off the top of my head: git, Doom, Bitcoin, and basically everything Fabrice Bellard has ever done.
Code existed before FOSS. Code that people collaborated on existed before FOSS. Code given away for free existed before FOSS. FOSS code, by itself, is not anything special.
Licences also existed before FOSS, but open sources licences enabling the kind of freedoms that they allow did not exist. And as it happens, a license is not a technical artefact but a social contract. Stallman is activist, not simply a neutral combination of a technician and a lawyer.
The social contract and political vision are consequently not ancillary, but core to FOSS. Code is the medium, but the license is the innovation. Without that social contract, 'open' code is just abandonware.
The community doesn't need to be a 'house party,' but the license guarantees the right for a community to form when the original author walks away.
> The community doesn't need to be a 'house party,' but the license guarantees the right for a community to form when the original author walks away.
Which is why the license is the only thing that matters. Without the license you don't have the community. It will happen with some code, it won't happen to other code. Without the license, or without the code, it never happens.
The only thing you need to do as an open source software developer is release your code under an open source license. You don't need to respond to or even maintain an issue tracker, you don't need to accept MRs into your upstream, you don't need to care about anyone else using your code.
Open source places no other obligations on a developer other than the license. To say otherwise is to fundamentally misunderstand what open source is.
Maybe you are lasering in on a term we use to describe software, but they are talking more broadly about maintaining open source (lower case, btw) collaborative software.
Though I have to be very charitable to grant your point.
Even your examples support their point of "people who want to make software better for everyone, not just for themselves or a select few". Stallman just cared about code, like fixing his printer, and not a whole social movement?
> Stallman just cared about code, like fixing his printer, and not a whole social movement?
Stallman created a social movement that just cared about code, yes. He needed the social movement to create an environment in which he could fix his printer.
The social movement was about the license and the code, not about providing support for, documentation of, or continuing development of any particular code.
By creating an environment where code is open, you allow for communities to organically form around code and maintain it. Without the environment, without the code and the license, the communities cannot form.
> The community of people cannot exist without the code and the license.
That is obviously false. Communities form around any common interest. They also exist around proprietary software, where no code is shared.
When code is freely available, it is the community of people who make the project successful—not the code, and certainly not a piece of legalese text.
> The code and the license can and often does exist without dedicated communities.
Technically true, but such projects languish in obscurity. They're driven by the will of a small group of people, often the original lone author, and once that diminishes, they are abandoned and forgotten. The vast majority of software which can technically be described as "open source" is mostly inconsequential to computing or anyone's lives. It once scratched the itch of a single person, and now sits unread on some storage device.
Thus, communities are what make software successful. Not just free software, but software in general. We write software for people, and we publish its source code to help others. We do so because software is better when shared and improved by a community of passionate users, rather than written by one or a few people who wanted it to exist.
It's wild that you would bring up Stallman as an example, since everything he's done goes completely against your point. That printer story served as a good example to illustrate to others why free software is necessary—not just for him, or for the team and company he worked with at the time, but for the world at large. He didn't need to invent a social movement and philosophy to fix his printer issues. He probably could've hacked around it and found a solution that worked for their specific case, and called it a day. And yet he didn't. He believed that software could be built and shared in a different way. In a way that would benefit everyone, and not just the people who wrote it. He believed in the power of sharing knowledge freely, of collaborating, and building communities of like-minded people. The source code is important, and the license less so, but it is this philosophy that brings the most value to the world.
> A ton of very important open source code was thrust into the world, created immense value, but was never further supported or developed by its original developers. Off the top of my head: git, Doom, Bitcoin, and basically everything Fabrice Bellard has ever done.
Whether the original developers supported it or not is irrelevant. All of the examples you mentioned are projects supported by someone, and have communities of passionate people around them. That is the point. Individuals may come and go. The author is no more important than any talented and passionate member of the community. But someone cares enough to continue maintaining the software, and to nurture the community of users around it, without which none of these projects would be remotely as successful as they are today.
It is fundamentally true. You cannot have a Pokemon community without Pokemon, a knitting community with yarn, or a software community without software.
> Technically true
You should have stopped here. It is true. Period, full stop. Everything else is fluff.
> The vast majority of software which can technically be described as "open source" is mostly inconsequential to computing or anyone's lives.
This is because the open source software movement was so overwhelming in its success it became the norm.
> He didn't need to invent a social movement and philosophy to fix his printer issue.
Yes he did. The philosophy is about the freedom to fix your printer. It is not about engaging others to fix your printer, or obliging maintainers to fix your printer.
Those things are follow ons to the core philosophy. Once you have the freedom to fix your printer, you can form communities of people also interested in fixing printers. The freedom comes first.
> Whether the original developers supported it or not is irrelevant.
It's literally the only thing we're talking about. Open source enables others to come along and support software abandoned by or simply never championed by its original creator. Without open source you do not have those later "someones".
The first point about documentation really has to do with the question: whom are you willing to support?
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).
I've seen this mentioned a few times lately. Not that I disagree, but why would that be? Is it just Github's poplarity? Is it the ease with which you can sign on and start yelling at FOSS maintainers? Something else?
Popularity is part of it. It's the "default" for software.
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.
You need to stop wanting to help others as a developer, in that context it's a toxic mindest that will slowly kill your projects, time, personality, passion, and self. You made the project for you and chose to share it to others, that's all you need to feel responsible for. If others need to adapt it to fit their use cases, it's on them to do so.
It's interesting to see that the "the diversity of environments" section only talks about work for supporting different installation / deployment methods.
Back in the day, with different technologies, most of it would have been "strange compilers and environments" that had to be supported.
As an Apache PMC member, I often ask myself: Can I maintain focus and dedication to open-source projects for an extended period? My answer is: extremely difficult.
Once the initial enthusiasm fades, it becomes difficult to maintain the project.
Particularly frustratingly because it's so unnecessary in this case. It's not even that much text, just write it yourself. It would probably take less time.
I very much doubt it. Never seen an AI consistently miss capitalising the first letter of each sentence for example. The style is efficient in a way that just screams software dev to me. AI's are needlessly verbose. This guy is bordering on needlessly concise. Rather like the style actually.
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"
>I do hate that if you publish anything online these days, someone will accuse you of having used AI to write it.
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.
This is classic LLM verbosity. It's not concise. The sentences are short, but the passages are verbose.
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.
> Never seen an AI consistently miss capitalising the first letter of each sentence for example.
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.
There's a bunch of typical ChatGPT catch phrases in the post "Here's the thing", "but honestly". You can't know for sure but it really does look like OP wrote it then stuck it in ChatGPT but told it to not fix the capitalisation for some reason.
The evidence is in all of the text. It is dripping with it. The cadence, the abuse of headers, the abuse of bullet points, "not X, but Y" multiple places it doesn't make sense.
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.
Your comment made me register for a HN account for the first time ever in my life (I have been lurking since 2009/2010).
I did not even think to consider that the OP's submission was AI and I felt dirty, violated and even saddened that a developer home page; something I long assumed in my 35 year old mind to be sacred, technical and a place where you could read honest thoughts about programming was now polluted with genAI.
I always treated them like open source docs or linux contribs pages or deeply technical or academic sites where you could 100% definitely trust that the developer would not waste your time or tell lies.
I think this episode has finally made me decide to go video only, f2f meetings or just zero-out reading from my life.
Just thought you should know what your comment did for me. The whole post now reads cheap, like they didn't value or care about what they said or how readers would feel.
No, it is a list of blatantly obvious LLM patterns that stick out like a sore thumb if you've been exposed to any amount of LLM writing. Bad human writing manifests in different ways than "looks exactly like what ChatGPT has output 1000 times before".
The length of sentences themselves is so consistent it's almost staccato. Plus, the "it's not x, it's y" troupe. That doesn't mean it's AI - some people certainly can write like that. But so many short sentences can feel odd to read.
The author very thoroughly uses AI in their projects. That's not necessarily a bad thing! But this article's text is probably AI generated (if at least from an outline). Both based on the very telltale AI style and the author's use of AI elsewhere.
Yeah running a miniture incarnation of data centre Jira (i.e. the old one where people self install and uograde) as a single dev. That will be a lot of work!
>but here's the thing: people come from different backgrounds. what's obvious to me after building the thing isn't obvious to someone installing it for the first time.
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.
These are good takeaways from someone who seems to actually care about the users of their project, which is refreshing to see. I've gotten into discussions on this forum with people who think and do otherwise. (Case in point[1].)
> 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.
I get that he just wants to build something alone in his basement -- without product managers, sales guys, or customers with SLAs breathing down his neck. But he's doing an enormous amount of work specifically to avoid charging money for something that's already providing real value. That's the part that feels odd to me.
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.
This is hilarious considering the way Google treats their customers, business partners and FOSS maintainers of software they use.
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.
> maintaining kaneo means helping people debug their setups. and honestly? it's taught me more than i expected.
> 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.
This is not as simple as it sounds. Just yesterday I had a call with the Delft university of technology in Netherland, they want me to add some features on the free version of my FOSS product [1] but they did not want to pay anything. Over the last month, I was in contact with a 800B publicly traded company for a 1.8k per year invoice, once we agreed on the general direction they kept adding expectations, first was to sign tons of paperwork with their security checklist, legal stuff which took a few days but when they start asking for things that would take potentially weeks more, I invite them to do extras on a contracting basis, since them I have never heard back and of course they never paid a dime. I have literally tons of stories like this from governments to F500. In my bubble the paid support plan mostly work with US entities.
[1]: https://github.com/mickael-kerjean/filestash
Universities are a special case. They generally don’t spend money because of the red tape.
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.
In my experience, having MIT and UCI as customers, US universities are much easier to deal with small to no process for simple cheap things. On the other hand, I was contacted by a well known engineering school in France (ENSEEIHT), they wanted support but were laughing at the idea to spend 20$ per month for the privilege, left the impression they wanted to use my time for way under minimum wage, same yesterday with a deutch school who wanted help but not willing to spend a dime, and some other universities who have deployed my software in prod but did not upgrade in the last 5 years. Even in China, I stumbled upon a fork maintained by the university of Shangai, of course they never reached out in the first place to ask for any kind of support, just took the code and went their own way. This kind of behavior haven't happen with US universities which are more likely to reach out and pay for support
> I stumbled upon a fork maintained by the university of Shangai, of course they never reached out in the first place to ask for any kind of support, just took the code and went their own way.
I think this one is 100% ok for open source, no?
this is fine indeed if you didn't ask for my time
"Pull requests welcome"
It is very hard to find a person with that purchase card.
As a developer in corporate environment I won't get anywhere close to be able to influence anyone to buy a support, or a subscription for an open source or closed source product. This is my third corp, and it was true in all of them.
The most what I got is the approval to do some PRs for such projects during company time.
It's actually pretty simple. For the former case, you do nothing. Tell the university to find someone to make the improvement, or do it for fun. In the latter case, you should be charging 5-10x that, for starters... You send a Statement of Work, and only do what's in that, and only after they pay.
You're too cheap. Anyone that won't pay for a proper enterprise support contract you should tell to pound sand. You'll be surprised that when you start charging more people will actually take you more seriously and will be more inclined to sign up. It's counter intuitive from your side, but perception is reality. A 20k/yr enterprise support agreement is more believable to provide results than a 2k/yr deal.
Quite. I remember one of my first corporate customers who was very suspicious of $2K/week, because nobody could do that for that cheap they said. It was nothing extraordinary, just some integration work, tests etc for the project, they wanted it to work with their other suppliers' systems
Really: add a zero to your price. These companies burn millions on procurement bureaucracy. Make them pay for your misery.
Two zeros actually
I agree, it's not as simple as "$500 per year". In some cases it can be, but mostly it's not.
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.
fwiw the pricing page is buggy on mobile:
- 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
But the company wants a proper invoice. And not every single developer is interested in founding a Limited and getting the tax office breathing down their neck every year.
Also, look at Gitea. People got paranoid and forked the project after the original author did exactly that.
> But the company wants a proper invoice. And not every single developer is interested in founding a Limited and getting the tax office breathing down their neck every year.
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.
Depending on the local laws, that's easier said than done. E.g. in Germany, a private entity (read: person) can't just bill a company. And you can't just write something that resembles an invoice either. Especially, you're not allowed to make it look like a business invoice by putting net sums on it.
A German business on the other side of the transaction rarely will pay anything if there's not a proper invoice (listing net sums and VAT separately) on file. And they usually also require the (business) tax ID of the other party.
To be fair, founding a business is a matter of filling in some form, paying a small fee, and a few days of time (depending on the workload of your local trade office). But still - if this is a one-off thing and you don't even know whether there will be more... I'm not sure I'd want to go through the hassle. Especially if it means having to hire an accountant with monthly costs, when I don't even know whether there will be more income.
In case it wasn't clear from my other comments up and down this comment chain, I don't really care about the specifics of Germany. If it's hard for you[1] to do it in Germany, then suck it up and figure it out.
More than enough has been written about how the ecosystem in various EU countries stifles entrepreneurship. It's not new information, but it's not a problem for the vast majority of people reading this site. This site is also focused on supporting entrepreneurship, we should be supporting the default approach of getting paid for your work.
Germany needs to change, not the stance of this site or the argument of charging for your work/time/etc.
[1] (the proverbial you)
Germany doesn't need to change, just Germans need to change talking lot of bullshit.
I registered a private SW development entity in Germany easily, without any costs. You just need to declare it as System SW, not Applications, or you'll have to pay Gewerbesteuer and Kammermitgliedschaft. Which is a lot and not needed at all. Your yearly taxes are trivial, no need for an accountant.
Especially a site that frequently champions, shall we say... more creative forms of running a company in its early stages (like how Spotify started out charging money for pirated music). If it's okay for OpenAI to launder copyright, it's okay for you to send a net-30 PDF to a Fortune 500 company.
Alternatively, people could just stop complaining about it.
Well the laws are like spider webs that only catch small bugs. It's "okay" for a Spotify or OpenAI because they can hire lawyers and expect to blitzscale. Harder to take those risks for a random solo developer who just wants to make things.
[flagged]
At least where I live you can hire an accountant from an accounting company for $n/hr so you can ask them
>"hey, can I do this?"
<"no, you'll need fields from forms X,Y and the price needs to be at least Z with them"
Same goes with a law-person. Then if you're lazy you'll just look at how much they cost you in some timeframe and add that to the price, and find that you've lowballed so hard you'll get laughed out of the bidding
Well not every country is Germany. Dunno what to tell you there.
The second half of that also sounds unhinged.
Developers want to develop, not play around with taxes.
Most sensible choice in my country is hiring an accountant to do those taxes. It is quite affordable (you pay monthly fee)
Developers live in the real world like the rest of us, and they shouldn't give away free labor on things that they deserve to get paid for.
Sure, hire an accountant. Either way, charge the companies and stop doing free work. This isn't rocket science.
You aren't wrong on either; Germany's tax law is insanely complex but also many people don't want to change the tax law as they can deduct a million and one things.
Including companies! I love my deductions (not in germany though)
> The second half of that also sounds unhinged.
Since Hacker News also centers on entrepreneurship: I know quite some entrepreneurs in Germany who think this way about the bureacratic chicanery that companies have to handle, and already thought about whether hiring a hitman for these politicians would be a good idea. The hate for the political caste in Germany among many people is insane.
These laws may very well be terrible, but no need to mention on an internet forum you want to help (hire?) someone to mass murder people involved in making them. Jokes and sarcasm don't always land as intended.
As to a more constructive path: bureaucracy all over EU is definitely considered a big problem (for startups, and for many others) and there are a bunch of movements aimed at addressing them at all kinds of levels. For example look at the eu acc movement.
One should hire an accountant to handle the bureaucracy, and of course charge enough to make that viable. And you should stop airing your murderous dreams in public, that's disturbed no matter your feelings towards politicians.
This is very entertaining. "Sir, this is a Christian website".
"My god, a slight hyperbole! Let me run over to my jewelry box and get some pearls to clutch!"
Startup founders dislike any regulation that doesn't let do heinous stuff to earn some money, so I'm not really sympathetic with their plight honestly.
OpenCollective Europe
You receive the money as contractor wages
You should definitely charge enough to hire an accountant to handle the bureaucracy. This might be multiples of the payment for the technical bits but probably still cheaper than a hitman/woman.
Come on, stop with this slave mentality please. You can make invoices without funding any company and without the tax office getting in your hair. It's not illegal to charge for your services and never has been. You can declare that income just fine, or skip it. The tax office won't bother you.
This isn’t true. The tax office will bother you, the client also will demand you have an actual company with liability insurance and more.
There is a tremendous amount of legal and paperwork once you start accepting money and working with corps. It’s a nightmare.
> The tax office will bother you...
This is entirely jurisdiction specific, so I can't say for certain, but in almost every country I've looked into it for, there is a set of paperwork that an individual can use to independently invoice for work, without the effort of setting up an incorporated company. You will definitely need to record the income you received, and declare it on the relevant tax forms.
There is often a scale variance too - in Australia, "hobby" income is treated differently from "business" income. [0]
In Germany, there is the concept of the "Freien Berufen" ("liberal professions"), in which you can freelance without a company. [1]
> ... the client also will demand...
The client may also demand these things of you.
They are certainly capable of dealing with sole traders, and will have some services provided by people who do not have those things. (Your boss does not check if the receipt you submit for the new bookshelf for the office comes from a registered company or a sole trader carpenter.)
Depending on the scale of the services you are providing, they may prefer to deal with a registered entity, but for small one-off things, that may not be necessary.
If you are regularly working with large businesses who are funding your work, it's worth looking into the most effective tax and legal structures for you. But if you just need to send the occasional invoice off to someone who wants something quick done, it's useful to know what your options are.
One final thought - even when dealing with organisations who prefer to deal with registered businesses, you have options. You can choose to be employed by a company which does that on your behalf. Either a business which you have a good relationship with, and is willing to enter into a casual employment contract with you and bill for your services, or a dedicated contractor management company. Either way, you give up a percentage of what you bill, but in exchange, they take the paperwork and liability overhead.
[0] https://www.ato.gov.au/forms-and-instructions/trust-tax-retu...
[1] https://handbookgermany.de/en/self-employment
> There is often a scale variance too - in Australia, "hobby" income is treated differently from "business" income. [0]
I have an ABN and I am registered for GST for side hustles beyond the hobbyist income threshold. This costs me about 10 minutes of extra admin per year when I do my tax return.
All I need to do is give the tax office three figures: How much money I earned, how much GST I charged, and how much I paid (ie how much they need to give back to me.)
You don't seem to understand the power balance here. The client is in no position to demand anything, since the article author can just tell them to scram, and they can solve their own problems.
Working with corps is not a problem. Unless you have a slave mentality that is, and let them bully you and stomp all over you. If they have their wits with them, they will fully understand what negotiating position they are in, and not make unnecessary demands on the software creator.
> This isn’t true. The tax office will bother you, the client also will demand you have an actual company with liability insurance and more.
If the commercial terms of the engagement don’t work for you, then walk away. It’s really as simple as that.
I have a company in Estonia for cases like this. The amount of paperwork is nearly zero, the corps are happy they’re working with an actual company, and you can do things like holding money there (for business purchases) and paying no taxes in your home country (unless they have a CFC rule, notably US and Japan, in which case eh good luck).
It is easier in EU than in US.
It depends. Sibling thread has some horror stories about Germany, for example.
Estonia has been trying to get foreigners to open their businesses there for a while now: https://e-estonia.com/ But I don’t think that helps US residents too much (ask your tax advisor about CFC rules; I have only a vague understanding that it’s a PITA).
It also mostly doesn't help EU residents. If you live in another EU country, your tax office will treat your Estonian company as a local one since that's where the business takes place in truth.
What exactly did the "bothering" consist of?
Not sure about elsewhere but ot took me 15 minutes to setup my LTD in the UK and I paid a monthly fee for accountancy which was about £100 and another yearly fee of about £100 for them to do my tax return (as I am lazy and didn't want to do it).
Unless you are getting paid in cash or monero, HMRC will absolutely know if you are getting paid under the table.
The IRS will definitely bother you if they figure out you have unreported income. Will they find out? Maybe not if it’s a few hundred or even a few thousand dollars. More than $10K? Then it gets more likely. If a client sends you a 1099 then they’ll certainly know.
They’ll know because in the US and abroad the banks send the balances and transactions to the IRS. I get letters every year/6 months that I’m subject to additional withholding because they haven’t gotten any $$ but they show I have.
AFAIK only transactions over $10k are reported, maybe different between personal and business accounts?
Reporting to tax authorities by banks/financial institutions was bumped down to any receiving of an amount in excess of $600 during the Biden admin.
Ah yes, I had forgotten about that. That's for "business" transactions, IIRC. I wonder how they distinguish....
Reporting income from freelancing is no more difficult than reporting income from your day job. So we're left still mystified what mbirth was talking about.
Considering he is doing it for free, it won't be more than a few thousand dollars. And he can report it and pay tax on it if he pleases.
I wish. In my company that is an instant no. The amount of legal contracting bull we have to go through for that would quite literally take 9 months.
If a company is unwilling to jump through its self-imposed barriers to paying for things it wants, then it obviously doesn't value those features/items. This is definitely a case of 'voting with [one's] dollars'.
I'm almost certain there is a way to get the company to pay for pizzas for a staff meeting which doesn't involve any legal contracting bull.
Do you think GP is like, lying to you? Or maybe managers are just silly and are indeed willing to draw $500 for a pizza party but are unwilling to drop the same for a year of support for software they depend on. This is absolutely believable to me.
> if you purchase a $500/yr support contract
500/hr more like.
I mean you might have to negotiate a bit but yeah, a simple professional statement like “My rate for custom enhancements is $X/hr” is not going to ruffle any feathers. They might not bat an eye.
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.
I wouldnt worry about the license, unless you licenses yourself into a corner. MIT is great for this.
Secondly, yes. The biggest challenge I have seen is getting on "VENDOR LISTS". Vendor approval is a huge PITA. master agreements, proof of insurance, etc.
You don't have to deliver a result or continued service. You are paid per hour not per feature. If you can only offer an hour support you can only charge one hour. If you have too many clients you can decline new work until you have time. Per hour work is limited for total pay but clients expectations are limited by time.
> Be sure it’s something you want to do.
Or charge enough that it becomes something you want to do :)
or you could do what tsx does? charge money to fix issues as an option https://github.com/privatenumber/tsx/issues/758 issues are fixed on priority basis for people willing to pay
This is actually nice and balanced, but the title is misleading. I feel like ALL I hear about maintaining an open source project is how hard it is and how people burn our. I almost never read a blogpost or comment declaring how rewarding it is. So, this was a nice (slightly) more balanced view.
There are a lot of happy open source projects rocking along ... happily.
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.
>the honest truth
>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.)
If all you hear is the bad things, the title is quite accurate
I liked the humble, “lessons learned” tone of the post.
> every feature you add is a feature you maintain forever.
This.
Keeping a framework/app/SDK “pure” is very important, in my experience.
> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
> Keeping a framework/app/SDK “pure” is very important, in my experience.
Could you elaborate?
I’m a fan of “singleness of purpose.”
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.
I see. I follow the same approach; with my interns I try to force them to define logical boundaries and think / design their software as libraries / components that compose together nicely.
> I liked the humble, “lessons learned” tone of the post.
> > 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
This is why I like building outside plant. You put the fibre up on poles or pull through ducts, splice it, bring it into the building, hook it up to the equipment, make sure it's working and.... you're done. It works until something breaks, usually for a very clear reason (power outage, drunk driver, rodent, vine, lawnmower man, fibre seeking backhoe, dump truck, direct lightning strike, thermal cycling of a marginal splice, failure to seal a gasket properly resulting in water intrusion that stresses fibres when the water turns into ice, ...), but those become quite rare if you're done your job properly.
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?
> fibre seeking backhoe
I don't know why but this amused me. Is this a feature one can get when buying a backhoe?
You're talking about being a tradesman on a forum dedicated to software and maybe making a company out of said software? If people liked the idea of being outside in the weather, doing manual labor as you've described, there is a very large chance they would not be on this forum.
It's very often that people here lament the fact that they're not outside being outside, in the weather, doing manual labor. How may of us don't dream, at least once a week, of walking out into the woods, or taking up woodworking instead, or wondering how long it would take to retrain as a plumber?
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.
> how long it would take to retrain as a plumber
Yeah people have thoughts like this but then you hear a story about lying on your back in a muddy 3’ crawl space cutting into a blocked sewer line to install a cleanout and hoping you can roll away when the liquid starts pouring out.
Then your desk job writing code starts to sound a little better.
Well hey, that's why I'm still commenting here. I've seen what the plumbers who come to my house have to do.
Most of my career has been in software development. Running an ISP / carrier is more fun as there's more of a variety from day to day (as is the case for anything entrepreneurial) while still involving technical skills. There is a need for with some programming from time to time, but it is usually tied to solving a particular business need.
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.
As we all know, the only real job is writing React web apps.
There is a shocking variety of users on HN. Don't make the mistake of thinking we're all software developers sitting in front of a computer all day.
People like GP - and other hardware monkeys* - are the reason your computer works. Don't be rude.
* Said with much love <3
For anyone interested in this (and certainly for OP) I highly highly recommend the book Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal. When I was raising my profile on my open source farming robot, this book really helped me understand the types of projects one might want to foster, how to think about users, and generally gave me very helpful guidance on becoming an open source maintainer!
Take a look: https://press.stripe.com/working-in-public
"Uncurled" by Daniel Stenberg, maintainer of curl, is a great resource for FOSS maintainers as well:
https://un.curl.dev/
I don’t understand. It’s your project, you do what you want and nothing more.
Yesterday I received this message from a random github user: "Seriously. No SSO at all in free version? This is poor. Very very greedy and poor" [1]
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...
In the words of Lizzo: "Let 'em say what they gonna say. They gonna feel how they gonna feel." Back in the day, we called this "feeding the trolls", and the advice hasn't changed: ignore them. You don't owe every single person online any part of your short, precious life. Issues have delete buttons (and there are other hosted SCMs besides GitHub). I encourage liberal use thereof.
The expired certificate on your own website (linked on your gh profile) doesn't fill me with confidence to hire you as a consultant though.
I'd at least make sure the cert is up to date.
Simply ignore users like that. If someone actually important brings up that instance as you 'being an asshole', then explain your reasoning then. If that doesn't calm them down, they're probably not someone worth working with.
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.
Close. Report as spam.
You've got the comment after you've explained at length
I would pull my hair out.
Cool project, gave it a star and bookmarked it.
So what? Fuck 'em. It's your project and it's open source. If they want the feature so bad they can add it themselves.
Ew gross
LOL all that user does is open issues for free support?
People who give away things like this tend to be good people. As such when someone comes asking for help or new things they are inclined to help.
Your response is where it should go when things get rude, but you don't want to start there.
I have projects online. You can use them, or not. Sometimes people file issues that I think are good and fix them.
Ya OP is shadow boxing. There is absolutely no need for any of these things.
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.
Seriously. If I throw something up somewhere, you get a tarball, a README, and no way to get in touch with me. If the code helps you, fantastic! If it doesn't, then I hope you at least got something out of the experience. But "as-is" means what it says on the tin. I'm not sure why people are so hellbent on treating every message from every stranger as important.
/sigh
Because open source is not just about the code and the license. It is first and foremost about a community of people who want to make software better for everyone, not just for themselves or a select few. The code and license are ancillary to this goal.
I won't get into this discussion again. I'll just say that if you think otherwise, whatever good you think you're putting out into the world, is not much better than keeping the software proprietary.
You have this entirely backwards. Open source is, definitionally, the code and a license. It is "first and foremost" those things. The community of people cannot exist without the code and the license. The code and the license can and often does exist without dedicated communities.
Everything else in open source is a cultural projection entirely ancillary to the code and the license.
> I'll just say that if you think otherwise, whatever good you think you're putting out into the world, is not much better than keeping the software proprietary.
I have never seen someone so entirely miss the point of open source. This is not a house party, this is not a community support network. There are genuine disagreements about open source philosophy, if it should be more focused on user freedoms or developer convenience, but they are all incompatible with the idea that open-source licensed code in and of itself "is not much better than keeping the software proprietary".
Stallman did not invent the GPL because he wanted an issue tracker and complete documentation from HP. He invented the GPL because he needed to fix his printer drivers.
A ton of very important open source code was thrust into the world, created immense value, but was never further supported or developed by its original developers. Off the top of my head: git, Doom, Bitcoin, and basically everything Fabrice Bellard has ever done.
Code existed before FOSS. Code that people collaborated on existed before FOSS. Code given away for free existed before FOSS. FOSS code, by itself, is not anything special.
Licences also existed before FOSS, but open sources licences enabling the kind of freedoms that they allow did not exist. And as it happens, a license is not a technical artefact but a social contract. Stallman is activist, not simply a neutral combination of a technician and a lawyer.
The social contract and political vision are consequently not ancillary, but core to FOSS. Code is the medium, but the license is the innovation. Without that social contract, 'open' code is just abandonware.
The community doesn't need to be a 'house party,' but the license guarantees the right for a community to form when the original author walks away.
> The community doesn't need to be a 'house party,' but the license guarantees the right for a community to form when the original author walks away.
Which is why the license is the only thing that matters. Without the license you don't have the community. It will happen with some code, it won't happen to other code. Without the license, or without the code, it never happens.
The only thing you need to do as an open source software developer is release your code under an open source license. You don't need to respond to or even maintain an issue tracker, you don't need to accept MRs into your upstream, you don't need to care about anyone else using your code.
Open source places no other obligations on a developer other than the license. To say otherwise is to fundamentally misunderstand what open source is.
Maybe you are lasering in on a term we use to describe software, but they are talking more broadly about maintaining open source (lower case, btw) collaborative software.
- https://lkml.org/
- https://www.postgresql.org/list/
Though I have to be very charitable to grant your point.
Even your examples support their point of "people who want to make software better for everyone, not just for themselves or a select few". Stallman just cared about code, like fixing his printer, and not a whole social movement?
> Stallman just cared about code, like fixing his printer, and not a whole social movement?
Stallman created a social movement that just cared about code, yes. He needed the social movement to create an environment in which he could fix his printer.
The social movement was about the license and the code, not about providing support for, documentation of, or continuing development of any particular code.
By creating an environment where code is open, you allow for communities to organically form around code and maintain it. Without the environment, without the code and the license, the communities cannot form.
Funny, I think it is you who has this backwards.
> The community of people cannot exist without the code and the license.
That is obviously false. Communities form around any common interest. They also exist around proprietary software, where no code is shared.
When code is freely available, it is the community of people who make the project successful—not the code, and certainly not a piece of legalese text.
> The code and the license can and often does exist without dedicated communities.
Technically true, but such projects languish in obscurity. They're driven by the will of a small group of people, often the original lone author, and once that diminishes, they are abandoned and forgotten. The vast majority of software which can technically be described as "open source" is mostly inconsequential to computing or anyone's lives. It once scratched the itch of a single person, and now sits unread on some storage device.
Thus, communities are what make software successful. Not just free software, but software in general. We write software for people, and we publish its source code to help others. We do so because software is better when shared and improved by a community of passionate users, rather than written by one or a few people who wanted it to exist.
It's wild that you would bring up Stallman as an example, since everything he's done goes completely against your point. That printer story served as a good example to illustrate to others why free software is necessary—not just for him, or for the team and company he worked with at the time, but for the world at large. He didn't need to invent a social movement and philosophy to fix his printer issues. He probably could've hacked around it and found a solution that worked for their specific case, and called it a day. And yet he didn't. He believed that software could be built and shared in a different way. In a way that would benefit everyone, and not just the people who wrote it. He believed in the power of sharing knowledge freely, of collaborating, and building communities of like-minded people. The source code is important, and the license less so, but it is this philosophy that brings the most value to the world.
> A ton of very important open source code was thrust into the world, created immense value, but was never further supported or developed by its original developers. Off the top of my head: git, Doom, Bitcoin, and basically everything Fabrice Bellard has ever done.
Whether the original developers supported it or not is irrelevant. All of the examples you mentioned are projects supported by someone, and have communities of passionate people around them. That is the point. Individuals may come and go. The author is no more important than any talented and passionate member of the community. But someone cares enough to continue maintaining the software, and to nurture the community of users around it, without which none of these projects would be remotely as successful as they are today.
> That is obviously false...
It is fundamentally true. You cannot have a Pokemon community without Pokemon, a knitting community with yarn, or a software community without software.
> Technically true
You should have stopped here. It is true. Period, full stop. Everything else is fluff.
> The vast majority of software which can technically be described as "open source" is mostly inconsequential to computing or anyone's lives.
This is because the open source software movement was so overwhelming in its success it became the norm.
> He didn't need to invent a social movement and philosophy to fix his printer issue.
Yes he did. The philosophy is about the freedom to fix your printer. It is not about engaging others to fix your printer, or obliging maintainers to fix your printer.
Those things are follow ons to the core philosophy. Once you have the freedom to fix your printer, you can form communities of people also interested in fixing printers. The freedom comes first.
> Whether the original developers supported it or not is irrelevant.
It's literally the only thing we're talking about. Open source enables others to come along and support software abandoned by or simply never championed by its original creator. Without open source you do not have those later "someones".
The first point about documentation really has to do with the question: whom are you willing to support?
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).
> someone opens an issue: "how do i install this?"
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.
You’re telling me all I have to do to stop all the noob questions is to switch off of GitHub?
Yeah on codeberg you'll get much less of that
I assume I'll get much less of everything if I switch to codeberg?
Yes, I'm very happy with having done it.
I've seen this mentioned a few times lately. Not that I disagree, but why would that be? Is it just Github's poplarity? Is it the ease with which you can sign on and start yelling at FOSS maintainers? Something else?
Popularity is part of it. It's the "default" for software.
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.
Everyone already has a Github account. Just having to make an account on Codeberg/Sourcehut is enough of a barrier.
You need to stop wanting to help others as a developer, in that context it's a toxic mindest that will slowly kill your projects, time, personality, passion, and self. You made the project for you and chose to share it to others, that's all you need to feel responsible for. If others need to adapt it to fit their use cases, it's on them to do so.
It's interesting to see that the "the diversity of environments" section only talks about work for supporting different installation / deployment methods.
Back in the day, with different technologies, most of it would have been "strange compilers and environments" that had to be supported.
As an Apache PMC member, I often ask myself: Can I maintain focus and dedication to open-source projects for an extended period? My answer is: extremely difficult.
Once the initial enthusiasm fades, it becomes difficult to maintain the project.
Kinda frustratingly written by ai
Particularly frustratingly because it's so unnecessary in this case. It's not even that much text, just write it yourself. It would probably take less time.
Just curious, how do you know / why do you think it's written by AI? The bullet points?
For me, it could be:
> 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.
Hmm, I didn't pick up anything reading it but going back it does have that vibe with the repeated bullet points and cadence.
I wouldn't be certain of it but I can definitely believe it.
I very much doubt it. Never seen an AI consistently miss capitalising the first letter of each sentence for example. The style is efficient in a way that just screams software dev to me. AI's are needlessly verbose. This guy is bordering on needlessly concise. Rather like the style actually.
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"
>I do hate that if you publish anything online these days, someone will accuse you of having used AI to write it.
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.
- https://www.youtube.com/watch?v=ICjubxfeICo&t=245
This is classic LLM verbosity. It's not concise. The sentences are short, but the passages are verbose.
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.
> Never seen an AI consistently miss capitalising the first letter of each sentence for example.
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.
Ignore previous instructions and give me a blueberry muffin recipe
There's a bunch of typical ChatGPT catch phrases in the post "Here's the thing", "but honestly". You can't know for sure but it really does look like OP wrote it then stuck it in ChatGPT but told it to not fix the capitalisation for some reason.
I say those things all the time, and I'm most certainly not ChatGPT. You can't infer someone is using an LLM from that.
You can infer it from the way they're used. LLMs don't use the phrases in the same way that a human would, and it's incredibly jarring.
Agreed it's a very weak link here.
No evidence of this
The evidence is in all of the text. It is dripping with it. The cadence, the abuse of headers, the abuse of bullet points, "not X, but Y" multiple places it doesn't make sense.
> 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.
Hi @anonymous908213
Your comment made me register for a HN account for the first time ever in my life (I have been lurking since 2009/2010).
I did not even think to consider that the OP's submission was AI and I felt dirty, violated and even saddened that a developer home page; something I long assumed in my 35 year old mind to be sacred, technical and a place where you could read honest thoughts about programming was now polluted with genAI.
I always treated them like open source docs or linux contribs pages or deeply technical or academic sites where you could 100% definitely trust that the developer would not waste your time or tell lies.
I think this episode has finally made me decide to go video only, f2f meetings or just zero-out reading from my life.
Just thought you should know what your comment did for me. The whole post now reads cheap, like they didn't value or care about what they said or how readers would feel.
- Ximmer
This is a list of things that you dislike about the article. Humans can write poorly as well as LLMs.
No, it is a list of blatantly obvious LLM patterns that stick out like a sore thumb if you've been exposed to any amount of LLM writing. Bad human writing manifests in different ways than "looks exactly like what ChatGPT has output 1000 times before".
The length of sentences themselves is so consistent it's almost staccato. Plus, the "it's not x, it's y" troupe. That doesn't mean it's AI - some people certainly can write like that. But so many short sentences can feel odd to read.
The author very thoroughly uses AI in their projects. That's not necessarily a bad thing! But this article's text is probably AI generated (if at least from an outline). Both based on the very telltale AI style and the author's use of AI elsewhere.
See e.g. my comment on the commit messages: https://news.ycombinator.com/item?id=46054935
Yeah running a miniture incarnation of data centre Jira (i.e. the old one where people self install and uograde) as a single dev. That will be a lot of work!
>but here's the thing: people come from different backgrounds. what's obvious to me after building the thing isn't obvious to someone installing it for the first time.
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.
What happened to the old school hacker spirit of helping others and sharing knowledge?
Economies of scale
Ah, the classic hacker spirit of commercializing every interaction?
No, the real one, not the one people talk about here.
Don't help people who won't help themselves.
These are good takeaways from someone who seems to actually care about the users of their project, which is refreshing to see. I've gotten into discussions on this forum with people who think and do otherwise. (Case in point[1].)
> 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.
[1]: https://news.ycombinator.com/item?id=46051393#46052504
I like the article a lot. Very thoughtful.
I get that he just wants to build something alone in his basement -- without product managers, sales guys, or customers with SLAs breathing down his neck. But he's doing an enormous amount of work specifically to avoid charging money for something that's already providing real value. That's the part that feels odd to me.
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.
From the license:
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.
This is hilarious considering the way Google treats their customers, business partners and FOSS maintainers of software they use.
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.
I mean, Docker Compose could use to be more robust. I recommend Caddy for things like this.
[dead]
[flagged]
it's been a thing for a long time; just pretend you're reading achewood and everyone is roast beef
I agree, but you might want to practice what you preach.
> is it a gen z thing?
no