Hacker News Reader

Comment by altf4 | Hacker News Reader

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.

View on HN

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.

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.

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

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.

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.

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.

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.

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

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

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

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

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/ ?)

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?

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.

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

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

I guess you have a typo there in total time?

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)

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

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.

What’s the library, out of curiosity?

Reply on news.ycombinator.com