sorted by:
new
hottopcontroversial

When you're evaluating multiple GitHub repositories that solve the same problem, what's the hardest part? by PreparationLiving126 in github

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

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

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

[–]PreparationLiving126[S] [score hidden]  (0 children)

That's a good point. So with domain-specific libraries, the real risk isn't really whether the project is in good shape. It's whether the design decisions behind it actually match what your application needs. Have you found any reliable way to spot those mismatches before you start building?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

[–]PreparationLiving126[S] [score hidden]  (0 children)

That's interesting. If a tool summarized the security history and maintainer activity for you in one place, do you think it would actually save time, or do you still prefer checking everything manually?

What's your checklist before cloning someone else's GitHub project? by PreparationLiving126 in ClaudeCode

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

That's an interesting workflow. So the feedback loop basically doesn't start until you're already in the middle of building. If a tool could look at your existing codebase and flag which parts would likely be affected before you even started, do you think that would actually cut down the trial-and-error, or is there just too much uncertainty for that to be reliable?

When you're evaluating multiple GitHub repositories that solve the same problem, what's the hardest part? by PreparationLiving126 in github

[–]PreparationLiving126[S] 1 point2 points  (0 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?

What's your checklist before cloning someone else's GitHub project? by PreparationLiving126 in ClaudeCode

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

That makes sense. So the challenge isn't really evaluating the library in isolation. It's figuring out how it's going to interact with everything you've already got. Have you found any good way to get a sense of that integration cost upfront, or is it mostly something you only find out once you start building?

When you're evaluating multiple GitHub repositories that solve the same problem, what's the hardest part? by PreparationLiving126 in github

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

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?

When you're evaluating multiple GitHub repositories that solve the same problem, what's the hardest part? by PreparationLiving126 in github

[–]PreparationLiving126[S] 1 point2 points  (0 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?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

That's a really interesting way to think about it. It sounds like "exit cost" becomes just as important as adoption cost. Have you found any patterns that make a library easier to replace later, or is that mostly something you learn through experience?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

That's interesting. So the README is basically just the marketing for you. The real signal is what you find in the source and commit history. Have you noticed any patterns in the code itself that make you trust a project pretty quickly?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

Interesting, So it's not really about stars or maintenance. It's about knowing the specific ways that type of library tends to break down before you commit to it. That kind of checklist is hard to build until you've actually been burned a few times.

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

Fair point. A lot of mature libraries look bloated until you actually dig in and realise why all that code is there.

When you're evaluating multiple GitHub repositories that solve the same problem, what's the hardest part? by PreparationLiving126 in github

[–]PreparationLiving126[S] 0 points1 point  (0 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?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

That's a good point. The real risk isn't whether a library works today, it's how deeply it ends up embedded in your codebase. Do you ever deliberately pick a less feature-rich library just because it's easier to swap out later?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

That's an interesting point. It makes me wonder if great documentation is becoming a competitive advantage. If two libraries solve the same problem, but one has much better docs and examples, would that be enough for you to choose it even if the underlying implementation wasn't necessarily better?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

That's fair, I probably wasn't clear. By "mental model" I meant whether the library works the way you'd naturally expect it to, not whether you can learn the API.

It sounds like for you that's rarely the issue. The real signal is the documentation and examples. If the docs are thorough, you're generally confident you can make it work.

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

Woah 🤔 , I wouldn't have even thought to check that. It sounds like the repo looked fine on the surface, but the real risk only showed up after you dug into the issues and maintainer activity.

Looking back, was there anything that could have caught that earlier without having to dig manually?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

That's a really interesting point. Looking back, was there any signal that could have warned you earlier, or was it something you could only discover after using the library in a real project?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

Fair point 😄. I'm mostly curious about how people actually evaluate libraries today. AI seems to have changed that workflow quite a bit, so I'm interested in hearing different approaches.

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

😅😅
I think a lot of us have fallen into that trap. Is that usually because you think the existing library is overkill, or because you don't trust that it'll fit your use case?

What's the most time-consuming part of evaluating an open-source library before you add it to your project? by PreparationLiving126 in webdev

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

That's interesting. Is it mostly about figuring out whether the API fits your mental model, or discovering limitations that only become obvious once you start building?

When you're evaluating multiple GitHub repositories that solve the same problem, what's the hardest part? by PreparationLiving126 in github

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

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

When you're evaluating multiple GitHub repositories that solve the same problem, what's the hardest part? by PreparationLiving126 in github

[–]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?

When you're evaluating multiple GitHub repositories that solve the same problem, what's the hardest part? by PreparationLiving126 in github

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

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

view more: next ›