Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The difference is that code from an existing developer is going to be maintained: that is, the existing developer will stay around to take care of it.

Code from an outside developer will just be committed and never touched again in many cases, since the outside developer doesn't intend to stay and work on the project. If you don't believe me, look at the history of the ffmpeg project: there are enormous swaths of unmaintained code (and uncommitted code) for exactly this reason.

Thus, it is often reasonable to have higher code standards for code whose author does not intend to maintain it into the future.



Great unmaintained code is better than a well maintained codebase that features a set of fatal flaws :)

These things are relative


There's no such thing as "great unmaintained code".


of course there is... great code that doesnt get refactored. Kick aside corporate jargon and namby-pamby ness :)

The point was sometimes stuff just works, much better than a mess of a refactored project that has a core flaw.


Great code is still subject to entropy. Shit will break. Mail servers will start using some proposed SMTP extension, someone will find a nasty bug or two, there will be security problems and inconsistencies and inefficiencies discovered.


Sure. Then you simply require hit-and-run commits to be well-commented and also include good docs.

Just because it's not currently maintained does not mean it won't be maintained in the future.


What set of fatal flaws are you talking about?


huh? what? the flaws in XYZ piece of code.

(I think your misunderstanding: I was replying to the generalisation with a generalisation)




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

Search: