Live data from Hacker News

Sorry everybody, I failed with you

github.com

181–190 of 357 posts

Re: Sorry everybody, I failed with you

#181
post #101

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.

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.

Re: Sorry everybody, I failed with you

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

Re: Sorry everybody, I failed with you

#183

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…

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!

Re: Sorry everybody, I failed with you

#184
post #47

Earlier quoted context omitted.

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

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?

Re: Sorry everybody, I failed with you

#185
post #21

Earlier quoted context omitted.

> 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. We just need UBI.

Why UBI? I don't want any money, I have a job.

Re: Sorry everybody, I failed with you

#186
post #75
post #39

Earlier quoted context omitted.

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.

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.

Re: Sorry everybody, I failed with you

#187

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

Re: Sorry everybody, I failed with you

#188

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.

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.

Re: Sorry everybody, I failed with you

#189
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

Re: Sorry everybody, I failed with you

#190
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…

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)

Post reply on HN