Sorry everybody, I failed with you
github.com
github.com
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.
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.
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.
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.
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 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.
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?
As an example, here's a package I wrote which I haven't touched in 3 years: https://www.npmjs.com/package/jumprope
There are no projects on npm which depend on this, and yet it gets downloaded about 3000 times per week. Who's using it? I have no idea. Are they running into any problems? I suppose not, I mean, there aren't any issues on github. Its kinda spooky.
Rope took 5610 ms. 0.001122 ms per iteration, 891k iterations per second
JS toString took 3463 ms. 0.003463 ms per iteration, 288k iterations per second
And your last paragraph nicely illustrates the blindness we get from closed projects/products not publishing their dependency metadata. I suppose that for client side js a tiny subset of usage stats could be generated by CDN distribution, but repackaging is a thing (and for good reason, in many cases)
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.
OSS works best when it’s a small project that does a single thing and does it well, but doesn’t rely on too many upstream projects for its functionality.
As soon as the project tries to do too much, it virtually needs a committee to coordinate it all. If it relies on too many upstream dependencies, then the maintainer will be hammered with complaints that “this doesn’t work with version 1.45 of foolib… fix it!”.
But a project that just lives in its own little world, doing its own little job? It’s something you can just maintain and improve at your leisure.
However, this logic fails for situations where the itchy often aren't capable of scratching. For example, a wordpress plugin. In this case, I think it's a grey area. Maybe users should have to pay since they can't write it themselves. But that attitude would still fail for situations where a library is widely used and security patches would be for the "greater good".
When I worked on an OSS project I hated getting PRs. They usually wouldn't work for one reason or another and I would have to explain why they were problematic. It took a lot of time out of my day—I would rather people just submit bug reports and feature requests.
Yes, with hours of effort you can make your review relentlessly positive and constructive, but then it still hurts and they probably don't have the ability to fix it.
You'll have to fix it for them, which is often harder than writing it from scratch.
What I'd add in response is that this "change request load" is much easier to manage for small, well-maintained projects with fewer quirks.
And if the entire project architecture can fit within your mental buffer space at one time, then it's much easier and faster to parry those incoming change requests and pull requests into clear, effective feedback and code.
Maybe only a few people are using your library directly, but most use it as part of some larger library. That library has a continuity problem now.
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.
Why don't you? That's how you get people to step up.
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.
of course, giving cash is a much bigger gesture than just pressing a star button, but it sounds like the star button is closer in vein to the kinds of acknowledgement people are asking for here.
If I fork a project I am more likely to actually be using it, although in fact I have plenty of forks from simply evaluating or playing with a project
Wouldn't it make more sense to use the "watch" button for this?
As for cloning, I don't clone projects I use every day. Maybe I cloned them once a year ago. Maybe I'm using a package from somewhere and not interacting with your repo at all.
The cross-referencing sounds like a useful metric though, at least for open source use, but many projects are more useful in non-open-source environments (eg how many open source projects are using something like http://riemann.io/ ?)
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.
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
Could help lower the number of GH issues that are filed because people don't read said docs...
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.
You could just leave it up to somebody else to solve, but if you've got viable ideas, give it a shot.
Your suggestions seem like a win win for Github and the hardworking OSS maintainers.
Maybe if it was an optional and project-oriented patreon-style?
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!
The thing about open source projects is, they tend to be slightly generic things like "file format," "widget library," or "machine learning algorithm" that most companies see as the kind of thing they can typically get for free from open source. (They're not wrong there - the fact that we're talking about my open source contributions here makes it almost tautological.) They also tend to involve the sorts of generic programming skills that, by virtue of being stuff that we all know at least somewhat well, aren't all that valuable. Supply and demand works with job skills, too.
By contrast, my commercial work tends to involve a lot of specialized knowledge that's quite uncommon, and also tends to produce the kinds of software that people are quite happy to pay a lot of money for.
Counterpoint - I have. Many times.
I created some Perl libraries (most notable <a href="https://metacpan.org/dist/DateTime">DateTime</a> and <a href="https://metacpan.org/dist/Log-Dispatch">Log-Dispatch</a>) that were used by a huge percentage of companies using Perl for applications (as opposed to simple scripts or sysadmin). This often came up in interviews, and I'm sure it helped me get more and better offers.
Nowadays, as fewer companies are using Perl for applications, it's probably less helpful, but it doesn't hurt.
But, anyway, yeah - I think that this was different 20 years ago, back when open source hadn't quite completely disrupted the software industry and companies didn't yet understand the economics of open source.
I'll never say OSS is an optimal career path unless you are doing something extremely specialized (which to be fair, he is). But it sure can open doors for you even today if that's something you're passionate in. For me, I got around without any OSS, so it's more like a post-career plan now to help out some beloved repos.
(as long as you're not stupid, like showing your botting repository to an online game studio).
There was a company I know of that was advertising in their job postings that the guy that wrote Perl's DBI once worked for them or was their CTO or whatever. That was about 6 years ago, so not that far off.
It's not valuable in terms of potential to market/usefulness/popularity, rather, because I can see very clearly how a person designs/writes code, and how they solve problems, when they have plenty of time; I can also see other non-technical aspects, like how they structure their git history (which, to me, has lot of signals).
People (rightfully) dislikes to show their capacity under pressure; open source is the way to show it without pressure :)
They gave a crap about mine, I believe for two reasons: first, I put it in the middle of my CV, at the same level as my regular job. This basically forces everyone to talk about it. Second, Monocypher is a crypto library, and cryptography tends impress people.
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.
FAANG does hire OSS devs, but a lot of them don't really do that much apart from being excellent politicians. To be fair, they don't get any time for OSS development in the first place.
However, they do have time for politics and often ruin the projects. People play along because they want to get hired at GNAAF.
As a result, these projects combine the worst of corporate and OSS development (horrible atmosphere and yet no money for development).
MAAAF for Mafia of MAGAF (Make Google Great Again, F...) are nicer.
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.
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.
> "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.
In the famous words of Peter Griffin, "OH MY GOD WHO THE [expletive] CARES?!!"
If someone isn't being paid for their work, then any version of OSS isn't really sustainable long term.
The definitions of these terms have existed for decades. Trying to confuse or conflate them is just a slight of hand to generally disingenuous ends. Very little stops people from selling products under whatever terms they want. If they are honest, they can call their product what it is: proprietary. Otherwise it is just using the term 'open' to virtue signal. So 'open' becomes the new 'green'.
> If someone isn't being paid for their work, then any version of OSS isn't really sustainable long term.
Exactly my point.
FOSS (for the most part) can't achieve financial viability in the current economic system (along with several other things).
Electronics are integral to contemporary existence in most of the world.
Without full control over their tools, human beings cannot be free/autonomous.
this assumes humans want to be free/autonomous. modern society already hunts and provides power/water/shelter to most of the middle class and above populace. How many truly want that full control over their resources to begin with?
Which is both pretty rich coming from a guy who lived for free at a university while enjoying a million dollar grant but, more importantly, suggests that the view of the FSF on how a programmer should live, and the view of how programmers think they should live don't have a lot of overlap.
First time I've heard that on HN ever. This needs to be common knowledge so more people realize how valuable they really are.
At the end of the day, it boils down to a choice as to how you setlle the intellectual property rights which derive from your creative work. Either you restrict the use, sharing and altering of your work by others; or you give a limitless license and anyone is free to do whatever.
Putting your code out there for free redefines the relationship between you and the users of your code. And it does so at both sides at the same time. It's the latter part which usually tends to be forgotten.
As a developer, sharing your work under an open source license is not an obligation to provide premium support. Or any a support at all, for that matter. All you did was share your work, others are free to either pick it up and use it, or walk past and choose something else.
As a user, an open source license doesn't come with a warranty, nor does it imply that you are entitled to support from the maintainer. All you get from an open source license is the freedom to use, adapt and share the software under a similar license.
It means that maintainers of open source projects are well within their rights to say "No. I'm not going to do that." to whatever request you submit to them. Whether that's an issue queue or an e-mail.
When a maintainer receives a request to add a complex feature or fix a complex bug and the request starts with "We use your code at our business / company / organization..." then it's perfectly acceptable to reply with "I would love to. Please contact me at my e-mail address and I'll send you my offer." As a maintainer, open source still leaves you free to charge for any support people solicit with you. You're even free to differentiate between "this is what I'm willing to do in my spare time, this is what I'm willing to do for a price."
The big question, then, is: Why don't open source maintainers do this?
That's where the answer gets complex. For instance, the jump from side project to sustainable income is difficult. Not all projects would yield enough support / servicing work. And not all projects are interesting enough to turn into a full time job. Depending where you live, making a little extra income from a side project may even get taxed away, making it just not interesting to turn it into a side business.
So, why don't maintainers then just refuse largish questions if they can only work on a project in their spare time? I suppose that's the hard part: publish creative work means putting a part of yourself out there. When facing an audience, being able to take a step back from criticism and feedback is probably the hardest part to creative work. There's all sorts of rationalizations one makes to defend a perceived requirement or obligation to keep working on open source projects, even when it's to one's own detriment. Learning how to deal with that in a healthy manner takes time and experience.
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.
I think it might be time to upgrade GPL to the age of modern internet, and have licenses requiring that modification are actually PR-ed (or sent by mail or whatever) to the author.
Hell I'd even think that there could be licenses where you are required to use mainline for anything remotely looking like production, and you are not allowed to fork, you're only allowed to use as-is, and to contribute. This one would definitely not be considered FLOSS, but some components really would benefit from not having an infinite number of forks, like the Linux kernel.
I'm not sure they need an OSS project to succeed, or that they would do any differently than if they hadn't.
I once had the pleasure of encountering some street musicians that were very, very good. I bought their CD out of their suitcase. It remains one my favorite CDs. Pludo's "The Only Thing Certain Is The Future".
Sadly, they never made it.
The large majority of street musicians are worthy of a tip, but I'll pass on their CD.
P.S. It's a lot easier to make money as programmer than a musician. You don't have to be anywhere near the top 0.01% to have a good career.
In many of such places you will probably live better from tourist tips than trying to make it as programmer.
It starts by living on a country whose technology infrastructure makes it possible at all.
Then it follows on how much the tier 1 customers are willing to pay to their offshored devs, with the race to the bottom on the dollar per hour rate.
There is also the culture of the country, if programming is seen as a servant job only used as stepping stone for a real job, or if it is seen as master of universe Silicon Valley style.
Working as software developer is privilege, not seen through the same lens across the world.
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.
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.
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.
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.
¹=https://www.exactaudiocopy.de/en/wp-content/uploads/2007/03/...
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.
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."
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-...
Why? Disliking someone not giving you free money seems rude.
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.
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.
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.
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.
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.
Suddenly, even just relinquishing control can be a bad thing for the community.
Twenty years ago, they would have done that, but these days, someone would just write a replacement from scratch (quite possibly, proprietary), or everyone would abandon it, along with their own projects that depend on it.
Most open-source (and closed-source) APIs and SDKs are “Swiss Army knife” projects, with many functions that serve many purposes. Most API consumers use only a subset of the interface, so “rolling their own” is not that intimidating.
I think with all the security problems that we’re seeing, these days, we may be headed for some agency/consortium that validates dependencies (with all the myriad problems, therein).
We may be seeing more “semi-proprietary” stuff, soon.
Not necessarily a bad thing, as I think that anyone that makes money on software should probably pay for it.
As I have made my point before, if all I want is money I would spend my time working a paying job. But money is not everything isn't it?
But making things that other people depend on is an obligation; not just a vocation.
I liken writing an SDK/API/library to having children. Once they are there, they aren't really my "property" anymore, and I am under an obligation to maintain and support them, so I need to keep that in mind, when I publish them. I need to play the long game.
I've written a system that is used by thousands, around the world, and is the backbone infrastructure for a particular demographic. It is not hyperbole to say that lives depend on it. I worked on it for ten years, before transferring it.
The best thing that I ever did for that system was toss the keys to a new team, and walk away. Nowadays, I'm just the dorky old man that chips in his two cents' worth, from time to time.
I'm not particularly interested in getting into religious battles, which is fairly common in the [F]OSS community. I mostly code for the love of the craft. Delivering and supporting open-source projects helps me to have a purpose, but I also take my obligations quite seriously.
One of those obligations is to go to great lengths to deliver very high-quality software. I'm quite aware that it is not commercially feasible to write software that meets my personal Quality bar, so I give it away for free,
People have no idea that's it's mainly charity. And even then people demand, get angry, don't read any docs, etc, etc.
Bigtech sometimes helps by employing these guys. What is really needed is a service, which does the moderation and filtering. Kind of like oss communication management as a service. For example by github.
It also means supporting other people and stepping up. It’s so few and far that’ll pay value for value.
Outsourced moderation would probably end up something like Stack Overflow — useful things will be closed because non-subject-experts can't tell the difference between invalid questions and valid questions that look like invalid questions.
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.
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)
So whats wrong with allowing them to help with those parts?
But everyone is free to make shitty software, so have at it.
The answer to this is that getting partial help sometimes costs more time than getting no help at all.
One of them is the cost of communication. My sense is that the overall cost of communication scales in a manner that's more in line with the number of active contributors than it does with the actual volume of communication that they produce. Even the actual time spent communicating may not do so, but the kinds of communication - getting to know new people and new teams, negotiating different and potentially conflicting needs, stuff like that - tend to be more tiring than the communication you get in a stable team of people who have been working together for a while.
But, if you can't make a living doing it, then you probably aren't prepared to contribute more than a very small amount of your time. A large group of people doing that might have an outrageous communication cost relative to its productive output. With the brunt of that being born by the maintainer.
I would imagine that, if we could figure out a better way to enable maintainers to support themselves and their families while also working on their project full time, things might work out better. More time spent programming means less need to negotiate with and review contributions from others, and the work getting done more quickly because it's being done by the person who knows the code best, and the job being both less tiring and less thankless, and possibly leads to higher quality (by virtue of being more coherently designed) software in the long run.
I don't have experience with it, but it seems active and better than abandoning a project.
Good luck!
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.
Put that in the readme?
There's probably a better way of phrasing it than I had though -- a way that is less standoffish.
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.
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.
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.
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.
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.
Eg: "This project works but will not be maintained. Github issues & PRs will be ignored. If you want changes, fork the project. If your fork is being actively maintained, let me know and I'll link to your fork from this readme."
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.)
If there isn't, and anyone can write straight to the source, then good luck to anyone using that package because it's probably not very safe.
It would be useful if there was a checkbox "Actively Publicly Maintained" in forked repos that defaults to Off.
That way, on the forks page of a repo, if someone is offering an alternative, an "actively maintained" check mark (and perhaps a date) can be shown and it can bubble to the top of the "forks" list.
Many of forks are made for personal purposes, experiments, one offs to patch bugs, to keep an eye on a project, or other reasons.
I'm thinking of the opposite of "archive" -- a setting that means "I nominate myself to become the lead repo for the community to rally around should the community be interested.
On this repo, can you tell me which fork the community moved to for this dead project?
https://github.com/lightbody/browsermob-proxy/network/member...
It would be awesome if there was a way on github to say "give me the upstream with this repo cherry pick, this repo cherry pick". But that might be pretty difficult to implement.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I had no opportunity to do it so far, but what is wrong with simply banning such people and closing tickets (with note that this issue is closed for rude behavior, not WONTFIXed)?
I would certainly not feel forced to support them.
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.
I'm sure they lose a good amount of potential contributers that way. But the few newcomers that remain are highly motivated.
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.
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.
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.
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).
Nodejs is the new Java jar dependency hell.
Maybe package the entire project into a docker container so that people can download and run the pile of dependencies in one step.
It is not a nodejs specific problem, every software with dependencies has it. (some more, some less)
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).
It’s 2012 all over again: “churn makes things better! BTW, what should we be using this week?”
People still build 3 tier apps, and web farms. It’s eternal 1997.
* 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.
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.
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.
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.
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.
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.
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.
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 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.
also, tenuous conditions are inherent to that model - typically you have a couple people paying a few dollars and asking for the moon every other day, and you already said "yes"
doing that sort of thing solo is certainly not for everybody, the overlap of people good at producing software and good at customer management + PR is extremely slim
if you were only paid a few dollars, why would you say yes to it? I'm not suggesting that you accept any "donation" amount and agreeing to a blank cheque for features.
I'm saying you ask for some 20-30k per feature request that takes approx. 1 month of work. And if the requesters of such feature can't pay this, then cannot afford to request (basically i'm using a contractor rate above, but you substitute the level of pay you intend to make).
I myself had something like this in mind decades ago, thinking of providing a web/platform/service to barter such deals, but it never made it past the design stage before I was convinced it was a fool's errand - and that was even before I started doing contract work
I'd be interested to listen if you can provide detailed real-world examples of how do you see this working
In this bit:
> I'm saying you ask for some 20-30k per feature request that takes approx. 1 month of work. And if the requesters of such feature can't pay this, then cannot afford to request (basically i'm using a contractor rate above, but you substitute the level of pay you intend to make).
how do you envision this negotiation taking place? coders, let alone younger ones and/or OSS-attracted ones, typically suck at this, on the following levels:
1- all work takes "a bit of effort" to "a weekend hackathon" to "two weeks™" - both on the client end, as technical challenges are often invisible to the client, and on the proud coder end who tends to overpromise a lot (combination of overconfidence, wanting to "give the best deal", and other psychological factors)
2- people are used to dark patterns and seeing concrete figures puts off a lot of people and has a strong impact on the perception of projects - also, the internet is worldwide and in most of the world a moderate pay will be seen as greedy or astronomical
3- judgement on whether the work is done, or ongoing, or satisfactory - this will always lead to some friction, and most people don't want to deal with it; coders gravitate to jobs where this shit work is done by someone else, typically on lower emoluments, leaving the higher rate for himself (we're usually a "he" let's face it)
From these, 1 is (roughly) the inner challenge, 2 is the outer challenge and 3 is the structural challenge. Perhaps 3 is the strongest of the 3, as it essentially boils down to the business model competing with a more traditional, tried-and-tested company/employee paradigm. Since a good coder commands a good pay these days, the traditional model needs to suck a lot to a lot of people before the coder (let alone the project lead coder or the CTO/CEO coder) is better off outside of "the system"
perhaps I should finish up some write-up and then open a discussion, but who'd read it heh
long story short, these OSS-with-tips arrangements will remain in the hobby/side-gig range for most people, except if you hit gold somehow in a superstar economy; I don't see this changing in the foreseeable future
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.
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.
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 :)
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.
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 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.
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.
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.
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.
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.
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...
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.
Nobody says that one company has to support every project and google supports many open source projects.
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.
We just need UBI.
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.
in that sense ownership is relative, for better or worse
writing OSS will always make sense, for certain kinds of projects and perhaps without expecting much compensation fo it most of the time
And when they do, they give up many of those rights in the process. At the very least they give up any right to tell anyone else what they can or can't do with "their" code. The entire premise of FOSS is that software belongs to the community, not to authors. It is fundamentally collectivist, anti-ownership and anti-capitalist at its core, and only recognizes concepts like IP and copyright out of legal necessity.
>Now, this has changed, so there is no longer any point of writing OSS for free.
The only thing that's changed is that a new generation of open source developers have lost the plot now that software has become a billion dollar business and suddenly they want to get paid for work they voluntarily gave away for free. The point has never been compensation.
Again, if programmers want to get paid, they can use a proprietary license, or write code for a corporation and get a paycheck. Or get a second job. Otherwise the complaints from people who likely have never contributed so much as a dime or a single PR for any of the FOSS code they use, and who chose the FOSS path out of a belief in its moral superiority to the capitalist incentives of proprietary software, are starting to get tedious.
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.
If every download cost a tiny amount, could it add up to pay some maintainers full time?