Ask HN: How to proceed with less-than-perfect FOSS projects? | Hacker News Reader

Ask HN: How to proceed with less-than-perfect FOSS projects?

9 pointsexorbitas4 comments

A few weeks ago I have started to learn Rust. To have a nice "goal" project I decided to develop a CLI-based chess client in the language which should be free and open source. As I was learning enough to get the first steps behind me I opened a github public repository which I have used for development ever since. The project is still far from completion but as I am learning more about the language I can spot minor and major flaws from both design and implementation standpoints.

I am unsure how to proceed here, it feels like the standards for FOSS (and any public software) are so high that any less-than-perfect work will reflect badly on me, as I am a part time Software Developer in another language and consider applying for CS PhDs in the next year or so. Do you think it would be best to get rid of the project and delete it, or would it be better to keep it published while continuing to work on it, eventually fixing all flaws? Apart from that I am also not sure how useful it would be to anyone stumbling upon it right now, as it is not yet fully functional and not a good example for learners. Do you think FOSS software should only be published at a point where it bears an actual value to the user? I was publishing early in the hope that other chess enthusiasts might join the development, but I don't think that will happen for the foreseeable future.

Thanks for any advice!

IMHO the main part is honesty in "advertising". If a project README promises a production-ready product I'm looking at it differently than at one that says "my Rust learning project: a chess client". I don't think in most environments a clearly toy project in a different language is going to be held against you in any way. IMHO being honest also covers the "FOSS software should only be published..." point - I've found random snippets of "outdated" code by others sometimes extremely useful, so I try to apply similar rules to my own code. (some exception for security-critical code personally, I won't publish that if I know it is sub-par)

I think it's jsut fine to leave such a project up, with "I've abandoned this / I learned what I wanted to from this effort". Adding a note explaining where you think its flawed and other current thoughts on the matter is good too. If you come back to it later those will help; if someone else takes it up or is just poking at it for tips; also helpful.

If you never look at it again, it may at least give someone else an answer to a question or a tip on how to solve their problem sometime.

I'd kind of like to approach this the way I was taught to approach university programming projects years ago: shortcomings are fine if you document them, as long as you've written something that at least mostly works. Especially in learning projects, an honest effort and an awareness of potential issues should be enough, and documenting them allows a potential user to make informed decisions of their own. The worst-case scenario should be that a potential user ignores your project because it doesn't answer their needs.

I don't know how companies approach these kinds of things but I think it would make sense for them to appreciate an awareness and a realistic assessment of potential issues over perfection.

It just shows you're growing in your skills, I think there's very few people can look back at code they wrote even last week and not see where it could be improved.

I'd keep it as a record of your progress and just mark it as a toy project/not ready for production etc.

Reply on news.ycombinator.com