Live data from Hacker News

Sorry everybody, I failed with you

github.com

141–150 of 357 posts

Re: Sorry everybody, I failed with you

#141
post #36

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 "oth…

>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.

Re: Sorry everybody, I failed with you

#142
post #126
post #115

Earlier quoted context omitted.

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 GitH…

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 w…

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.

Re: Sorry everybody, I failed with you

#143

Seeing a lot of posts like this. Open source is wonderful in its way, but it's really not sustainable to work on projects that make money for other people - including big commercial interests - when they don't help out in any fashion. I'm not just talking money or contributions. I'm talking about simple acknowledgement: "we use project X" - even privately. A open source library that I worked on at Intel (the Hypersca…

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…

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.

Re: Sorry everybody, I failed with you

#144
Try to care less about what other people want. It's your project, not theirs. Also, there will always be someone who wants another feature. always. It never stops. So, i'd recommend only doing the features you personally want and tell the others: no thanks.

Side note, there are alot of manipulative people on the internet that dont have the skills to create something, and they will try to say certain things to you, so you would create the things they want. And they may act like they care about your project, but they dont, they just care about themselfs, and then on monday they tell their boss, look, i created this new feature. It's sad, but i've met people like that.

Re: Sorry everybody, I failed with you

#145
post #126

Earlier quoted context omitted.

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 w…

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 downloade…

You can possibly find some users in Github: https://github.com/search?q=jumprope+filename%3Apackage.json...

Re: Sorry everybody, I failed with you

#146

Seeing a lot of posts like this. Open source is wonderful in its way, but it's really not sustainable to work on projects that make money for other people - including big commercial interests - when they don't help out in any fashion. I'm not just talking money or contributions. I'm talking about simple acknowledgement: "we use project X" - even privately. A open source library that I worked on at Intel (the Hypersca…

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.

Re: Sorry everybody, I failed with you

#147
post #97

Earlier quoted context omitted.

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."

Re: Sorry everybody, I failed with you

#148
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.

Re: Sorry everybody, I failed with you

#149
post #83

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.

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 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.

Re: Sorry everybody, I failed with you

#150

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 weaponi…

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.

Post reply on HN