Hacker News new | past | comments | ask | show | jobs | submit login

I'm getting pretty good at working that out.

Note that this isn't a dig at any particular project, I know FOSS is hard and free time is scarce (and so is funding).

Quick ones:

1. Date of last commit to main repo

2. Number of issues open on Trac/Bugzilla/GitHub/Jira whatever (note, I'm taking a point off if you use Trac, only because there's still an instance from 10 years ago sending me emails that I can't unsubscribe from)

Takes more time:

3. Number of open pull requests/mailing list patches and general discussion around them

4. Any kind of clear and updated roadmap.

Edit: number one these days should be an up to date and working CI/CD system with published artifacts, including for Windows.




I like to look at the reactions maintainers have to pull requests. Do they usually get merged, or do they end up being dragged through a bureaucratic nightmare and eventually closed?


I've never written anything popular enough to really get pull requests, but I can definitely understand not merging a pull request due to not being able to maintain that code or it taking the project in a different direction to what you want.


It's one thing to say "no", it's another thing to say "later" forever.


That comes back to having a defined plan for where you want the project to go.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: