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

It impacts me as a developer because this potentially diminishes DHH's credibility in my eyes, and as the Rails BDFL, this has the potential to impact how I approach the platform I use to make a living.

Well, all the code is available, right? You should base your decisions on the design and implementation of Rails, not on one of the author's blog. This is a really scary pattern emerging that I've noticed. It seems like people want to base their infrastructure decisions on things that don't matter. "Well, I would use $foo, but the website doesn't look very nice." "$foo seems nice, but the main author can be mean." If this is how you make IT decisions, I pity you.

(A while back, someone posted to my blog a comment that read, "Because you were so mean on CPAN Ratings, I've suggested to my clients that they use PHP instead of Catalyst." That doesn't seem like a very sound way of evaluating infrastructure decisions, especially since I am not the author of Catalyst. If they want to make more work for themselves because they don't like me, all I can do is point and laugh. Clearly I'm mentally ill, though.)




"..all the code is available, right? You should base your decisions on the design and implementation of Rails, not on one of the author's blog."

I can stare at the code all I want and still be no closer to knowing how rails performs under load, or how much memory it leaks. That isn't just about the code, it's about behavioral interactions with the OS, level of traffic, other layers in the stack. To address those issues I could run a million performance evaluation experiments, or I could try to gauge how the community is doing, who's using it that is kinda in the same situation as me, and what issue's they're dealing with. And I refuse to believe you don't do the same.

He's not talking about what words DHH uses in a blog. He's talking about DHH's credibility in saying rails was production-ready. That is relevant to platform choices.


Open-source is largely a trust network. I don't mind if someone is an arrogant SOB, intolerant of n00b questions, or has an ugly website... IF I can trust their word about the code they produce, AND if they are still able to maintain an active community. There are implications about the long-term ecosystem regarding the particular project in question if the leadership falters too frequently or too severely, and the support network (community, business, labor, mindshare, et cetera) around a project is a vital aspect in making IT decisions. If you can't trust upstream providers to be clear and honest with respect to code, the future doesn't look so bright. While the proof is in the pudding, I have neither the time nor the inclination to thoroughly vet every change or release (this gets back to Open Source being a trust network.)

The blog post comment that you refer to seems to reflect a poor thought process. However, mine has a little more reasoning behind it.




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

Search: