A open source library that I worked on at Intel (the Hyperscan high performance regular expression library) had to shed most of its staff (including all the original folks who worked on it, including me). One of the big contributing factors was a sense that "well, who really uses this". The answer was "tons of people, including some major Intel target customers" but a number of Hyperscan users picked up the library and never told anyone (not asking for public plaudits, but even a private communication would have been something to show our management).
When you can't even say "thank you, we're using your library now, it's great" in a goddamn email, don't be surprised when 75% of the people maintaining and advancing it don't have jobs anymore. Never mind paying money or contributing - even acknowledgement.
Open source is a recipe for burn-out. If something is important to people - especially corporate interests - there needs to be a way of getting paid. Much as I dislike those wacky "free for non-commercial use, otherwise, give me a call" licenses, I'm starting to see the point.
I think GitHub should really have a way for users of your repository to somehow illustrate that they're using your project. Maybe that'd even help to get into contact with your users and the companies building solutions on top of your product. Maybe it's just me, but I often feel blind to how and where your project is being used.
EDIT: Typo.
Abandonware is not such a bad thing. It served its purpose for a season, then the world moved on. Nobody's out there trying to breath life into the Apollo program. Or into Mosaic. And that's ok. It doesn't diminish how awesome they were at the time.
Well "stars" are kind of like that. Also the insights page tells you how many times your repo is being cloned per day, so that's one metric you can use to see how "used" your project is. You can also search GitHub for the name of your project and see how many other projects are cross referencing it.
But obviously most commercial usage remains invisible. I could imagine a hybrid cultural/technological approach were dev teams publish/are allowed to publish at least usage metadata were they can't publish source (or actually contribute).
There's a huge tie-in with security, I remember heated discussions were one side tries to establish this as an audit mechanism ("how vulnerable is product x really, in terms of outdated dependencies?") and incentive for updating, while the other side is crazy scared of punishing a list of potential attack surfaces. Perhaps the implied attribution benefit should become part this discussion as well?
Why don't you? That's how you get people to step up.
I kind of use forking that way (although more when I like a project, it's not necessarily a promise that I'm using it anywhere). This ensures that I have a copy of the project in the state that I originally liked. Then if the project is either (a) taken in a disagreeable direction or (b) deleted, I still have my local copy. I can also always update from upstream if future development occurs that I want to benefit from.
That said, I don't fork all the open source packages I use, although maybe I should.
I ended up feeling... amazed, really. I was going to say sad, but if the most prolific oss dev can’t make more than an entry level salary from 2008 on community support alone, it’s not sad — it’s simply how it is.
People need to think of open source as something they do for themselves. I put stuff out for people to use. You don’t like it, you can use something else. I try to give as much help as I can, but only because it makes me happy to do that.
The recipe for burn out is, you’re not putting yourself first. You should! Most people do open source the way a jazz pianist does a jam session on the weekends, but it sounds like your typical jazzist (jazzer?) ends up happier than most of us. It’s worth taking a hard look at why.
Don’t do it to yourself. Life’s worth more. I understand why they left a lengthy apology here, saying “I let the community down” and such, but it’s just not true. Everyone who makes their code available for others isn t a letdown — you’re a hero to 12yo me, who would’ve given anything to get a glimpse of any closed-source gamedev engine. That’s what OSS is all about: letting people build on your work, not working yourself to death for other people.
https://blog.sindresorhus.com/answering-anything-678ce562379...
> How do you make a living if you don’t have a job and don’t take donations?
> I don’t make a living, currently. I have some money saved up. I don’t really care much about money or material things, don’t use much money, and don’t have a lot of monthly expenses.
> Do you enjoy being homeless?
> Definitely. It’s nice being free to travel anywhere at any time. I don’t really care much about material stuff either, so I have everything I need and care about in a small backpack.
> How to be rich?
> You don’t want to be rich — You want to be happy.
You said you worked on the library at Intel. Doesn’t that qualify as getting paid for your work?
That’s not the usual setup when developers talk about getting paid for their OSS contributions, usually off the clock, so its not clear what the lesson is here besides politics/resourcing at big co (which is a real but distinct problem).
This situation was supposed to be where OSS shines - instead of a dedicated team subject to the will of a single private corporation, a project should have multiple contributors, working on their employers’ time - then there is no central team to be disbanded.
It's just rather discouraging from the perspective of working on anything else OSS as an independent developer - unless it's a pure passion project. Given that the stuff I'm interested in often tends to wind up being hauled into high-performance infrastructure that's kind of important to bigcos, it's a bit depressing.
The whole multiple contributors thing is a great theory and works for some high-gloss, high-profile projects. There's a huge tail of OSS where the expertise just isn't there and most companies just want to free ride.
It just shifts the problem along; instead of getting paid, you need to justify to Intel why they should pay you. Showing that you're keeping customers happy, building Intel brand value etc. can be part of that, but only if they give you feedback.
I think the off-the-clock long term OSS maintenance is rare, because it is actual work. And contrary to stereotype, no matter how passionate you are, you will burn out if you work two full time jobs at the same time.
They can offer a new subscription model for people with expendable income and companies with benefits, on a per user basis instead of a per project one.
They can offer monetizing issues, e.g. promoting a question or issue report with an X amount of currency.
OS maintainers can create a bot that asks people to contribute financially or to reach out to their employer to do so.
Github can push their sponsors program more, and aim it at companies / "enterprise" sponsors.
Maybe if it was an optional and project-oriented patreon-style?
Your suggestions seem like a win win for Github and the hardworking OSS maintainers.
You could just leave it up to somebody else to solve, but if you've got viable ideas, give it a shot.
Thanks for your work on hyperscan! I think I'll identify a few other libraries that we use and reach out to their developers - it's a good reminder to not take everything for granted.
https://geekmonkey.org/regular-expression-matching-at-scale-...That change alone might be enough to break the fragile conditions that allow the license to be considered Open Source... but who cares, the mental health and happiness of OSS devs affected by the difficulties mentioned in here is more important than the technicalities of what could happen by a small clause addition.
I remember using one, but I not exactly which one; it's not in the Wikipedia list.
I like the project I'm working on now, but if I release it publicly I don't want to deal with 98% of the possible users. I'm mostly worried about the idea that the itch I want to scratch will turn out to be popular, because open source is mostly horrible.
It would be great if there was a method for privately tracking who uses what libraries so that the marketing/support model could be used. Tons of companies use Tensorflow to run on TPUs, but Google doesn't know if tons means 90% of their cloud customers or 5% ( unless they put library tracking directly into the TPU which ... is possible)
I'd love to see a feature on Github for tracking dependents of a project. I'd also bet that most major firms would be willing to allocate a small funding level to ensure that lynchpin dependencies such as OpenSSL, git, maven and other projects remain viable - after all it's probably cheaper than migration later!
A bodgy, high-touch system that required endless customization and lots of meetings would become a high profile project that could ultimately get the corporate equivalent of high fives all around. Meanwhile, if you ship a library that Just Works, people quietly link it into their product and move on with their lives.
I rather work for ecosystems where customers see a value that developers keep their job.
"Developer tools seemed like a good industry to be in, "sell shovels in the gold rush" and all, but it turns out developers prefer to dig for gold with their teeth."
Obviously there are some potential privacy issues here, but adding it to the README and doing a single ping on use seems like not too bad a compromise to keeping open source projects alive.
It won't be 100% accurate due to offline use or available to many open source software projects due to their use case, but most applications would probably connect.
For the area we were in (pattern matching is basically computer security-adjacent), this would have been equivalent to shipping malware in terms of sheer career-destroying potential.
Not everything is a long-running desktop app.
What I did kinda want to know is if a major Intel customer put our library into production. Sometimes we figured this out by detective work - e.g. one of our staff had a bunch of custom standing google searches hooked up to an RSS feed that would often find big vendors handing out paraphrased versions of our documentation to explain which regex patterns were supported.
I do prefer to work on libraries that are available for commercial work. But I also cannot get my employers to pay for said libraries. Which is how many of us started using OSS in the first place - because nobody could smack us with a checkbook and say no.
If I were doing serious OSS I'd really hard consider adding just something like a once-a-week ping just to be aware of users count
ofc with an ability to disable it
The only sane, healthy, sustainable license is the "wacky" one you describe: individuals (and possibly even (very) small businesses) can use it for free. Everyone else needs to pony up. It's absurd that a ton of the software allowing giant corporations to run day-to-day is not only created but ACTIVELY MAINTAINED by an individual or groups of individuals for free, as if they were running a soup kitchen. Microsoft, Amazon and Google are not homeless. They can, and should, pay the people that make the software that keeps them going.
"But if it's open source, couldn't they just fork it and keep using that for free?" Yes, but a. not legally, if the terms forbid it and b. They would now have to find a new group of people to maintain the code, after just creating a bunch of ill-will in everyone in that space. In the end nothing is absolute: you can always just pirate closed-source commercial software too. But doing so has serious negative consequences.
First time I've heard that on HN ever. This needs to be common knowledge so more people realize how valuable they really are.
> "But if it's open source, couldn't they just fork it and keep using that for free?" Yes, but a. not legally, if the terms forbid it and b. They would now have to find a new group of people to maintain the code, after just creating a bunch of ill-will in everyone in that space. In the end nothing is absolute: you can always just pirate closed-source commercial software too. But doing so has serious negative consequences.
This is neither free nor open by either the OSI or the FSF's definitions.
The real problem is that there is a fundamental crisis at the intersection of capitalism and human freedom/autonomy that may be impossible to resolve.
We already do this to an extent but the mechanisms are not strict enough. The stake on the ground needs to be put much earlier on, for much less demand than it typically is.
Ok man. I mean, I'm quite capitalist myself but I draw the line before "don't share things with everyone because sharing free things like that is for suckers/commies/whatever".
If you don't like doing open source, don't do open source. There was never a requirement for you to do open source.
Doing open source doesn't mean tending to other people's feature request, or even looking at pull requests. It's just releasing code under a certain list of licenses. Which you can do, if you want to, or don't. If you want to discriminate between your users, you do you, that's not open source but unless you run afoul of the law you can go and do that.
When Google spends a billion dollars sending cars all around the world taking pictures, they are doing so in a way that the Open Source world can't centrally compete against, as they don't have the billions to get that done. This means that all Open Source mapping software will be missing a crucial feature that users rely on, and will therefore go unused. But meanwhile the libraries that those Open Source Software use, Google can freely use within their walled garden. On the other hand, Microsoft paid a great deal of money to researchers with Encarta and had this same exact structure and Wikipedia came in and disrupted them. It takes more time for the decentralized approach to come online, but as long as it's possible and the data is kept high quality Google Maps will slowly lose market share to OSM.
So eventually decentralized open source software will catch up and these billion dollar companies will go to 0, but in the interim period, and as innovation never truly ends so there is always a new horizon, we should consider creating a better incentive structure.
The big problem with capitalism today is that we care very deeply about prices. Prices is where supply and demand match, but we no longer have any supplies. We have costs of 0 and values that can differ between people. Price is merely a negotiation between the two, with Open Source Software declaring 0% of the value, and Billion Dollar companies declaring 90% of the value. Price has become a flawed metric. What society truly cares about is the surplus. What we need is a way to do a sort of Incentive Compability system[1](i.e. a Vickrey Auction) so that these Open Source Software can show the value that they produce. If they can show that their development costs were offset by their users values, they should be funded for it. Linux would certainly have a much higher value than Microsoft in this view, and would therefore be able to fund their own data collection systems, and would likely leave those open to the world so that everyone could reuse the Linux Street Map data for themselves.
Why? Disliking someone not giving you free money seems rude.
But, is it just me or has it become rarer for open source project maintainers to feel free to let projects go? I don't mean to let them die, I mean, to find like-minded individuals to which you can defer some or all of the work? I realize that as the original author one feels a sense of ownership, but if you want it to continue, and you don't have the time, there is nothing wrong with putting out a call for someone to take over maintainership.
Most projects that I've maintained have been my own work but I've also taken over maintainership from someone on a popular project, and it was a great experience. I got to work with a good code base, add my own ideas, offer some direction, and I learned a lot about maintaining code for longevity, integrating community contributions, and I cared about it probably more than I have for much of my own work, because I felt that I owed it to the original author to do a good job.
Now, several years later, I do not use it myself as much, and I am perfectly ready to find a new maintainer for it, should someone appropriate come along. (That hasn't happened but the project no longer takes a lot of my time. since new solutions have come along, so it's fine. If it did take more time, it would mean there were more users, and therefore probably there would be more interested parties in taking over maintainership.)
I encourage authors and maintainers who are feeling they are reaching this burnout stage to feel more comfortable putting out requests for help, it can be a good experience and even encourage community building around your work. You don't have to be a BDFL, you can be a temporary one.
It is particularly apparent in schools. Students start something, then they graduate and do something else. Most of the times, no one takes over, at least not in a sustainable way.
It is not always the case, but it is the most common outcome. Simply, I think there are simply more people who want to start something than there are people who want to lead somebody else's project.
Anyway, nobody ever simply gets replaced. When you change the people, things change. Some times it's a disaster, other times it's an improvement, but the result is never exactly like the beginning.
This isn't purely hypothetical: it's the foundation of my own career.
This may also explain the imbalance you see.
Having said that, I also think that just as often it _seems_ no one is available, until someone steps down and things do turn out allright. Of course this idea that a project will stop if the passionate individual stops is based on exactly the observation you describe! So that fuels the idea but you'll never know until you stop.
I've had a few people offer help over the course of the years, but unfortunately they don't always have all the skills needed, so they can only help with a part of the project. When they do have the necessary skills, they don't have the time.
As I don't have the time to keep working on both projects for free, I'll probably abandon the lesser used one. I'd love to find a successor for the second project, but to be honest I don't have any idea how to go about finding that person.
(I don't want to post specifics of the projects because I'm trying not to link this account with my real world identity)
I don't have experience with it, but it seems active and better than abandoning a project.
Good luck!
So whats wrong with allowing them to help with those parts?
I've seen lots of these calls for help fail.
And someone else points out: It's open source. Literally anyone can continue the work at any time. There's no need for the original creator to find someone else to continue it. Anyone can just do it.
They literally can't though. Only the owner or a maintainer has permission to merge PRs in to the main branch. Anyone can fork a repo, write a patch, and PR it, but that's where outside contributions stop. It still takes someone from the original team to accept a contribution. Forking a project and then maintaining that fork as a separate project is an option, but it's divisive one that a lot of the community will react badly to if they see it as a hostile takeover or if there's a change in goal (eg making a commercial product out of the abandoned project.)
Everyone these days is chasing the latest Javascript framework hype and practicing the next big modern language, e.g. Rust or Go.
But most important infrastructure open source is written in C++ and to maintain a cross-platform library linked into hundreds of apps, you need years of practical working experience to accurately estimate the side effects down the line from a seemingly innocent patch.
There's few people who have that experience. Plus as the greybeards retire, more and more companies need to hire this kind of developer to keep their own stuff running. So the people who could do open source usually have a waiting list for future freelancing clients.
Same will happen when everyone that actually made BSD and GNU happen is no longer around, it will be business as usual.
Suddenly, even just relinquishing control can be a bad thing for the community.
That won't work for most small projects though, so orgs like https://sfconservancy.org/ exist.
Not sure what other options like SFC exist, and the differences between them though.
At a minimum you'd want them to be in charge, and fire the current lead developer if they go rogue.
While interested people will come, I think it is rare that a distant and complete stranger will suddenly appear and not only share your same interests but also with the same level of compromise. And given that some projects now seem to suffer sudden popularity growths as flavour of the month -or week-, it would also be rare that such a person or persons would appear before that happens and the pressure suddenly increases.
To release way less often has been one of the best changes I've made and also dual licensing. If people will get me a hard time then pay for that part of the development.
Burnouts like this happen, because it is not actually possible to keep working on side projects for 30 hours a week on top of actual 40 hours a week work.
Whoever would take it would face the exact same issue.
There are few projects that actually get used for longer than a couple years at most, the churn (especially in JS projects) is massive. You'll always find people to work on Big Old Stuff that's used everywhere - think Linux kernel, Qt/KDE, Gnome, Firefox, Thunderbird, libc, gcc, LLVM, jQuery, ReactJS - but the small stuff that gets disrupted ehhh replaced by some shinier newer toy? That will eventually diminish and die off, when the original author either has all their needs met, burns out or no longer needs the project.
Additionally, all of the above projects have massive financial firepower and/or other institutional backing behind them that contributes either with direct man hours or financial grants.
It doesn't matter if it takes half a decade to implement the last 20% of the feature set and iron out all of the bugs and corner cases, if you can bang out a prototype in a long weekend, someone is going to do that over and over. Meanwhile, if it takes nearly a year just to get something half-working, the existing open source codebase has to be pretty bad for you to not at least fork it.
Why is this necessary? If someone wants to start maintaining a project, all they need to do is fork it. For example, ZBar is now being maintained by a Linux kernel developer. His fork started getting updates and contributions and is now objectively better than the original project. Linux distributions have already accepted it as the master branch.
Social media - and GitHub is definitely a social media tool - gives people an easy way to shout at you whenever they're unhappy, and gives them plenty of tools to get in your face while making it very hard for you to cut them out.
I think it has always been rare. I generally avoid projects which are under a person's own github account because to me it is a massive red flag that they will kill the project by failing to maintain it and failing to hand it over at some point in time.
When you build a project the most important part is to eliminate dependency on yourself. If you are approving all commits, or doing most changes, you need to fix it, because it is a problem.
I don't really understand pedronauck's response. If he does not have time, he should tell people he does not have time and they should make PRs, is that not the point of open source projects?
There is nothing wrong with demanding that people help themselves, people are not entitled to your time, and unless you are not processing PRs then you are not the problem.
1. Sometimes people create a project for themselves but use Github as a convenient place to store the code. I've done that before and found people filing issues against those projects.
2. Sometimes people create a project to scratch a personal itch and put it online in case it helps anyone else. Not in the sense of hoping people will use it but rather than in the "I bought 10 bottles of wine and only drank 9. Help yourselves to the last bottle" sense.
Maybe there should be (maybe there already is) a software license that should better explain the "wrote this for myself. You're free to use it but don't expect support".
3. Some people probably do hope that their project has some, maybe even just small, degree of success but they host in their own user profile because their Github profile is their CV and they're starting new projects in the hope of landing better jobs.
This 3rd group are a particular problem for open source. Not in the sense that they're doing anything wrong -- they're clearly not. But in the sense that you end up with a lot of NIH since the primary reason for a project existing is to boost the CV. So when the primary maintainer moves on, any future contributors will prefer to build their own solution rather for their own CV rather than taking over maintenance of the existing project.
---
It should also be noted that not all projects are large enough to warrant their own Github org. Take BurntSushi's stuff. I'd wager the percentage of HN developers who use BurntSushi's code is in the double figures. But there'd be no sense in every one of his projects being it's own org.
* open source project
* success
* no monetary reward, maybe just cost
* burnout
* project abandoned
This is why I don't try to make any open source projects - what's the gain?
I'd only do it if it paid money. If people aren't willing to pay then I'm not willing to work.
Yep. Scratch your itch. If someone else wants different features then let them add them or compensate you for your effort, unless of course working on those changes is interesting for you or would help scratch your itches. If you do it for the "interesting/fun" reason make damn sure the requester knows that if that interest/fun stops then free work on the feature will stop and it might get removed completely if not maintaining it becomes a security problem or other burden.
"But what about the community?!" you hear them cry. Fuck 'em. Or at least suggest they do something for the community they care so much about by putting in a bit of effort in to maintain it, maybe forking your project to do so while you deprecate the feature and work on things that are interesting or useful to you, or paying you to work on the bits they particularly want and you don't. Your mental health should be much higher up your priority list than doing work to help people who (call me cynical, but...) probably wouldn't do the same in reverse.
* Write to high profile companies that use your OSS work asking them to contribute. * Get a very polite and convoluted "no" in response.
Also as someone who works in a Microsoft language, I get really tired of silly immature Go/PHP/Python developers who seem to get off on hating on Microsoft and have this strange desire to preach that opinion everywhere.
It could be fun.
The hope to find similar people who really want to work on the project too and split the workload for everybody.
Giving something back: i use so many OS tools, so i give back a tool that a made to solve a problem for me, hopefully it could solve problems for others.
On the other side, you don't have to maintain an OS project, you can publish it "as is".
I know people that publish basic OS software and sell their time to extend the project to the needs of customers. (so it could be a business model)
Burnout is not a OS specific problem, it is something that anybody has to learn and find his own limits. I hope the post author learned how to deal with it in the last year.
I can think of two reasons to work on open source. Altruism, you want to give back to the community without expecting a monetary gain in return. Investment in skills, if you want to differentiate yourself from peers, you'll have something to talk about to potential employers. It is a great opportunity to learn and become a better software engineer.
Would a form of UBI, together with 20 or 30 hours work week work for you? I seriously wonder what the state of open-source hardware and software would be if society would focus on redistributing automation gains more.
Every developer is different, but ideally they would do it full time if it pays significantly more than their current job.
We don't need more laws. There is something called a License Agreement.
However if you publish your stuff on GPL and other permissive licenses you can't really complain about Amazon, Google and Microsoft making millions on your code while you beg for donations on your Github page.
OpenSSL has only recently received support despite powering all the Internet infrastructure for decades.
Xorg, xterm etc. have received very little or nothing. Same for most Unix system tools.
Projects that receive the most are "open" source corporate vanity projects that are also used for bait-and-switch hiring.
Nobody says that one company has to support every project and google supports many open source projects.
If you want to require payment from anyone who uses your software, use a proprietary license and charge money. The "fair share of revenue" in free for free and open source software is correctly "zero."
In the long term, altruism only works if there aren't too many leeches. Up to 2010, OSS authors at least got recognition, could stay aloof and in general weren't little corporate bitches.
Now, this has changed, so there is no longer any point of writing OSS for free. The corporations have won their long term game, using the freedom propaganda until they owned most of it.
I think Github can be a positive force for change here. Redesign the UI to encourage donations, to encourage people to get involved in project work, to write less hostile issues, etc. If devs and designers can weaponize UI to create addiction, anxiety and FOMO, maybe we can use the same tools for good for once.
Open source maintainers used to have the sterotype of being rather harsh, and basically telling people to f off if they had stupid questions, didn't RTFM or didn't follow cultural norms. And dont get me wrong, there's a lot wrong with that, but maybe it was also that way for a reason.
Modern devs in those ecosystems that use a lot of dependencies see their jobs as plugging together lumps of other people's code. There's a very strong "don't re-invent the wheel" vibe - the first thing any dev does when presented with a problem is look for an existing code base that solves it.
This means that people have their entire jobs on the line relying on other people's code. If the OS library that you found has a bug in it, and your project depends on that library, and your manager is shouting at you to get it fixed, then you're having a bad day. In an ideal world, "fixing the bug" would mean diving deep into the library code, finding and fixing the bug, and submitting a PR to the maintainer. But this can be beyond the dev's abilities, especially when the only kind of coding work they're done is plumbing together dependencies. So they only have two options: try and get the maintainer to fix the bug, or switch dependencies (which might take longer, and possibly have other bugs).
There's a real sense of "I'm using your library, giving you cred, so you need to fix it for my use-case" that I've seen. It doesn't help that dependencies are free (as in beer) - it's a well-known truth that people don't respect things that are free.
I think for all of this to change, we need to scale back the dependence on dependencies, audit dependencies properly for security and sustainability issues, and pay the maintainer. If there's any change needed in Github, it's that Github needs to start charging a fee for every download.
It's especially bad if a big company links to you from their tutorial or in their add-on catalogue because then some of their customers will feel like your open source is part of the commercial offering that they bought. So then you're forced to do open source support for entitled aholes and someone else is cashing in on your work.
You're not satisfied with my open source work? Fork and fix it. You can't fix it? Hire somebody who can. You don't have the money to hire somebody who can? Then find other users, do a fundraiser and hire somebody who can fix the code.
This culture of entitlement has gone way too far. Some companies make billions out of some open source project yet never contribute a cent or a man hour back yet you still find engineers from these companies complaining on github issues that bugs aren't resolved quickly enough.
I say this, this might be the golden age of open source now but it's not going to last. Users have become too petty and entitled.
The entitlement drove me out. The market is more about chasing shiny things than using things that are the best fit.
I have an OS project too, people want 1000 things, you can say "ok, make a PR and it will be integrated", many make a good PR, but that's it. Normally they do not make any support, they made feature they need, and they are gone when it is implemented. (not all, but most people)
And when issues come up, because of the new feature, you can try to contact the creator, sometimes they help, sometimes not. But to contact them is work too.
I am so happy that i found a "community manager" (after years and many try it), who does all the non-programming stuff and keep the project alive, cause my time is spare too.
And perhaps a little bit of false guilt, because they were overwhelmed by the sheer amount of work. Perhaps they didn't estimate how time consuming it is to do this and feel guilty about that.
This is a conceptual hack to avoid considering the state of the ecosystem.
Think of software like a living being, not like a statue etched in stone (although even statues etched in stone degrade).
Maybe people shouldn't start software projects if there isn't a "can leave it here unmaintained" milestone within sight.
It's because these projects have tons of dependencies and moving parts which tend to break themselves (often for very little reasons) so of course it's going to affect upstream.
The software you listed are usually mostly self-contained or rely on stable projects.
There is no such thing as "stability" in the Node.js ecosystem (which isn't javascript itself).
We paid him $1500 for a couple of days consulting. He showed us how to fix a couple of tricky bugs and gave a talk to the eng team. At this point we've more than recouped the investment.
He was psyched to see his tool being used and I feel the visit contributed to him continuing to maintain the project.
After those two days we also tried to hire him (he declined because he was making bank elsewhere). But those two days were also the best interview process ever because we did hours of pairing in non-interview mode.
If you're a senior dev at a tech company with money you can easily make this kind of thing happen and it's such a win-win
Convincing corporates to do the same is a little trickier. They want things like invoices, which can be hard for many smaller FOSS projects. Not every FOSS developer has a consulting gig. Not sure how to help out those developers, except by using their software and being appreciative, I guess.
But they could! It's as easy as saying "I can consult on $topic, please contact me to discuss details."
Then you charge money and do the work.
The same limits I impose on the community I fully expect to follow when working with any OS project. Period.
Remember, in that "other world", we would have to pay for each and every little proprietary piece of sh* code. The "new world" will not be built by profit-maximizing value-extractors, and if you think it will, then I wish you a happy burnout.
Also remember, that for millions of people the notion of giving away something valuable for free is totally absent. They literally fail to comprehend. They are happy to sell the same thing many times over.
In my book, OS software developers are living in the future, today and a lot of the friction comes from a world, that just works by a totally different set of rules.
I get the value of free software, but lately it feels like OS went from geeks sharing code because we value knowledge, to people who use the software making demands on someone else’s personal time.
Yeah, I think there are a couple of problems with Open Source as it is done today.
One is that people are making things that are useful to profit-maximizing value-extractors. I don't know how much is because their "itch" is aligned with them, or because that's the way to get a top project on GitHub and make a name for yourself. But seriously: stop making things that are useful to profit-maximizing value extractors. Make software that is useless[1].
The second is that we really have no kind of license to discourage the use of useful software by profit-maximizing value-extractors. In large part, this is, IMO, because FLOSS licenses have prioritized the rights of the user (who may be a profit-maximizing value-extractor) over those of the author or the community. It is also in part because licenses seem to be the wrong kind of tool for controlling how our software is used. CopyFarleft and Ethical Source licenses are trying to tackle this, but not very successfully, I think.
It may just be my cynical view of the world but it just seems like more and more people are demanding higher and higher levels of service for things that they don’t pay much if anything for.
I play a game right now that is in Beta called Dual Universe. Some people paid for Kickstarter packages 5-6 years ago for around 40 bucks. The game has its areas for improvement to be sure, but some of the players are just horrible and abusive to the community. I know they paid 40 bucks for a vision some years back and maybe DU has overproduced a bit, but the abuse of the 40 or so staff that is trying to build an amazing game where you can build anything you can dream of with voxels is just unrealistic.
I know it’s cliche on HN to blame everything on Google and Facebook, but I really do suspect that the “free to use” model pioneered by these companies (among others, of course, but these are the biggest) have got everyone used to expecting things for free.
If they are all users of your open source software and are begging for features for free, ignore them and focus on yourself. This is why many developers always prioritise paid support or sponsors and the choice of license is also very important.
It's really simple, either the user does the work and contributes the fixes for free (depending on the license) or the user pays for the maintainer to prioritise the work at a cost.
Either way, I will never do free open source work on someone else's deadline and will always do it in my own time. Unless you're willing to pay me to add a feature or support.
This is bearable for a certain amount of time but after that one really has to look after themselves, regardless of financial interests or a crash is inevitable.
Either way, no developer wants to do free work on someone else's deadline and it is always done in their own time, unless they want to pay for the effort.
i would say overwork and no/low pay are the same thing.
If you have a large amount of work being demanded of you by users/companies, then it's time to charge money for the time that would've taken. The charge should be big enough to replace your day job. If it's not, then don't do it, except for any fun bits that you would've already done.
If I had an open source project, I would not publish it on Githib precisely for this reason. Open source doesn't necessarily imply open development, or horizontal organization, or constant support, or anything. It just implies that the source is open.
Plus, on the Internet it's very hard to tell when someone is demanding something from you from when someone is just making a suggestion.
[1] https://docs.github.com/en/github/administering-a-repository...
And anyway, doing things this way I was able to write a database that beaten, in the market, products developed with hundreds of developers while I was alone, so there must be some merit in what the original author feels is worth investing into. So, just do what you want, but:
1. Don't fall in the trap of thinking that who asks you for things is doing some kind of mistake or abuse just because (for example) they are not paying you. Nope, they are fine asking for things, you are fine to ignore the requests.
2. Don't fall in the trap that you are not accountable about the quality of the software just because it's free software: do only want you want, but ship finished work that is reasonably well written and well documented. To do what you want, at your own peace and according to your own personal expectation has NOTHING to do with the quality of your work. Software fails, but one thing is to ship terrible stuff just because "Hey it's free", another thing is to do things the way you want, but with love.
3. When people attack you, reply gently saying what you think. Don't get trapped into fights, don't feed the troll, remember that many criticizing you, if you are stealing money from the table providing something free, have specific agendas (but sometimes they are just assholes), and their goal is to mount a big case. Stop them replying carefully and without anger, then let the discussion end, or continue without you.
4. Make good friends in the process. They'll help you immensely when there are hard times. Remember: the smartest people 99% of the times have a big hearth and are the most friendly.
Often it's closer to next week than never, but sometimes it's not. This sets expectations, and best of all, it just feels very liberating saying it out loud. Some of the stress I had in the past (not just OSS work, also other volunteer work) is having the feeling I was obligated to do stuff; for me personally anyway, this relieves much of it.
Thus far, everyone has understood this too; that it's delivered in a friend/positive rather than snappy way (as I've sometimes seen) probably helps. Granted, I haven't maintained some truly "large" projects since I started doing this, but there are a few of non-trivial size with some amount of issues.
Personally, I think this is better than outright ignoring, at least for me personally (everyone is different). I will feel guilty if I ignore people, and even a reply like the above removes that guilt because I've clearly communicated expectations.
Aside: if you say "I'm happy to merge patches" then you should really do your best to actually do so or not say it at all IMHO (which is also fine). Of course life happens and it's not a hard promise, but you're essentially asking people to volunteer their spare time to write code, and ignoring their code (and time) is not great. I've seen people solicit patches (sometimes very large non-trivial ones), people write them and then ... crickets. Not even a "this patch won't do", just ... nothing.
Unsolicited patches is a bit different, I do try and respond as best/quickly as I can out of respect for people's time, but I didn't promise anything beforehand so I don't feel the obligation, and especially for difficult patches I sometimes leave a similar message as above.
I think there's something about seeing a line item on a UI that really breaks people's brains. This is why sometimes having a conversation on Slack can feel different than Zoom or even in person; there's a sort of permanence on these mediums that don't exist in person to person interactions. I think it's similar with GitHub issues. Seeing an issue and getting a notification for it can make repo owners feel inclined to answer.
Just don't answer. You don't owe anyone anything.
I think once you start making a lot of money from your project and can do it full-time it may help to bring some enthusiasm back (if it doesn't, well you can always leave the project too).
For example, take Laravel. The guy created Spark and Forge and it was an instant hit for those who love his software. I think fontawesome, tailwind, sidekiq, browserless are more such successful examples.
Some means of montesing OSS projects I've seen include:
- Approach big companies to sponsors your project. Often times big and funded companies will love a spot on your readme for a monthly subscription (but they need a little nudge).
- Offer a hosted version (like browserless)
- Offer specialized subscription courses (like Vue Mastery)
- Offer premium features (like Sidekiq)
- Use it to drive traffic to your own commercial business (like jwt.io is for auth0)
success in terms of usage doesn't necessarily lead to success in these ancillary efforts - take for instance docz which is the project in question, its very main selling point is that it's simple enough you don't need support and it generates output without dependencies that is trivial to package or serve yourself
and yet there's mention of lots of people pressuring him to add new features or fix issues.
So i say, OSS developers should actually have a standard set of ultimatums for all projects ; namely, pay up, or don't get any support that the developer doesn't feel like providing.
There should really be a more transparent way that projects like this, canihazip, gitignore, redis, and a bunch of other projects can be sustainably run.
I also see nothing in https://github.com/toptal/gitignore.io and GitHub sponsoring seems to be not enabled.
(just mentioning in case you would make it more clear that you would be happy about donations)
Now I understand that the project was not that valuable but it would have been nice if I could have run it as a lifestyle business.
This is everything with what's wrong with open source. Many companies treat open source as something they have a right to consume and no obligation to support financially or with dev time. Some poor schlub is on the other end working their butt off and feeling guilty, while the company realizes all the value...
That doesn't negate the fact that when you rely on open source software for your business and need more than just read access to the repo it would be polite to wise up on the maintainership status of the project and ask if you can contribute back in any form.
If you manage an open source project, you owe it to yourself to make it clear how other devs can contribute and add features they want to see. Don’t be the choke point. Open it up. That’s the whole point. Make it clear how a user can add to the codebase and encourage them to do so.
It is not perfect of course, but at least it is a good start. Especially the "value-" & opinion-based discussions can be reduced considerably.
I'm currently on a 6 month hiatus from OSS, no one has notified me of any fires so I think everything is just fine without me which is how it should be.
Don't use only PayPal to accept donations. There are countries out there (i.e Turkey) that don't allow PayPal payments.
P.S: I'm not specifically addressing to Pedro Nauck.
I bet if you really want to contribute even receiving some Amazon voucher would help. Just send then an E-mail and sort it out.
Edit: I am the owner of an open source repo on Github which was quite popular a while ago, but fell into disrepair because I could no longer find the time to maintain it. So I understand the pain of this person.
What I'd like to see is a fund which companies who use opensource are expected to contribute to. For every 100 employees at your company building on top of opensource software, I'd like to see at least 1 employee's salary funneled into the opensource ecosystem. That fund could have a default division based on community needs, or each company could specify how their donations are allocated. And if they donate by having their employees publish generally useful packages, thats fine too.
I don't think it should be compulsory, but I want this stuff to be very visible. If someone files an issue against one of my projects, I want to know if the organization they're part of contributes to the community, and how, and to what projects. If you want me to donate my time to fix an issue you're running into, but you don't contribute back in any way, I'd like to know that before I decide if I'm going to spend my weekend helping out.
Right now there's no incentive for companies to contribute to opensource because contributions are generally invisible. And bugs they run into usually get fixed anyway. If we tie a company's contributions to their reputation, and make reputation affect public standing, we might have a shot at changing social norms.
It's a different story if you're being paid to do some work, then you hold a degree of responsibility, demarcated by contract, for the thing you're working on. In the case of open source, however, that's not the case and it's absolutely your right to minimise or drop your support for a project at any time.
Expect nothing, and you can only be positively surprised.
Same sh*t. Same drama and human nature. So much drama about IP and copyright and abandoned mods. Point out that the source code is open. "Feel free to implement something yourself, the documentation is available." Crickets.
I haven't fully gone no-code[0], but I am close to it. I also do this to avoid the burnout trap. Working on large projects is physically and mentally taxing and it's only over longer periods, you find the project is actually an insurmountable task.
Then on top of this, FOSS is never finished. Only few projects have a finished feel to them, and even those require modifications and upgrades. This is why forking dead projects is always a great idea, and why FOSS succeeds.
Here's what has worked for me.
- Provide a paid version + support: The free version on its own does everything. The paid version saves you time. I have a full time support staff that helps Premium customers (they get first priority) as well as Free customers but we won't hop on a call and provide you one-on-one support. That's simply not sustainable.
- I've got bills: As much as I would love to provide everything for free, I can't. I don't have another job, maintaning the plugin and charging for support is how I make money.
- Put money to good use: I use the money I make from the paid version to improve the free version. That way, its a win-win situation for all the parties involved.
And now you have to take care of your mental health, because when you're burnt out or miserable you psychologically can't help others. You take time off for yourself now or eventually you'll physically and mentally break down and be forced to take time off. So even now your decision to care for yourself is actually for the benefit of others.
You have nothing to be sorry for. Thank you for giving docz to the world, and I hope you feel better soon :)
You have a bug they want to fix or a feature they want to add and the author/maintainer is not doing it fast enough? Fork away! Submit a pull request! Oh, you don't have the skills/time to do that? Wow, that's too bad. Offer to pay the author! Post a message to the project list or bug reporting tool offering to pay someone to do it for you. Oh, you want it for free? Immediately? You built critical infrastructure around a tool you don't understand and don't have the skills or resources to maintain? You're a parasite, and can be safely muted and ignored.
This is the important bit: If you're afraid the person maintaining your key infrastructure for free might suddenly stop doing that, just take some time to send them a nice note thanking them. Periodically getting one of those in your inbox is remarkably effective in maintaining passion for a project. Find a way to give them a gift. Do they have Venmo/Patreon/Amazon wish list? Use it. Are you a developer or do you employ some? Fix a bug. Say nice things about them in social media. Offer to help pay for the resources to host the project. Send them an effing Starbuck's card with your sincere thanks.
Edit: https://www.google.com/search?q=how+to+say+no+without+feelin...
I maintained a set of Visual Studio Code builds for the Raspberry Pi and for Chromebooks.
Unfortunately life happens to us all, and due to similar reasons of mental health (and a few family matters that couldn’t wait) I fell well behind on responding to issues on GitHub and merging patches.
It’s hard to know you’re letting people down, especially when it was something you put out there for them that they’ve come to depend on.
In my case my project eventually became obsolete due to a combination of direct vendor support from Microsoft for ARM, and because of Linux for Chromebooks.
In the end I wasn’t upset to move on from the project, I was just relieved that I was able to stop and still point the users back to something officially supported so they wouldn’t be abandoned.
I’m glad Pedro’s doing better, but I really hope for his sake he’s returning to work on this because he wants to and not out of a sense of obligation - his health is way more important than a few feature requests. It looks like a great project, he should be rightly proud of his work here.
Nothing -- nothing! -- stops you from forking my code and making the changes yourself. You don't need to ask me to make the changes for you; you are not helpless. I've already solved 99% of one of your problems, and now I am empowering you to solve yours with 1% of the effort.
Just because I release my code under an OSS license doesn't mean you're entitled to my time and attention. My labor is not free-as-in-beer, and I take a very dim view on wage theft. If you want me to care about your issues, you will pay me my consulting rate. If you harass me about it, I'll block you.
Framing OSS development as empowering developers I think would remove a lot of the toxicity from OSS. Being involved in OSS should be about improving your effectiveness, not working for free for entitled Internet strangers. You owe it to yourself and the OSS development community to demand that you be paid for your time.
There's a kind of pressure that can come from an unsolicited email of a real human explaining how your project is broken for them.
As coding and software development is getting democratized, if you have a concept that definitely has a market even though you are first to market. Other developers will build similar product and saturate the market, essentially diluting your value. For instance, I have been tracking Heroku style deployment tools in the market, there is like tons of opensource platform doing the same thing built by startup as well as individual developers. Same for opensource airtable clones.
1. Repo endorsements by companies or brands that use it.
2. Bounty option on feature requests - aka increase the priority on a request by paying a bounty on it of sorts - attracting more contributors to projects in demand.
Unfortunately there are a lot of people who really will do the bare minimum and take everything they possibly can from projects and give absolutely nothing back.
It's incredibly kind of you to consider your users so much, but OSS only works (in the I'm-just-a-guy-in-a-basement-without-funding way) if it is a personal project. That is to say, if it's something you make for yourself, for fun. Once you start worrying about other people, how they will use it, what they want, etc, it stops being fun. If it's not fun, and you're not getting paid for it, it's just going to kill the project (and can make you totally stressed out).
There are strategies you can use to maintain the project:
- Put out a call for help on your README. Ask for developers to join your project. Ask for people to field user requests. Ask for people to write documentation. You may not get any help at all, but sometimes all you need to do is ask.
- Create a specific method of receiving requests, like a mailing list (one for bugs, one for discussion, one for feature requests, one for security). A mailing list can act as a small road block to filter out less urgent requests, and can make it slightly easier to manage in one place.
- In the past I have tried "feature bounties", a sort of donation where someone paid me just to develop some feature. It didn't work out well. I still had a full-time job, so while the extra money was nice, I still had to dedicate all my extra time to the feature, and if I got sick of it and wanted to quit, I felt extra bad because I had accepted a donation just for it. Plus it required more support later. So I still think you should ignore any requests that aren't something you personally want, and remind people to send you patches if they want code merged. Donations are nice, but be wary if they make you feel beholden to the users.
- Be direct with people. Tell them, "This is my personal project, I only spend X hours a week/month on it, so do not expect any support or features." Sometimes this is enough to get people off your back. Otherwise, I recommend moving off of GitHub or disabling all the features so you don't get barraged with requests.
- Above all: have fun! If you're not having fun with your project, either end it, or make some changes to make it fun again.
The correct answer there is to raise prices.
Another thing that happens a lot is that lower prices bring in worse customers who are more demanding and less respectful of your time.
Then, I don't think this is a specific problem with open source. My view. The lack of knowledge about how to delegate work is a real problem. I mean, I worked with junior developers on the edge of breaking down while being on same team writing pointless games to pass time.
At some point a leader/entrepreneur has to get out of the way and open the path for others to do some/all of the lifting.
This way incentives align so that there's more intrinsic motivation to work on the software.
Then, I don't think this is a specific problem with open source. My view. The lack of knowledge about how to delegate work is a real problem. I mean, I worked with junior developers on the edge of breaking down while being on same team writing pointless games to pass time.
I think this is more of an issue with young people enjoying the heights of the Dunning Kruger Effect.
It seems like a problem that could be turned into opportunity. If one's software is becoming that popular, and the demands for changes so many that it's too much -- why not try to monetize it? Let the current version stay open source, and create customization and support for a fee. It could make the effort worthwhile, and could even grow into a business.
Consumers in the foss world need to understand that getting their wishes fulfilled isn't necessarily going to be free. They might be asked to pay; or, they have the option to fork their own branch.
