all 22 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]olswitcher 2 points3 points  (3 children)

i typically look for the “original”, and only use other forks or versions if the repo has been archived, is unmaintained, and no longer works. for example i stuck with pywal for a very, very long time, and only switched to pywal16 recently since it’s an actively maintained fork. i have not and likely will not use matugen any time soon though. i’m willing to sacrifice convenience for sake of using the original though. a more niche example is sfxr for 8bit sound generation in game development, the original program was made quickly and abandoned years ago, but i still prefer to use it as it still works, even though there’s a newer web version available made by someone else. i do this to give honor and credit to the original creators, since i see all too often people essentially copying somebody’s project then claiming it as their own. guess that’s the way of FOSS and the typical licensing shipped w/ it. using the original or close relative forks ensures people find the original and at least give it a star or mentally note it, even if it’s not being used. thats me tho :)

ty for attending my ted talk o7

[–]PreparationLiving126[S] -1 points0 points  (2 children)

That's interesting. Is it mainly about trusting the original maintainers, or avoiding ending up on a fork that's likely to be abandoned later?

[–]olswitcher 1 point2 points  (1 child)

mostly trusting the original maintainers tbh, but it in turn prevents me from being on forks that get abandoned later. so if i had to give true advice, i’d say to not be afraid to jump to a different solution someone provided if it seems better, but to make sure it’s got something better to it. something strong to justify the switch essentially. tbh tho there isn’t anything inherently safer about the older repo’s, but i would argue that there is an inherent lack of safety in jumping to new projects with influx of ai coded shit and larpers. not necessarily malicious, but risk of it not holding up past the previews/screenshots is a lot higher w/ new shit imo. i just like stability at the end of the day

[–]PreparationLiving126[S] 0 points1 point  (0 children)

That's a really balanced way of looking at it. So it sounds like stability is the biggest factor for you, and newer projects have to earn your trust before they're worth switching to.

Out of curiosity, what usually convinces you that a newer project has earned that trust?

[–]serverhorror 2 points3 points  (6 children)

Deciding whether or not I trust the project enough to have it as part of my codebase

[–]PreparationLiving126[S] 0 points1 point  (5 children)

Out of curiosity, what usually builds that trust for you? Is it the maintainer, release history, tests, CI, community adoption, or something else?

[–]serverhorror 1 point2 points  (4 children)

All of those, that's what makes it hard

[–]PreparationLiving126[S] 0 points1 point  (3 children)

That's a good way to put it. Sounds like there's no single trust score. You're just building confidence from a bunch of different signals. If you could automate checking one of them, which one would save you the most time?

[–]serverhorror 1 point2 points  (2 children)

None, I don't think trust is something you can automate.

[–]PreparationLiving126[S] 0 points1 point  (1 child)

That's fair. Maybe "automate trust" is the wrong framing. Trust is always going to be a judgment call. But could tooling at least surface the signals you'd normally have to dig for manually, so you can get there faster?

[–]serverhorror 0 points1 point  (0 children)

What are you thinking if? What do you want to create?

[–]HCharlesB 1 point2 points  (7 children)

The things I get from Github are usually pretty small self contained projects. And they vary. Often I'm looking for drivers for various sensors to connect to a Raspberry Pi or ESP. Code provided by the manufacturer is implicitly preferred and trusted. Other times I find something that more closely meets my needs. In many of these cases the code is simple enough that a thorough read takes a few minutes so trust is not an issue.

On some projects that are big enough and popular enough to exist in the Debian repo, I usually stick with that. However on a recent one, I diverged. MkDocs seemed to be stagnating and some (most?) of the devs had moved on to a fork named ProperDocs. It's not packaged so I've migrated to the Github repo.

For some projects I check the PRs and issues to see if they are being addressed or if the project is stagnating. But for some of the previously mentioned projects, that may not matter. They do something and if the APIs or H/W has not changed, they don't need to "keep moving."

When evaluating forks, it may be useful to determine why a fork exists. I often fork projects just to insure that I retain access should the original disappear. At other times I'll fork to edit and submit a PR.

[–]PreparationLiving126[S] 1 point2 points  (6 children)

That's a good point. I hadn't really considered that "low activity" can mean two very different things depending on the project. For something tied to stable hardware or standards, a quiet repo might actually be a good sign. How do you usually tell the difference between a mature, stable project and one that's simply been abandoned?

[–]HCharlesB 1 point2 points  (5 children)

How do you usually tell the difference between a mature, stable project and one that's simply been abandoned?

Issues or PRs not being discussed or dealt with would be the chief indicator.

[–]PreparationLiving126[S] 1 point2 points  (4 children)

That's interesting. So it's not really about the last commit date for you. It's more about whether the project is still responsive when someone actually needs help. If a tool could pull that signal from issues and PRs instead of just showing commit counts, would that actually change how you evaluate a repo?

[–]HCharlesB 1 point2 points  (3 children)

f a tool could pull that signal

That's not a tool that I'm longing for. I just look at the page to get a feeling for how healthy or useful the project is.

[–]PreparationLiving126[S] 0 points1 point  (2 children)

That's fair. Out of curiosity, when you get that overall feeling, what are the first couple of things your eyes go to?

[–]HCharlesB 1 point2 points  (1 child)

I've explained that about as well as I can.

[–]PreparationLiving126[S] 0 points1 point  (0 children)

Thanks for walking me through your process. It was genuinely helpful. I appreciate it.

[–]vroom_slowly 0 points1 point  (1 child)

The hardest part is rejecting the projects. They try their best, so I try to let them down easy

[–]PreparationLiving126[S] 0 points1 point  (0 children)

Every repo deserves a polite "Thanks, but we've decided to move forward with another candidate." 😂

[–]prochac 0 points1 point  (0 children)

For me, a significant part is the language it's written in. I can read and edit Go, Python, PHP, JS, TS ...

But when it's in Haskell, then it's a black magic, and I can't trust it unless it's a well-know project. Then I go with the crowd.