Sorry everybody, I failed with you(github.com)
github.com
Sorry everybody, I failed with you
https://github.com/pedronauck/docz/issues/1634
356 comments
I agree. I've been working on a Go library for 8 years now that I'm sure is used by quite some people and companies, and I've been close to burnout and letting it go at least twice. I'm super happy when people just "Buy me a coffee"--not for the coffee but for the feedback you get that someone is using your project, so it's valuable for someone. I'm very grateful for that, even without financial support.
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.
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.
There are a lot of facets to open source contributions. One big facet is the whole itch-scratching thing. If you know longer itch, stop scratching. That's ok. Maybe when you stop scratching, it will start to itch again for you or for someone else. If nobody steps up, it just means it doesn't itch enough.
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.
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.
There's also libraries that are simple enough that they just work fine without constant updates. I have numerous libraries that I use that haven't had commits pushed for 2+ years. This is the other aspect: burnout is so rampant because it feels like it never stops and you can come up for air.
Burnout is made worse when you take on too many complex interactions and dependencies.
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.
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.
The irony is we demand constant updates, pushes, recent commits, and maintenance, yet we use OSes with libraries and tools that were written decades ago and see little to no updates at times. Some of us go happily along using a decade old version of zlibc, for example. But when it comes to that latest NPM dependency -- if it doesn't have a commit within the last six months, psh! must be abandonware.
This applies well for things like a java package where the itchy generally have the skills to scratch. I think of these things as having numerous benefits, namely saves your company/team time; most of the time, in this case I think boo-hoo if the person working tirelessly for no compensation stops doing that... Pay them or do it yourself. (I am currently doing-it-myself with an abandoned java package my team relies on.)
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".
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".
In such a case, maybe Wordpress themselves should extend some engineering capacity for maintaining popular OSS plugins for their ecosystem.
The hard part of OSS management is dealing with change requests. Something comes in and now it's on the maintainer to ensure that the new fix doesn't break anything existing, or the new feature doesn't collide with anything else that comes down the pipe later. It's not work that can be done by volunteers, it's something that can only be done by long-term maintainers.
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.
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.
Also it hurts all around to tell a hopeful contributor that their code isn't good enough.
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.
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.
Thanks for writing this; it matches an undescribed feeling that I've experienced for a few codebases.
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.
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.
That sounds good in theory but it doesn't compose.
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.
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 think GitHub should really have a way for users of your repository to somehow illustrate that they're using your project.
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.
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.
"stars", at least from my perspective, doesn't map to usage. I've stared plenty of projects I don't use. I like the latter two metrics - thank you for sharing!
Devil's advocate: no action short of landing your own project will prove that you use a library. I've donated to stuff like Godot (which I have yet to open myself) and Blender (which I only know the bare basics of; I haven't even tried the new UI overhaul) years back because they are projects I appreciate an open source alternative for these very complex problems.
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.
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.
One thing you may encounter is that a large company may be using it for many things internally, and that still shows up as just a handful of clones, because they have some central artifact caching service in place.
It would be nice to have a similar system to the language metric at the bottom of a repo, have something like a library metric that list what external libraries a project uses and feed those metrics back to the maintainers.
GitHub does show a dependency list in the sidebar for some projects.
Unfortunately, they don't have dependency plugins for a bunch of popular languages. Even languages with well-structured dependency tracking like Rust.
I am afraid that within GitHub I mostly use stars as a bookmark for projects I find interesting and may want to check out in the future.
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
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
>I am afraid that within GitHub I mostly use stars as a bookmark for projects I find interesting and may want to check out in the future.
Wouldn't it make more sense to use the "watch" button for this?
Wouldn't it make more sense to use the "watch" button for this?
The problem with stuff like stars or even lists of "who uses this" is that they need to be refreshed every so often. Just because someone used your project ten years ago, doesn't mean they're using it today. Maybe a list with a "latest update" date and gently asking and reminding people to update it each year if they're still using the project would help...
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/ ?)
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/ ?)
The social stars aspect of GitHub is what makes it toxic. I would support more visibility for open, not centralized initiatives like humans.txt and contribute.json (https://www.contributejson.org/).
In the Java world we have the Maven repository dependency aggregators like mvnrepository.com that accidentally serve as some kind of citeseer equivalent. I assume similar things exist for the package managers of other languages as well?
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?
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?
For javascript packages, npm lists which other packages which depend on any given package, and how many times a package was downloaded in the last week. That gives you a rough sense of usage, but it can also be super mysterious.
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.
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.
You can possibly find some users in Github: https://github.com/search?q=jumprope+filename%3Apackage.json...
Oh good idea! It looks like Github also tracks a project's dependancy tree explicitly, though those 3000 downloads per week remain a mystery:
https://github.com/josephg/jumprope/network/dependents
https://github.com/josephg/jumprope/network/dependents
I've heard that the vast majority of those downloads are from CI systems. It would be cool if GitHub could draw anonymous metrics from GitHub Actions and help with this mystery.
I really wish GitHub would invest more in the dependency graph, like allow you to sort by stars at least:
https://github.com/josephg/jumprope/network/dependents
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
Thanks, just like I expected. Hopefully every at least remotely modern dependency/package manager has some sort of citeseer equivalent in its ecosystem.
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)
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)
> I've been close to burnout and letting it go at least twice
Why don't you? That's how you get people to step up.
Why don't you? That's how you get people to step up.
Github allows any repo owner to adda donation button. That should be a more widespread practice.
> I think GitHub should really have a way for users of your repository to somehow illustrate that they're using your project
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 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.
What’s the library, out of curiosity?
I was recently shocked to discover that sindresorhus, one of the most prolific oss devs of all time (I think), only has around $14k/yr of app revenue. It sounded like he was saying that it was a majority of his income, so I pressed him how he could possibly live on it. He said he had GitHub sponsorships and open collective donations, and then mentioned he was living in a country with low expenses.
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.
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.
It seems that he isn't really trying to make more money. Maybe I'm misinterpreting his words from his site:
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.
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.
> there needs to be a way of getting paid
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.
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.
Fair enough - my complaint is a bit too compressed. The point here is that my experience at Intel led me to realize that corporate OSS users will take your library in secret and not even tell you - much less publicly acknowledge it, much less contribute or help support it. Obviously I'm not expecting to be paid extra while at Intel because folks are using a library.
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'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.
[deleted]
> You said you worked on the library at Intel. Doesn’t that qualify as getting paid for your work?
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.
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.
It was an Intel project. https://github.com/intel/hyperscan/
Need to justify the time spent on it to management.
Based on FOSS surveys I have seen, majority of OSS contributions are paid for that way. The off the clock for free contributions are smaller part of it all.
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.
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.
Not always. Might be a personal project.
I feel like Github and co could do a LOT more to help open source project maintainers and contributors rewarded.
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.
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.
Sounds like you've got some ideas. That's cool. Take a risk and try to run with some of your ideas. Maybe you can help them grow legs.
You could just leave it up to somebody else to solve, but if you've got viable ideas, give it a shot.
You could just leave it up to somebody else to solve, but if you've got viable ideas, give it a shot.
These are great ideas. You should shoot the higher ups an email and a link to the thread.
Your suggestions seem like a win win for Github and the hardworking OSS maintainers.
Your suggestions seem like a win win for Github and the hardworking OSS maintainers.
A counter-argument to these ideas is that because it's open source, I'd just fork whatever I wanted to use and re-host somewhere else.
Maybe if it was an optional and project-oriented patreon-style?
Maybe if it was an optional and project-oriented patreon-style?
Monetizing issues would be a great move.
I'm so sorry to hear that has happened to the team behind hyperscan. It's truly a fantastic library and has helped us speed up some of our regex heavy workloads write drastically. I even spent some time writing about hyperscan both internally (at $dayjob) and externally.
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-...
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-...
I've actively resisted open sourcing some things I've written at work - including stuff that I'm sure others would like - precisely because of fears that it would be a career-limiting move. For my employer, these libraries are only valuable to the extent that they help us build things for which we can charge money. An open source library would not be one of those things, but it would take time (and therefore company money) to maintain such a thing. So putting myself in a position to be maintaining open source software on company time has the potential to greatly reduce my value to the company.
I think getting your name and work out in the world with open source work is a career _advancing_ move.
I've honestly never been at a job interview where people gave a crap about my open source contributions. They're typically much more interested in hearing war stories from the closed source projects I've worked on.
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.
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.
> I've honestly never been at a job interview where people gave a crap about my open source contributions. They're typically much more interested in hearing war stories from the closed source projects I've worked on.
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.
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.
To be fair, that's like the guy that wrote moment-js or jQuery. I've worked at a number of Perl-based companies and every single one used DateTime (I'm a huge fan, btw). Something like that is going to be noticeable on a resume. Assuming they have some experience with Perl.
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.
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.
Ha. I had actually thought about mentioning that this situation seemed to be very different 20 years ago, but decided I had already done enough blathering.
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.
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 mean, I worked with someone who creates a very high profile OSS project, and I'm sure it's a big reason he got hired to where he is.
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).
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).
This still helped me as recently as 2017, so it's not like this stopped being true 20 years ago.
> I've honestly never been at a job interview where people gave a crap about my open source contributions.
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.
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.
I can't speak for other companies, but as a person involved in hiring, open source is very valuable to me.
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 :)
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 :)
[deleted]
A lone developer can not maintain more than one or two open source projects at a time. I know for me, if I don't see any traction at all in the community once I get a project to some sort of MVP state, I will lose interest and move on. My github has many dead 1.0 projects :)
Maybe an easy solution is to do the thing everybody seems to discourage: add a clause to your preferred OSS license, stating that usage of the code is subject to sending a mandatory thank-you email.
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.
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.
That's Postcardware!¹ :)
I remember using one, but I not exactly which one; it's not in the Wikipedia list.
¹=https://en.wikipedia.org/wiki/Postcardware#Postcardware
I remember using one, but I not exactly which one; it's not in the Wikipedia list.
¹=https://en.wikipedia.org/wiki/Postcardware#Postcardware
Found: it was (not anymore) Exact Audio Copy¹.
¹=https://www.exactaudiocopy.de/en/wp-content/uploads/2007/03/...
¹=https://www.exactaudiocopy.de/en/wp-content/uploads/2007/03/...
Or, if you can't give the dev some money, or a thank-you, fix it yourself. I think that's supposed to be the point of open source.
I'd really like GitHub to have the option of open sourcing your work but both being able to turn off pull request and be able to limit PRs and issues to trusted contributors. Open source / closed contribution on an individual level.
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.
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.
For a while Open Source was a great way to project skill onto employers, and employers reaped recruiting benefits for having a large open source portfolio. This extended to the point that companies would accept internal inefficiency to support an open source release of a portion of their code. This has detectably changed in the last 5 years or so as getting a top project on github has both become more difficult as well as a more common bragging right. Everybody has some open source, so the marginal benefit to a company of releasing another project is low.
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!
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!
Oh, that scenario, retreating corporate sponsor would probably not have retreated if only usage was more visible, that must have been very frustrating. Almost seems as if the odd occasional visibility boost from some heavy bug or exploit could have saved it. Were Oscar Wilde and PT Barnum secretly open source visionaries?
One thing I found immensely frustrating was that occasionally other projects at Intel (not mentioning names) would wind up completely fucking up by, say, building the wrong thing, then they would do some heroic 8-week "save" of the mess that they made, and wind up getting Major Corporate Recognitions.
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.
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.
Sorry to hear that, I was hoping that my "no such thing as bad publicity" musings were merely crazy what-ifs, not a reflection of your reality.
That has been my own experience too. The heroics to fix messes are given more recognition than a properly run projects. One company would actually give quarterly awards be those who did heroics.
Unwilligness to pay for developer tools or desktop software is what made me gave up and just focus on Apple, Google, and Microsoft platforms.
I rather work for ecosystems where customers see a value that developers keep their job.
I rather work for ecosystems where customers see a value that developers keep their job.
Andy Gocke put it best, on Twitter:
"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."
"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."
Yeah I love the quote, specially the irony wanted to be paid, while unwilling to pay the work of others.
I'm curious. Is there a reason to not build in some sort of ping for the software being used? Essentially doing analytics for open source usage so you can monitor how many people use it?
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.
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.
Surprise telemetry is deeply unethical. Putting it in the README is borderline OK, I guess. However, even supposing it's OK, a "single ping on use" is only really feasible if the system has "main()" and some reasonably persistent usage. If you're a small tool - or a library, like we were, "single ping on use" might result in thousands of systems "beaconing" back to home base per hour.
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.
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.
Generally apps that send telemetry get a lot of flak here. Even if mentioned in the docs/faq.
So true, it's really taken for granted. Especially these days with Github and package managers which make it so easy to end up incorporating a dozen or more 3rd party libraries. There's something impersonal about it, and trivializes the amount of sweat that was poured into the code you're npm installing.
[deleted]
Totally agree! That's why I want to help open source maintainers monetize the ecosystem they have built. The first step: Sell add-on products/plugins/tools with a super easy Checkout paywall: https://basetools.io
Feels like a great opportunity for Github or another website to have these sort of analytics. Seems like quite the complicated task tho. Start small?
Rather than centralizing on GitHub, this seems like something that could be well suited as a `.well-known` url websites/companies could use, then anyone/everyone could aggregate or just inspect what is being used.
You didn't have any way of knowing who was using your library? Any way of communicating with them? A survey even? Download numbers?
Once it's up on Github and out there, you don't really have any control. It's not like we were keen to put big barriers on the 'try it out' side. I didn't have some mad keen quest to be able to communicate to management "hey, someone from A----- or H----- downloaded our library". That's not that interesting. A lot of people kick the tires.
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.
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.
That's an interesting nuance I never considered.
I think Richard Stallman's cynicism about licenses was misplaced 30 years ago, but that the tide is turning.
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 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.
that's why telemetry is imporant
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
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
SaaS or something explicitly that people know will 'phone home' is one thing, but putting unexpected telemetry into a library would be staggeringly unprofessional.
Not really, there is a lot of projects doing this as an anonymous statistic, for example InfluxDB sends anonymous statistics about your InfluxDB instance to their server. This way they have overview/statistic of usage (they are visualize it on word map, looks amazing), together with data like OS, version you use etc...
You can disable this in config
https://influxdbcom.readthedocs.io/en/latest/content/docs/v0...
Frankly, there could be some value to OSS contributors in saying 'There is Telemetry' very up front, but also in the same breath telling people that instructions for disabling Telemetry is in the Docs.
Could help lower the number of GH issues that are filed because people don't read said docs...
Could help lower the number of GH issues that are filed because people don't read said docs...
[deleted]
I've long believed "open source" is for suckers for exactly this reason. Literally being open source, having the code open for review, isn't a problem. But usually "Open Source" also ends up meaning free as in beer, for EVERYONE, whether you're some college student or a billion dollar company.
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.
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.
> "open source" is for suckers
First time I've heard that on HN ever. This needs to be common knowledge so more people realize how valuable they really are.
First time I've heard that on HN ever. This needs to be common knowledge so more people realize how valuable they really are.
"Opens source" isn't a business model.
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.
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.
A lot of open source developers leverage their contributions into high paying jobs they never could have gotten otherwise.
I don't doubt it could help but these are pretty talented people in the first place.
I'm not sure they need an OSS project to succeed, or that they would do any differently than if they hadn't.
I'm not sure they need an OSS project to succeed, or that they would do any differently than if they hadn't.
OSS is a shortcut to career advancement if your resume is not the best. I know people who have done very, very well via contributing to Open Source.
Just like a couple of street musicians happen to hit gold, the large majority doesn't.
The implication is that the OSS contributor has to be good. The same with street musicians.
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.
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.
Only if living in tier 1 countries, I can assure you there are countries where both professions have equal chances of success, and probably the musicians get the upper hand on opportunities.
In many of such places you will probably live better from tourist tips than trying to make it as programmer.
In many of such places you will probably live better from tourist tips than trying to make it as programmer.
That's no longer true in these days of working remotely.
To work remotely, there are certain requirements on the life pyramid that need to be fulfilled.
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.
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.
> 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.
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.
> "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.
> This is neither free nor open by either the OSI or the FSF's definitions.
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.
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.
> In the famous words of Peter Griffin, "OH MY GOD WHO THE [expletive] CARES?!!"
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.
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.
>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?
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?
Yes, in general humans often do everything they can to escape from freedom. Or, as the serpent said to Eve: "Here's Looking at You, Kid."
you force goodwill onto humans and you push them to the serpent even faster. The whole topic here is based on making people do more work for less rewards, after all. More work billionaires benefit most from.
To double-down on that, rms noted that he doesn't think that developers "should be able to eat sushi every day".
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.
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.
I like this idea! Free for small and paid for medium/big. I think the real wisdom lies in taking the middle path (mostly). I recently read how babel, a project used by millions, struggled to keep few full-time developers. It was heart-breaking. Great developers gets glued to the idea of open-for-all at the cost of practicality. It's kind of like how people say "follow your passion" but realistically this approach only works for a a very tiny percentage and rest just struggle to pay their bills.
But I am sure some projects out there must have taken this middle path. It would be interesting to know how it worked out for them.
GPL is also a possible alternative. Big companies pay you back by contributing to the project, insofar as it is worth it to them to maintain a fork and add features for their own use.
Sadly, GPL doesn't give you that. It only gives users the modified source code. No history, no time of fork. And nothing to the developer.
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 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.
This unfortunately worked much better before it was feasible to hide everything behind a server, having no releases so to speak at all
Is this not the purpose of AGPL?
The purpose of AGPL is to have a bunch of people harass you about you daring to have the temerity of not letting them run their business on your code for free.
But isn’t it cathartic when you tell those people to fuck off?
I've never liked that approach, it's leading with the stick and not the carrot and IMO it defeats the purpose of open source. It cuts away one of the main benefits of open source -- that companies can use it and start contributing back to it right away with no friction. AFAIK Microsoft, Amazon and Google actually DO hire a lot of open source maintainers at this time, for exactly this reason.
Companies rarely contribute back except for very few projects like gcc and LLVM.
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).
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).
A bit off topic, but instead of FAANG (Facebook, Apple, Amazon, Netflix, Google) I much more prefer the MAAAF or FAAAM acronym (Facebook, Apple, Alphabet, Amazon, Microsoft) because their monopolies basically make them a mafia family, and I don't really see Netflix belonging in the group.
Not just politics, but often they'll couple OSS to their own build systems and stuff. Yeah, it might be 50ms faster on paper, but that whole project now depends on that company's OSS licensing allowing that dependency to exist publicly. That's some really scary power.
That seems to be a mostly orthogonal concern -- you're talking about a general issue of "doing business with big corporations" and not really something I would say is specific to any given project. One way to help improve the situation would be to help them win those battles so they can negotiate for more time to upstream useful things.
The problem isn't the software but the discussion around it. With discussions, issues, feature requests etc you can be a contributor or you can be a user (beneficiary). There should be a possibility to distinguish between both and require compensation from beneficiaries.
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.
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.
"Sharing stuff you want to share with other people is for suckers"
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.
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.
pg has a good article on doing things that don't scale[0] and showed how the AirBnB guys went and setup the first listings manually, but it's actually far more general than just kicking off the network effect. Moats are things that don't scale. Open Source software scales perfectly. Billion dollar companies are billion dollar companies because they can use Open Source software wrapped around some Moat-able structure. The more Open Source Software that exists, the bigger the garden.
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.
[0]:http://paulgraham.com/ds.html
[1]:https://en.wikipedia.org/wiki/Incentive_compatibility
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.
[0]:http://paulgraham.com/ds.html
[1]:https://en.wikipedia.org/wiki/Incentive_compatibility
> Much as I dislike those wacky "free for non-commercial use, otherwise, give me a call" licenses,
Why? Disliking someone not giving you free money seems rude.
Why? Disliking someone not giving you free money seems rude.
Well your comment is meaningful but you could still have recorded the total number of downloads and the monthly number in order to answer how popular is the library.
As somebody with experience in developing many OSS projects of different sizes (Redis, Hping, Jim Tcl, Visitors web analyzer, and many additional smaller ones), I think that the solution is simpler than it appears: just do what you want. When you are inside the flames of a successful open source project, you may think that the solution space is binary: don't do anything, or do everything people are demanding from you. Instead you can just keep doing what you want, cherry picking what issues you want to address, reply to, what features you want to add, and so forth. Just give you a fixed amount of time to spend on the project (in my case most of the time it was "all the time I've in a day, but up to 6/8 max", but it can be even just 10 minutes every day), and in this time do the things you like to do and ignore all the others. A few issues/PRs will be perfectly aligned to what you feel is right and you'll enjoy taking care of them. Others will not, and who cares?
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.
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.
Over the last year I've been very explicit about this in issues and such that people report (especially feature requests, but also bugs I don't really care about): "Thanks! Sounds good; keep in mind this is a spare time project I wrote for my own reasons, I'm happy working to solve other people's problems too if it improves the project, but I work on it when I feel like it, which may be next week, next year, or never. In the meanwhile, I'm happy to review and merge patches".
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.
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.
This is great advice and it's what I've done with my open source projects as well. The point of open source is that it's just that: it's open and free. People can try demanding things from you, but you don't work for them. So they can fork it and make changes or get lost.
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 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.
At my last gig I got budget to bring in the maintainer of an open-source testing library we using for some really important stuff.
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
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
Wow, that never occurred to me, that’s a win-win situation for everyone involved! The maintainer gets recognition and payment for his work, the company learns and has its questions answered. I’ll keep that in mind in my future projects, thanks.
This is exactly how it's done. People are willing to pay for modifications and consulting. The only danger here is turning into Oracle where little effort is put towards usability in order to protect your consulting revenue stream. Just build great tools and libraries and people will come to you for help.
About a decade ago, Gabriel Weinberg of DuckDuckGo fame set up fosstithe.org, which was about encouraging companies to set aside some percentage of your profit to donate to FOSS projects. Alas, the website no longer seems to exist. I still think it's a great idea, and every year I donate 5% of my profits to FOSS projects I like.
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.
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.
Not every FOSS developer has a consulting gig.
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 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.
It's probably not that clear cut. Maybe they have a full time job. Maybe their employer has An Opinion regarding side gigs. Maybe they live somewhere where a side gig comes with a lot of paperwork/taxes so it isn't worth the hassle.
There's probably some price where it's worth the hassle. I feel like every OSS project starter should have at least a firm notion of where that line is before they publish. On one hand, maybe you'll get it, but mostly it helps clarify what your time is worth so that you don't feel guilty about rejecting requests on your time that don't meet your own standards for value.
Of course it's terrible to become burnt out and it feels awful not having enough time to work on an open source project that you love.
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.
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.
Often a project, a club, or even a company only hold because of one passionate individual. Once he is gone, it is the end. It is very hard to find someone with the same level of motivation. Projects stop being maintained, clubs cease activities, and companies get taken over for short term profit.
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.
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.
I don't know how the idea that people are replaceable got so popular. Yeah, I know why some people tried to make it so, but it's so blatantly false that I don't understand how those people were successful.
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.
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.
There is an interesting "converse" to this observation for open-source projects, though. Namely: if a nontrivial abandoned project is still widely used, it probably represents a major career opportunity for anyone willing to take over maintenance.
This isn't purely hypothetical: it's the foundation of my own career.
This isn't purely hypothetical: it's the foundation of my own career.
To maintain something you will need a match between what type of person is needed and what type of person is available. To start something, any type (well, very simply put) of person will do, often the need emerges from what they initiate.
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.
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 maintain two slightly popular open source apps, and my experience is that there are a lot of people interested in using your product, but very few people interested in contributing to it.
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'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)
Have you considered adding your project to a site like https://www.codeshelter.co/ ?
I don't have experience with it, but it seems active and better than abandoning a project.
Good luck!
I don't have experience with it, but it seems active and better than abandoning a project.
Good luck!
> 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.
So whats wrong with allowing them to help with those parts?
So whats wrong with allowing them to help with those parts?
Allowing people to help also takes time...there's a non-trivial management effort involved...one that's too frequently forgotten about in these discussions.
This is very true. Even when collaborating with very skilled engineers, it takes a lot of time and energy to respond to ideas, questions, and review PRs. It’s like a regular programming job to a certain degree, but you’re typically not paid for doing it.
Software can be shitty garbage in many ways. It can be shitty garbage by having lots of bugs, and it can be shitty garbage by having a maintainer which cares more about bottlenecking all changes than about the future of a project.
But everyone is free to make shitty software, so have at it.
But everyone is free to make shitty software, so have at it.
Wow, calling people's software shitty because they care enough about it to want to vet contributions?
I don't know why you're being downvoted for a truly honest question.
The answer to this is that getting partial help sometimes costs more time than getting no help at all.
The answer to this is that getting partial help sometimes costs more time than getting no help at all.
This seems like one of the potential tragedies of the "all volunteer" development model. Many of the factors that play into Brooks's Law apply just as much to volunteer efforts as they do to commercial efforts.
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.
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.
[deleted]
"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'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.
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.
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.)
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.)
There are endless examples of forks that pick up where some other project left off. They give it a new name, explain what's going on, and move on. If it's seen as hostile, that means the original project is still active and doesn't need this?
This has happened with some pretty big names, too. gcc did this, and so did Jenkins. Didn't node.js do this a few years ago, too?
This is a serious shortcoming in github's current UI. There's no easy discovery for which forks are active.
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.
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.
Even just finding out which forks have any changes compared to the main repo is difficult on GitHub.
There is a graph showing the fork activity. Also, the setting you are thinking if is probably “archive”.
A fork having activity doesn't imply it is a publicly maintained fork that people can rally around.
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...
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...
All valid points. I do miss some sort of guidance every now and then on some repos. The most difficult bit starts when multiple forks have different features one wants to have in their own fork.
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.
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's version control other that Git / GitHub / etc. It's even possible to forego version control and just release tarballs somewhere.
Ok, but you'd hope there's some form of access control that stops someone just overwriting the canonical source with their own version. That's the same as the maintainer having to accept changes.
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.
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.
Or you maintain your own version. My projects got booted of GitHub when I did; I don't maintain a site anymore; but there's several forked versions of them floating out there somewhere, presumably because someone's still using them.
There’s a community aspect to consider though. You and I could both decide to continue some open-source project. The community will (reasonably and maybe even “rightly”) look to the original maintainer for guidance on which 0, 1, or 2 forks they suggest to continue.
It's even worse with other patterns, e.g. when the original project is suffering from some bit rot, the maintainer is unresponsive for months, independent forks spring up to fix that rot and suddenly you get a bout of activity in the original project and then another lengthy period of silence.
Yep. I think its important for project maintainers to be clear about the maintenance status of a project. You don't have to maintain a project forever, but if its not maintained its good to be clear about that.
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."
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."
This is truly frustrating, and happens in organizations as well. It is admirable when people actually make decisions.
Sure, one thing (it being OK to drop an already open source project) doesn't exclude the other (suggesting a fork if there happen to be any).
In my opinion, there's just a shortage of experienced engineers.
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.
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.
As greybeard, I see the golden age of FOSS like disco/hippie days, eventually the majority that was against the man ended up working at wall street like jobs during the 80's and early 90s.
Same will happen when everyone that actually made BSD and GNU happen is no longer around, it will be business as usual.
Same will happen when everyone that actually made BSD and GNU happen is no longer around, it will be business as usual.
I think part of the worry of handing projects over stems from a couple of fairly high-profile events when projects were handed over to theoretically trust-worthy people who went rogue and used them as a platform for malware or spear phishing.
Suddenly, even just relinquishing control can be a bad thing for the community.
Suddenly, even just relinquishing control can be a bad thing for the community.
What's really required is to build a community large enough that the 0.1% of people who can run it are big enough to have a group in charge, set up a foundation etc etc. It's just like going from a monarchy to a democracy, hard, takes ages, fails a lot.
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.
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.
The thing is, if the new project maintainers go against the community, but the community really need to use it, the community will just fork out a new path and move on. If the project is really open source.
Nobody forks anymore. Almost nobody contributes anymore.
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.
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.
Something like the patreon thing for sure which also means community outreach and engagement.
It also means supporting other people and stepping up. It’s so few and far that’ll pay value for value.
It also means supporting other people and stepping up. It’s so few and far that’ll pay value for value.
I think that was always the case — the majority of people don't contribute meaningfully, and was quite demanding. I had an old open source project that got a few users, and eventually too many support requests for me to handle. Somebody stepped up and helped maintain things until I lost interest, but that was a very tiny fraction of the people involved. I was lucky there and (as far as I know) they never went rouge.
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.
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.
I don’t think that really happens, anymore.
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.
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.
I think we are straying from the point of FOSS once we talk about money. If I start a new open source project, it will be my gift to the world, and I expect to gain nothing from it financially. If Google make a billion bucks from my project then I'm sure some other dudes running a startup is using it too, and if my project helps them then I'm happy. If my help is not appreciated, lotsa luck gentlemen ;)
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?
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?
Preaching to the choir, here. Take a gander at my work.
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,
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,
Also to refute your point here, I would say that there's not really that many project maintainers that just totally go rogue and kill the whole project. An event that was most similar to what I describe here is the Freenode boogaloo, and you can see that users started to move to Libera.Chat. If you advertise your product as community oriented and do stuff that your community despises then you basically have just shoot yourself in the foot.
TBH, I'm not exactly sure how that "refutes my point." I apologize for mentioning money. I think that may have raised some hackles.
I'm not sure if it's "become" rare or rarer. But in a way Github, npm, or maybe it was just ourselves in general... but we seem to have promoted the idea of "build it and they will come" to an unrealistic level.
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.
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.
I think with the modern internet, and GitHub, it's much harder. It used to be reasonable to make a release every year or so, and basically not be in communication other than that. You could also assume all your dependencies would release updates every year. Now people expect replies to their GitHub issues within a few days, if you have CI you were probably using Travis and had to update everything, etc.
I believe that GitHub problem is that people not into software development are pushing those actually developing at a very low developer/user ratio, it always feels like a never ending task and people won't ever stop asking features as they got used to see Corp projects next to project garages in the same service?
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.
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.
It's actually very hard to find help on an open source project. People are fine with submitting the odd PR here and there or reporting issues, but actually RUNNING a project, in whole or in part, is a serious commitment that few people will find the energy to stick with.
> 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?
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.
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.
This is partially why over the last few years I've been moving away from using smaller packages in favor of rolling my own. Big things like frameworks are generally safe bets, they generally are able to build a community around them pretty easily. But smaller libraries are often not worth the long-term risk.
> 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?
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.
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.
Is this just a function of how long it takes to recreate ~80% of the functionality?
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.
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.
> there is nothing wrong with putting out a call for someone to take over maintainership
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.
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.
> But, is it just me or has it become rarer for open source project maintainers to feel free to let projects go?
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.
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.
A temporary BDFL... Would that be called a TBD (temporary benevolent dictator)? :)
BDFN: benevolent dictator for now
when I started work on ts-loader I went with "caretaker" https://blog.johnnyreilly.com/2016/11/01/but-you-cant-die-i-...
Benevolent Regent Lord
Benevolent Dictator Pro Tempore
Davidism took on Flask/Pallets really well, I think.
> But, is it just me or has it become rarer for open source project maintainers to feel free to let projects go?
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.
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.
In an ideal world you're right. But most people don't create projects expecting -- or even wanting -- huge success.
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.
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.
> 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".
Put that in the readme?
Put that in the readme?
Pragmatically I think you're right that developers should put that but it feels like such a hostile comment to make that I certainly wouldn't feel comfortable publishing it.
There's probably a better way of phrasing it than I had though -- a way that is less standoffish.
There's probably a better way of phrasing it than I had though -- a way that is less standoffish.
I maintain OS projects and my stance is simple: I'll fix thing, that are broken - mostly because I want things to work. I won't add new features for you, unless I really see the appeal. If you come up with a PR, nice! I'll take the time to review, but even for that there is no guarantee.
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.
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 don’t know why paying for someone’s time and effort is a bad thing. If anything, undervalued/unpaid labor seems a little dystopian, especially when some large companies are getting value out of someone’s volunteer work without giving anything back.
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.
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.
>I'll fix things that are broken - mostly because I want things to work. I won't add new features for you, unless I really see the appeal. If you come up with a PR, nice! I'll take the time to review, but even for that there is no guarantee.
To some this may sound like it ruins the spirit of open-sourc but I totally support this. I should make this quote my default readme.
Even PRs often take a long time to review and get to a reasonable point, especially but not only from new contributors. Some are so bad I just have to close them even if I want the feature, and some I waste hours on that I could have spent just writing it myself. Rarely I get PRs that I can merge without non-nitpick reviews.
> 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.
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.
[1]: https://ando.life/journal/the-useless-tree
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.
[1]: https://ando.life/journal/the-useless-tree
This is kind of sad to read, that someone building and maintaining a free product feels compelled to over apologize for want burning out.
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.
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.
> 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 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.
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.
This has probably something to do with big tech companies putting out highly polished products for "free" while making money in no-so-obvious ways. People have been conditioned to expect high quality work for free.
Excellent point - and people forget the side benefits of those “free” projects are raking millions into the company.
I feel sympathy for the maintainer here, but at the same time I feel as though they've cultivated a very unhealthy relationship with the users of this project. If the users aren't paying you, you really don't owe them anything and you certainly don't need to apologise for prioritizing your own mental health and happiness over users' demands.
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.
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.
This may be an obvious point but how can you say you failed when due to the fact that it's open source, anybody could check out the code and start supporting it?
How about the insane entitlement that many devs have when it comes to open source? Getting bombarded with requests and angry emails from people who demand free support and bug fixes can burn anyone out.
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.
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.
I wonder if this is a back-firing of the push for people to be "nice" and "professional".
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.
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.
Agree. I'm active in some communities that are unfriendly if not outright hostile towards newcomers.
I'm sure they lose a good amount of potential contributers that way. But the few newcomers that remain are highly motivated.
I'm sure they lose a good amount of potential contributers that way. But the few newcomers that remain are highly motivated.
Now that I think of it, that's also my experience. If I really need a project to do whatever (and can't implement the feature myself), I shut up, let the horrible attitude wash over me and put hours of effort into testing and providing helpful information, and maintainers usually mellow out eventually. If I hadn't done all of that work, the maintainer would have had to do it. Sure, they're much better equipped to do it and can probably do it in a quarter of the time it takes me, but multiplied by fifty tickets... Oof.
In the 1990s, the perl and python communities both had to cope with an endless stream of novice confusion. One grew community norms which included recreational disparagement. The other, in part in reaction, was explicit and firm: if you can't be polite and professional just now, your contribution to the community can wait. The contrast between the two cultures was very dramatic.
Nice professional people have large backlogs ignored for years, say no to requests or delay work. Otherwise said, being nice and professional does not imply you will immediately implement every feature request or bug report. It does not imply you will not block/mute abusive people.
Being nice and professional just means smiling as you get a dumb request and being open about your intent to prioritize the request alongside everything else.
You can be harsh in a nice and professional way though.
I can't second this enough, and it's the other side of that whole "put your code on Github and use it as a resume". If I'm looking to hire someone, and I look at their Github repository and it's full of nasty, unprofessional responses to PRs and such, it's a pretty safe bet I don't need that attitude on my team.
[deleted]
I don't think some UI tweaks are going to fix this sense of entitlement.
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.
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.
This! Several of my github repos now have a disclaimer that says "if this doesn't work, don't send me insulting emails"
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.
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.
> So then you're forced to do open source support for entitled aholes
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.
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.
Agreed, I would never write such a message. I have zero responsibility toward the users of my open source code, and my license does reflect that fact, unless they pay me.
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.
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.
What bugged me the most was how unwilling users were to dive into code to make small edits. They’d rather spend 3X the time filing issues, writing emails, and tweeting about it. And if you tell them, “maybe you should just not use this,” then you’re seen as unreasonable.
The entitlement drove me out. The market is more about chasing shiny things than using things that are the best fit.
The entitlement drove me out. The market is more about chasing shiny things than using things that are the best fit.
It's a common thing that a person imagines that he's responsible for something, can't keep up with it and finally feels himself failed, despite the fact that he wasn't really responsible in the first place. But it's still a source of misery and disappointment. I guess, it takes some time to understand what's the real responsibilities are and what's the imaginary responsibilities are. I agree that putting some code public with open source license does not bind author to any kind of responsibility and any continued work from him is just a charity to the world which he can stop providing at any time. If someone needs more guarantees, he can pay author or any other person (if code is open source) to provide those guarantees.
Most projects life because of huge support of few people. Pareto principle: 20% doing 80% of the work. And in my opinion on the most projects doing less then 10% more than 90% of the work.
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 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.
Humility and a strong sense of responsibility.
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.
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.
[deleted]
> ...People want a lot of things from you and your project, big companies are using the project and need a lot of things as well from it in order to keep their projects healthy, but in most of the cases this is a talk in just one way. There are more people interest in have things from you, than help! And this crashed me
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.
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.
We don't know how much pay/sponsorship was the issue here. It seems to me that the maintainer was simply overworked and slept very, very little.
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.
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.
True, burnout is inevitable with a single developer. That's why paid support or sponsorship is used to hire more developers / contributors to reduce the risk of the project stagnating due to one developer burning out.
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.
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.
> overworked and slept very, very little
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.
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.
and of course: it's javascript! because literally every other community would have no problem if their doc-generator got unmaintained, because it would probably run for another ten years...
There’s also a defective culture meme that believes software that hasn’t been updated in the past week is dying.
This is a conceptual hack to avoid considering the state of the ecosystem.
This is a conceptual hack to avoid considering the state of the ecosystem.
I think GP is trying to imply that there's so much churn in the Javascript ecosystem that any project which isn't updated will actually stop working in a relatively short amount of time.
Pretty sure "Hello World" develops a major security vulnerability in a dependency you didn't know about if you go two weeks without looking at it.
It's been a big adjustment to me switching all my recreational programming over to Common Lisp. In the CL community, it's not uncommon for a widely used library to not have been updated in 5-10 years. In any other language community, that would mean unmaintained, bitrotted, unusable. In the CL community, it usually means it's finished, and doesn't need any more changes.
It's not a defective culture meme, because the modern ecosystem is moving fast. We're using to thinking about digital creations as if they're forever. This is incorrect. Software without a platform doesn't run. Platforms are always changing, and sometimes platforms die and get replaced with other ones.
Think of software like a living being, not like a statue etched in stone (although even statues etched in stone degrade).
Think of software like a living being, not like a statue etched in stone (although even statues etched in stone degrade).
You could almost say it was a Cambrian explosion of sorts?
It’s 2012 all over again: “churn makes things better! BTW, what should we be using this week?”
It’s 2012 all over again: “churn makes things better! BTW, what should we be using this week?”
I’d say it’s forever 1997. Netscape had a server side JavaScript platform in 1997.
People still build 3 tier apps, and web farms. It’s eternal 1997.
People still build 3 tier apps, and web farms. It’s eternal 1997.
3 tiers are older than computers. As for JS, most things that becomes popular have been around for decades, but without being popular. Society is slow as f**.
There's really something to be said for software that is so ruthlessly simple it runs forever without maintenance. Like most of what DJB has written: djbdns still works after all these years... And of course Knuth's TeX.
Maybe people shouldn't start software projects if there isn't a "can leave it here unmaintained" milestone within sight.
Maybe people shouldn't start software projects if there isn't a "can leave it here unmaintained" milestone within sight.
> 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).
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).
I think you just said exactly what the parent comment meant.
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.
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.
`entire project into a docker container `, like Linux Flatpak.
It is not a nodejs specific problem, every software with dependencies has it. (some more, some less)
It is not a nodejs specific problem, every software with dependencies has it. (some more, some less)
The pattern is familiar:
* 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.
* 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.
This is an Anti-Pattern in OSS. Start a project to build something you want/need. Update it as you want/need more things, but don't build other people's businesses for them.
> build something you want/need ... don't build other people's businesses for them.
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.
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.
Add to the pattern:
* Write to high profile companies that use your OSS work asking them to contribute. * Get a very polite and convoluted "no" in response.
* Write to high profile companies that use your OSS work asking them to contribute. * Get a very polite and convoluted "no" in response.
I'm exactly the same - I choose not to open source things because it's more hassle than it's worth.
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.
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 think it's worth noting that it doesn't seem like the author here sees it quite the same way as you do. Burnout is obviously bad, but it also seems to me that he genuinely enjoys writing open source software, so I guess that enjoyment (plus some "opportunities" he got) is the gain.
This is quite similar situation when many idealist engineers grow, often unwillingly, into politics, management or C*O level - someday the coding fun ends and the not so fun business work takes over.
You don't have to do OS, you can if you want.
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.
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.
If your primary motivation is short-term monetary gain then you're right, it doesn't sound like a rational undertaking.
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.
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.
Also, some of the best software could be stuff that nobody can actually afford.
> I'd only do it if it paid money. If people aren't willing to pay then I'm not willing to work.
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.
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.
> Would a form of UBI, together with 20 or 30 hours work week work for you?
Every developer is different, but ideally they would do it full time if it pays significantly more than their current job.
Every developer is different, but ideally they would do it full time if it pays significantly more than their current job.
Yep, I've stopped owning Open Source projects. All projects are for me now, and I reap the minuscule rewards from being all the only benefactor of the effort. But at least it's not a net negative burden of time sink, support, server costs, hosting, burnout, etc.
What’s really sad about this (and other open source devs with pressure from users) is the lack of support _from the users_.
Open source should be about being able to dive in and add the wishlist item you have. A lot of people put up this wall that only changes can be made by the author, proliferating this onslaught of requests from the user and in the end burning out the author.
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.
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.
I was surprised that nobody mentioned the Collective Code Construction Contract of zeromq/Pieter Hintjens [1]. It tries to minimise the friction created by maintaining & contributing to open source projects.
It is not perfect of course, but at least it is a good start. Especially the "value-" & opinion-based discussions can be reduced considerably.
[1]: https://rfc.zeromq.org/spec/42/
It is not perfect of course, but at least it is a good start. Especially the "value-" & opinion-based discussions can be reduced considerably.
[1]: https://rfc.zeromq.org/spec/42/
At this point, I tend to view open source software not as free as in beer, or free as in speech, but free as in mattress left on the side of the road with a "Free" sign.
Expect nothing, and you can only be positively surprised.
Expect nothing, and you can only be positively surprised.
Has anyone ever modded Bethesda games? And by modding I don't mean "downloading plugins" but making those plugins and doing game development for free?
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.
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 don't say for this project but if you own a popular open-source project which is used by many companies it does make sense to think off it as your main business sometimes. I mean not just donate to me or follow me on patreon business, an actual business business.
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)
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)
monetising OSS is not as trivial as starting all these extra fronts and just hope it somehow pays off, people need to survive in the meantime
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
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
> very main selling point is that it's simple enough you don't need support
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.
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.
one-off changes don't make for a revenue stream, you'll find that people are prepared to ask for features a lot more often than they'd pay for them
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
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
> you already said "yes"
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).
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).
there are very strong cultural factors preventing such billing model from catching up, on either side of the deal
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 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 started appreciating single duty snippets of code instead of creating large abstractions that tie together multiple snippets of code that all work together. I do this to set myself up for success. (Think of it as making the rungs on a ladder closer together).
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.
[0] https://bubble.io/blog/no-code-manifesto/
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.
[0] https://bubble.io/blog/no-code-manifesto/
I maintain a wordpress plugin that is actively used by 50,000+ websites and makes me $10,000+/month.
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.
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.
My technique to avoid burn out is to hack for X duration then take Y time off and let the community fill in the gaps.
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.
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.
OSS like the audio?
Dude, you spent your own free time which you barely had making software for others. You could've done anything else with that time and you spent it helping others.
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 :)
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 :)
Dear open source software maintainers,
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.
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.
So now they even have to care a lot about payment providers in order to receive money?
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.
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.
The only problem here is that the author perceives a need to apologize, or to even feel regret. If the only compensation for starting and maintaining an open source project is the work itself or personal use of the product, then you are your only customer. The moment it stops being fun or worth the effort, you have every right to just stop without feeling a tiny bit of guilt or remorse.
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.
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.
It seems like some open source maintainers need to learn the power of "no" and how to say it without guilt. My life improved when I learned I could say no without explanation. Like everyone says whenever this topic comes up, you don't owe anyone anything.
Edit: https://www.google.com/search?q=how+to+say+no+without+feelin...
Edit: https://www.google.com/search?q=how+to+say+no+without+feelin...
I can empathise with the author completely here. This exact thing happened to me in the last couple of years (albeit with a much smaller user base than in this case).
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.
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.
I think we need to stop seeing open-source development as a form of free-as-in-beer labor, and start seeing it as a form of professional empowerment.
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.
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.
I’ve seen few OSS burn out posts lately. I created gitignore.io and I’m thankful it wasn’t that successful because even the 5 hours a month I put in didn’t yield much financial compensation.
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.
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.
Looking at https://gitignore.io - there is plenty of empty space and nothing, even subtle and small like "I would appreciate donations" with link/button.
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)
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)
I sold the site to Toptal 2 years ago, but trust me I had donate buttons, crypto donate buttons, I messaged multiple big tech firms that used my project to ask for sponsorships, I ran ads using carbon. I tried a lot of things over the 7 years of running it and lots of the avenues failed or didn't generate enough revenue.
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.
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.
Tangentially related: My personal opinion is that github UI should make it bloody obvious by default "this project does not provide support." Maybe even with the issue tracker disabled by default.
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.
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.
One of the observations I have had is supporting opensource on donations is not a model that works long term. It could have been true back in the 90s and early 2000s. But these days the tech shift happens at very fast rate. So if your opensource product or concept is successful in the market, you cannot compete with another product or a startup cloning you idea on donations.
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.
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.
To reduce burnout among open source developers GitHub could offer a couple of additional features:
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.
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.
Instead of expecting corporate users to pay (which can be difficult, corporate finance depts are good at spending large sums of money, but suck at small expenses), or acknowledge use (company policies might mean employees are not allowed to), perhaps the major hosting providers such as Github and Gitlab can directly remunerate open source repo maintainers depending on the popularity of the hosted repo? Surely they make a lot of money by more and more devs adopting their service?
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.
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.
I like the idea, but I don't think it should be on github's shoulders to directly fund opensource. They do more than enough.
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.
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.
I think this is the kind of problem that might be solved by tokenomics. Gitcoin (https://gitcoin.co/) seems like a good step forward.
For every single one of my Open Source projects, having an exit strategy has played a central part. This included setting clear expectations and boundaries around what the scope of the project is, defining "feature complete" to be below what some users are happy with, and making sure occasional contributors can fix the critical bugs. Millions of people are currently using what I've built, and I spend zero time on those projects any more. Life's too short to be a slave to anything.
> big companies are using the project and need a lot of things as well from it in order to keep their projects healthy, but in most of the cases this is a talk in just one way.
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...
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...
Yes, I've seen corporate presentations on that matter, which basically focused on the zero-cost aspect. Well, you get what you pay for, I guess.
Well, often you get way more than you pay for, and it would be stupid not to acknowledge that. For example almost all Linux users never pay for nor support Kernel development in any way or form. And I think the people who do the development and create the value for the rest of us mostly are ok with that.
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.
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.
[deleted]
Even when open source is “attributed”, that is usually done in the laziest and bare-minimum way possible (like being buried multiple levels deep in some “Acknowledgements” item, that simply displays a 45 page text document with unzoomable and unsearchable text that casually lists the dozens of open source libraries used).
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.
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 very sad to see this happen. Open Source project leads, this is important: You need to stop thinking about other people using your project.
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.
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.
And Github still doesn't allow you to disable pull requests or issues in a repository.
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.
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.
I'm pretty sure you can archive a repository and disable issues that way. I've seen that happen (unfortunately) to a few libraries I follow.
You actually can disable issues now; I'm glad they finally added it as an option.[1]
[1] https://docs.github.com/en/github/administering-a-repository...
[1] https://docs.github.com/en/github/administering-a-repository...
I think issues are a great way to get people who are willing to maintain it, together and working on forking and getting on a single repo. Completely cutting it off is a bad idea. Perhaps disable notifications and pin an issue saying "I can no longer work on this project, feel free to fork it" and if people fork and good-faith maintain it, perhaps list it on the Readme or pinned issue.
After 6 years of working on two open source projects full time (16k and 10k GitHub stars) I decided to close off issues and discussions. GitHub has a nice checkbox you can untick to remove that tab and I did it. It's a thankless job, one that's pretty stressful and it's unclear what you gain from letting people berate or complain at you about their problems. I think I mostly built these tools for myself anyway so it felt like the right time.
Imagine giving so much of your life, passion, and energy away for free, then feeling guilty that you couldn't give even more. I'm glad Pedro decided to step back to focus on his health. That is not an easy decision to make. As he starts to return, I hope he will consider letting others take up part of the work and shoulder some of the burden. This kind of open source vampirism isn't healthy.
I had a similar moment where I almost gave up on Read the Docs, going as far as writing a similar post but never publishing it. I wrote about that experience here: https://www.ericholscher.com/blog/2018/feb/7/the-post-i-neve...
Don't use MIT. Use a GPL.
How does that exactly address the core issue of the post which is OSS maintainers are simply burning out due to a lack of support.. ?
The support structure is different if you go with the FSF - someone can takeover the project and big corps that use the code must contribute back. My take is, choose MIT if u want to give developers convenience (and u don't care if you r flooded with request and lack of attribution). Or choose GPL and the FSF if you care about legacy, organized support structure and end-user value. I even think dual license GPL version / paid version is a better choice than just releasing under MIT...I feel sorry but this story keeps repeating itself, we've been at it for decades and people are just realizing that open source is pointless without organized support groups or monetisation plan that respects developers and users freedoms
[deleted]
[deleted]
Reminds me of a phenomenon I see again and again in small business: owners struggling to keep up with demand and sacrificing their sanity in the process.
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.
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.
As a user of other people's popular open-source projects, I generally lack awareness of the effort and investment of time that the maintainers put into the projects. It's always eye-opening and helpful for me to see posts like this, because I gradually take their work less for granted.
First, no need to apologize!
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.
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.
Commenting more on the general pattern than specific case here, but sounds like the only failure here could have been to either 1) ask for help or 2) effectively delegate
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.
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.
I personally think it's most healthy to develop open-source software when you are the target user.
This way incentives align so that there's more intrinsic motivation to work on the software.
This way incentives align so that there's more intrinsic motivation to work on the software.
One of these days, a startup will tackle this problem and offer paid support for any open source project.
First, no need to apologize!
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.
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.
This is the argument for UBI
I have a lot of sympathy for developers like this, and this kind of story is too common.
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.
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.
That's the dark side of open source.
Companies think these projects grow on trees and they use them without paying anything.
We need law changes to ensure that open source can be sustainable and companies pay the fair share of revenue they make by using it.
> We need law changes to ensure that open source can be sustainable and companies pay the fair share of revenue they make by using it.
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 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 don't need more laws. There is something called a License Agreement.
We just need UBI.
We just need UBI.
not sure why are you being downvoted, you have accurately described the incentive structure leading to these situations
I was onboard until you suggested law changes
The point of open source is people can use it freely. A better project, which hits the right spots will naturally attract financial and technical support, both from the companies and the community. It is really just a free market, where the best projects survive.
Financial support is pretty arbitrary and not related to quality, user numbers or importance of the software.
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.
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.
It's almost like open-source needs a micropayments solution.
If every download cost a tiny amount, could it add up to pay some maintainers full time?
If every download cost a tiny amount, could it add up to pay some maintainers full time?
_people_ not big corporations that make billions, don't pay tax and don't share revenue made using the open source software. Personal use should be free but gravy train for corporations must end.
How do you estimate a share? What's the share of libc in Google business? What's the share of openssl? What's the share of ncurses?
libc used in Android.
openssl -> view boringSSL - BoringSSL is a fork of OpenSSL that is designed to meet Google's needs
Nobody says that one company has to support every project and google supports many open source projects.
Nobody says that one company has to support every project and google supports many open source projects.
But how would you estimate the contribution that libc has to Android? Is libc entitled to 10% of Android's revenue? 20%? 100%, since it is a vital component? This is what the GP was asking.
Only google can answer that.
But i think we can not say one lib make x%, it are all the libs and tools that are necessary. We don't now what e.g. google search uses under the hood, but all are needed so google can make only $1.
You don't own the open source software you write, so you don't have the right to make demands of its users beyond what the license stipulates. That companies can make billions with your software and not owe you so much as a cup of coffee is not the dark side of open source, it's an expression of the same freedom that allows you to fork and reuse any FOSS software under the same terms.
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."
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."
Please stop the misinformation: Open source authors do own their IP, but are altruistic enough to license it to others.
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 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.
>Open source authors do own their IP, but are altruistic enough to license it to others.
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.
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.
once you distribute your code under a permissive licence, you typically don't get to undo that surrender of control over your work
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
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
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.