Hacker News Reader

Comment by cbs | Hacker News Reader

What is this post responding to? And who is the target audience?

Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. We get it, Rails is "opinionated", sorry I guess we're saying "omakase" these days. Who really gives a fuck?

The reason DHH is getting loud complaints is because people feel that they carry a legitimate grievance but also feel no way to voice that opinion (or are trolls). Douchetastic talking down to them like exemplified in this post won't help (and will encourage trolls).

People with limited knowledge and understanding of something and/or restricted mobility in tech aren't in a place to see things the way you see them. Help them get to that place, instead of just telling them how to see things with metaphors that only work once you're at that place. Or just don't engage them at all.

Edit: Huh. This DHH blog post doesn't really feel on par as a response to the conversation in that github issue. But if it is, know that my post was written assuming the criticism was of the type he describes, not the type that transpired.

View on HN

What is this post responding to?

This: https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...

And also the corresponding reaction on Twitter:

https://twitter.com/jon_lemmon/status/284075141967790080

@dhh: @jon_lemmon Why don’t you go ahead and fork rails so you can change the default gitignore file for new apps? You can call it Rails on Drama.

ROFL, DHH has cajones.

Apparently somebody has bigger cajones.

@sbartholomew: @dhh the the Rails community has it relatively easy: http://article.gmane.org/gmane.linux.kernel/1414106 … :-)

Lol, imagine the flames if DHH had that kind of personality. People are being molly-coddled by DHH for stupid stuff like a default in .gitignore.

This 'stupid stuff' breaks every single new Rails app on Heroku that uses rbenv.

Exactly zero of the Rails apps on Heroku will break.

When you create a new app you'll need to remove a line from the autogenerated .gitignore in order to work the way you expect.

No?

I am repeating what Heroku's Ruby platform lead said here: https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...

You actually removed the word "new" from the middle of his sentence, which IMO changes the meaning substantially.

It does, yes. This is my bad. I do not use rbenv, personally. Let's see if HN will let me edit it.

It's funny, though the comparison isn't perfect, DHH is basically doing what Linus got infuriated about here. He's making a minor change for what seems like very little gain, meanwhile breaking third party projects that rely on Rails.

A very imperfect comparison, as Linus is maintaining a kernel and DHH is maintaining (the next major version of) a highly opinionated web framework.

its amazing anyone commits to the kernel after seeing that. i sure the hell wouldn't.

The Linux kernel is one of those top open-source projects, big, old, well oiled and with lots of contributions, both from companies and individuals.

So Linus must be doing something right.

It makes me less likely to want to commit code to the Linux kernel, but more likely to want to run it.

Typical Linus.

Linus was right, though.

And DHH was wrong.

Not a fan of the way Linus handled that, though he sure did set the tone and expectations for everyone else!

you know, while i don't talk to people like that (and especially not in public), i have considerable sympathy for linus's position there. it is clearly a deeply held philosophical belief of his that kernel changes should not break working userspace code, and here is someone who is evidently a long-standing kernel maintainer trying to blame a user app for breaking against a technically bad kernel patch.

i'm betting he made that mail public very deliberately, as a way of telling the world at large that as kernel dictator he would not tolerate his "staff" treating users like that.

The mail is always public... It's part of the Linux kernel newsgroup...

he could always have sent that mail to Mauro privately and a toned-down version to the list.

Doesn't that defeat the purpose of having a public list?

I think a big reason it's on the public list is because it should be. Linux is Linus' baby, he has every right to yell at someone for doing pretty much anything. And in this case, it was deserved. If you're going to break the first commandment of Linux development (don't break userspace), and blame the userspace for breaking, you should be reprimanded.

Does Rails not provide a way to customize the scaffolding used to make a new app, without forking?

It does have some features to do this, but the point is that the default operation is simply broken for many, many people. That suggests that it should not be the default.

Yes, you can using `rails new app_name -m template_name`.

But that would be way overkilled, here, because we just speak of adding a line to the .gitignore file.

If you don't know git, .gitignore is a file you're expected to edit, you put there anything you don't want to commit in the repository.

So, once again, all the trolling is about changing a default option. Which can be changed back with one line of four characters ("/bin"), in a configuration file. Change to be made only once in the whole life of your application.

Mexican-beaner grammar nazi here, is "COJONES" not "CAJONES". xD

That's a spelling issue, not a grammar issue :)

Actually, it's neither: http://en.wikipedia.org/wiki/Euphemism

Thanks. I'm not really a rails person, so forgive me if I have some questions. Am I correct in interpreting that thread as DHH not wanting to support multiple ruby package managers in the rails codebase? In particular, DHH has 'blessed' rbenv and that commit wants to support rvm?

If this is the case, then I have to wonder: why is there any dependency on a package manager at all in the rails codebase? This just seems odd to me, and perhaps is the source of the conflict. E.g. people are fine with 'omakase' frameworks, but these menus typically don't include toolchain dishes. It would be like going into a restaurant and being told that you must use chopsticks, no forks allowed.

> In particular, DHH has 'blessed' rbenv and that commit wants to support rvm?

No. Two things are going on:

1. 'binstubs' will now be checked into source control. If I use MRI and you use JRuby, they'll start with different things, and therefore, cause conflict.

2. Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now.

David maintains that if I use MRI and you use JRuby, or if I use rvm and you use rbenv, this is an 'organizational failure.'

"Many of the Ruby version switchers work with '#!/usr/bin/env ruby', but rbenv won't in certain circumstances, so an optimization for it has been built into the framework now."

Incorrect. It is support for an enhancement that rbenv provides.

You often want to invoke an application binstub from another program such as cron, and you want to use the per-project Ruby version specified in the application's root directory. Other version managers require you to spawn a subshell and load the version manager into the shell or otherwise set up the per-project Ruby version environment, then `cd` into the application directory, and finally run the binstub.

rbenv requires an environment set-up step too—set `RBENV_DIR` to the application root—but provides a wrapper that eliminates the need for such gymnastics. When you change a binstub's shebang to `#!/usr/bin/env ruby-local-exec` rbenv automatically searches up the binstub's directory tree to find the right Ruby version.

Thank you for clarifying the exact circumstances, Sam. I don't use rbenv, I was going by discussions on the ticket and in Campfire. I was referring to that difference in the binstub, but maybe should have been more clear that that's a conflict with the enhancement and not the base features of rbenv.

If a team is using different versions/runtimes of ruby I would have to agree this is an organizational feature in some cases. If you're working on a webapp you should be aiming to make as few differences between a development box & production as possible. Its unlikely that you have jruby & mri in production, wherein lies the failure.

Square is one example of a company which famously develops in MRI but deploys JRuby to production.

That sounds crazy to me, but I have very little experience with ruby. In PHP/python doing that can be unpleasant.

I'm not knee-deep in this specific issue with the binstubs, but I generally agree about the legitimate grievances. The Merb effort and the Rails 3.0 refactor resulted from people unable to voice what they need. We seem to keep repeating history.

Asset Pipeline is also the wrong area of innovation to focus on. Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end. There are more smartphone-like devices in the world than personal computers; there are kids growing up with a smartphone as their first computing device; people of our generation have a bias towards thinking of UX and web-apps as desktop-first; when the tooling around API-only Rails apps mature, then template-driven apps will start dying into irrelevance.

But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses, and it won't be in apps.

> Rails should be baking in support for creating API only apps, make it easy to shed template-driven code and write UX-agnostic backends. Mobile is driving a need for creating API-only apps, and something like Asset Pipeline is an evolutionary dead-end.

This has never been Rails' focus. Let Rails keep doing what it kicks ass at. Sinatra works great for API endpoints. There's probably an opportunity for an API-focused extension to Sinatra. Of course, Grape works too (https://github.com/intridea/grape).

The nice thing is that all of these are built on Rack now. GitHub.com runs as a Unicorn rack app that mounts over 30 Sinatra apps and a massive Rails app together. I'm not saying this is an optimal solution, it's just where the app is at in its current evolution. But it is very possible :)

For things like APIs, Rails has https://github.com/rails-api/rails-api, an excellent project.

I've taken a look at it. It does not really use the Rails 3 architecture (Russian Doll Pattern) to its fullest potential. I have written https://github.com/intermodal/intermodal back in 2010 to demonstrate it, and have put that code into production.

There are some people trying to revive Rails-API. I have already sent them an email begging them to steal ideas from Intermodal. https://groups.google.com/forum/#!topic/rails-api-core/LoJap...

Maybe they will, maybe they won't. I got a polite brush-off so I doubt they really looked at it, but since I am exiting, whatever.

In writing Intermodal, I've had to muck around with some of the guts of Rails. I've found that Rails 3.0 very much follows the principle of Russian Doll Pattern, but Rails 3.1 onwards started moving away from it. There are baked-in assumptions in the code for a template-driven app. This is where the Rails leadership is focused on.

Sinatra is not actually all that good for writing API endpoints.

The Rails 3 architecture is very modular. It was designed as framework to write frameworks, of which a template-driven app is one such framework. I have written a different framework specifically for just an app focused on SASS that has an abundance of CRUD operations.

However, when Rails 3.1 started transitioning into Rails 3.2, the assumption that Rails is specific for a template-driven app started being baked deeper into it. It was moving away from the "Russian Doll Pattern" that was so useful for me.

If you're going to do API only apps then there are much better alternatives than Rails. Rails is heavy. It's like using a cruise ship to navigate a small creek.

Rails is "heavy" because it does a lot of things that you'll end up having to recode by hand with any other "lighter" solution.

Sure. If you're building a traditional web app. The sort of web app Rails is good at. But if you are constructing an api, you can use ligher and alternate technologies that will get the job done faster and better.

Like what? Rails is great for APIs, because APIs, especially RESTful and Hypermedia APIs, can literally be a standard webapp with JSON views instead of HTML.

I've never built a SOAP API in Ruby, so maybe Rails wouldn't work with that very well. XML-RPC might also be a little tough, but I honestly can't think of any significant difference between a "traditional web app" and a RESTful API. They're a perfect example of code reuse in MVC (or Model2 if you want to be pedantic).

Check out https://github.com/intermodal/intermodal

People keep repeating that like it's some commercial gimmick, but what does it really mean? How is Rails or rails-api not suited for APIs? What's lightweight? What's easy?

And more particularly since you seem to know about this, what other option would you favor?

Well Sinatra seems pretty nice. I'm a node.js developer so I use Restify and Express. But I practically build api's exclusively. I've spent a lot of time cleaning up after terrible Rails applications. Replacing bits that are too slow or difficult to maintain with smaller more nimble node applications.

"what does it really mean?"

It means he's a node troll. They take a shot at the dominant frameworks any chance they can get. Node trolls have reached the level of obnoxious arrogance that early Rails developers were once mocked for. Don't feed the trolls.

It's about using the right tool for the job. Most developers never seem to understand that. Everyone seems to want the same magic bullet for everything.

Not so much recode by hand as actively choose components that provide the functionality. Sure, you might have to recode a bit of the between-components wiring if the separate components you choose don't natively support each other, but its hardly as if you'll generally have to recode the major components themselves.

Sure, Sinatra doesn't come with ActiveRecord like Rails does, but you can use ActiveRecord on its own with Sinatra -- or use Sequel or DataMapper or whatever other ORM [or non-ORM persistence solution] you prefer -- with Sinatra, you don't have to code your own by hand. Similarly with other components.

>> Rails should be baking in support for creating API only apps

Right now, I can create a rails app that doesn't use templates at all. I can start with a basic rails 4 install and quickly prototype an API that communicates through JSON or any other format I can think of. I can leverage handlebars and ember.js if I want to go that route, or I can stick with dumb old 'templates' to display my data. When you start coding ruby on rails you quickly realize that 'template' is just a word and that you are free to do literally anything you can think of, easily.

>> people of our generation have a bias towards thinking of UX and web-apps as desktop-first

Let us assume this is absolutely true. Why does rails keep you from writing code that honors this bias? Rails gives you abstractions you can use to decouple. If I want local data persistence perhaps I'll need support from other libraries--but only if I'm too shy to take a shot at writing a tool myself. I think you're on to something with the 'desktop-first' remark. We do need to be able to store data browser-side. We do need to address performance issues--especially as it relates to decoupling server-side data logic and application data logic. Rails is a very good tool for supporting solutions to these types of problems and packaging them in easy to implement applications.

>> But, I'm done with it. I'm looking at the next wave of leading edge of innovations for the masses..........

Obviously rails is useless if you don't want to make applications, but otherwise you can really do anything and it's not actually hard to configure rails.

I used to think that david hh and many other experts in the community were mean. Then I realized they have to deal with people all the time; not the 'grievances', but the attitudes. There are many trolls and one cannot be too careful.

https://github.com/rails/rails/commit/61b91c4c55bcbd5a2ec85d...

I read that entire comment thread, and maybe my perspective is skewed, but I saw none of the behavior that DHH described there. The discussion was generally polite, the participants were mostly experienced Ruby developers with open-source and community track records, and their objections were well-supported. I have less sympathy now for the original post than I did.

Exactly my thoughts. For example, I know for certain that José Valim is (or at least was last time I checked) a core ruby dev and he's against this change for example. DHH wants to sound like he's talking to trolls and the casual Rails user, but it's clear from the github thread that he's responding to seasoned members of the community as well, which quite frankly is a pretty shitty way to treat people who are known contributors. It's not a community, it's whoever screams loudest. To me that thread and this posts shows that DHH is willingly wearing horse blinders instead of keeping his opinions being open to being amended through thoughtful discussion with others as talented as he is.

The biggest problem with this "omakase" attitude is that it's causing Rails developers to miss the boat on many new developments in the state of the art in web app development because legacy is now baked in via opinion. 37Signals hasn't been the forefront of web-app design for a few years now. There are plenty of single page web apps out there that are far more responsible and present a better user experience than tools from 37Signals. Don't get me wrong, they are still decent, but they aren't demonstrative of what is achievable insofar as excellent user experiences are concerned.

Maybe this has changed, but I spent a year working on a single page webapp built on Rails and the asset pipeline was excruciatingly painful to debug to get your javascript and other assets handled properly.

Rails Core. I don't think he actually has Ruby core access like Aaron Patterson (Tenderlove)

Actually, I think he's sort of on vacation from Rails for the most part. He's got Elixir to work on.

As for the matter at hand, Bundler author Yehuda Katz said that checking in binstubs is actually not a good idea and is not recommended. DHH is going against the grain here.

Aaron and Yehuda are the only two people on both teams, Jose is on Rails Core only. He is also a maintainer of Bundler, as is Terence, who is also on the thread.

"37Signals hasn't been the forefront of web-app design for a few years now."

Exactly.

This shift isn't just "single page web apps" either. It is a generational shift. When people say "apps" now, it isn't a "web app". For all the thousands of hours of experience DHH says he has, it is stuck in a very narrow view while the rest of the world has moved on.

That's ok though. The neat thing about open source is that developers and users do not have to suffer dinosaurs for long.

It does mean that I can no longer depend on my Rails skill to put food on the table. Recruiters, desperate for Rails developers, will no longer be knocking on my door. It's a good thing I've been laying in the groundwork for the inevitable irrelevancy of Rails.

"The rest of the world has moved on"?

Good lord man, there's more than one way to skin a cat, and the web is not simply "apps". If you think Rails is irrelevant today than you are practicing fad-driven-development moreso than developing any real insight about the lay of the software land.

Yes. The rest of the world has moved on. If you've characterized what I am saying here as "web is simply apps", then you do not understand what I am saying.

I've written this in one other comment, I suppose I will repeat myself:

(1) There are more mobile units being sold than personal computers.

(2) More importantly, there are 2 year olds whose first experience with a personal computing device will be a smartphone or a tablet. When the start going to school, they will be forced to use a keyboard and will resent it. They will see this as a problem to be solved, and will solve it. This is a generation gap, something between 10 - 18 years from now.

(3) Our generation tend to think of the "web" as experienced primarily through a desktop or a laptop. We also like to think that we are at the cutting edge. We are not: these two year olds are.

(4) Rails is designed and used by people who experience the "web" through a desktop, and refuses to see where the world will be heading in the following years.

There are a lot more.

So yes. The direction Rails is going will lead it to its irrelevance.

You're backpedaling.

How am I backpedaling?

Sorry I was severely jetlagged when I posted that and don't remember wth I was thinking.

At any rate, I don't see mobile-first making Rails irrelevant. Rails has never been cutting edge on front-end development except at the very very beginning when they bundled the brand-new Prototype library. But by the time they hit 1.0, seven years ago or whatever it was, they were already going down dead-end alleys like RJS in an attempt to avoid javascript. Since then Rails hasn't done anything amazing with front-end development, but they've stayed relevant in their own way with the asset pipeline, coffeescript, and generally staying out of your way to implement whatever front-end strategy you like.

Server-side development isn't going anywhere, so I don't see how the shift to mobile makes Rails irrelevant.

I agree, this is a good example of why I think the complaints about criticism in the open source space need to be put back in check. Some are deserved, but these guys aren't trolls or well-intentioned idiots they're all trying to build the best rails they can.

I've been in and witnessed plenty of disagreements in closed source development, they always get much much more heated than this before someone pulled rank.

>I read that entire comment thread, and maybe my perspective is skewed, but I saw none of the behavior that DHH described there. The discussion was generally polite, the participants were mostly experienced Ruby developers with open-source and community track records, and their objections were well-supported. I have less sympathy now for the original post than I did.

My thoughts exactly. I read the DHH post first and thought, "I totally agree. That's why I like rails."

But the thread was perfectly civil and the people in it were experienced and well known in the Ruby world.

I think the analogy broke down somewhere in the upscale restaurant analogy, but let's continue with food joints.

In a town where you have only 1 big cafeteria (Rails), a pizza joint (Sinatra) and a few tiny snack stands, if you have friends, you'd probably have to get with the gang and head to the cafeteria for lunch. Now when the head cook decides to not offer disposable utensils anymore because of environmental concerns, but then the large Jewish community complaints about the bowls aren't kosher, then the head cook comes out and post a notice on the entrance that says, "If you can't eat out of the bowls I cleaned, get out of my cafeteria." Ok never mind, analogies can only work up to a point, it's almost 2013 and the world didn't end, chill out Rubyists...

>What is this post responding to? And who is the target audience?

People making comments like yours? E.g

>Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. We get it, Rails is "opinionated", sorry I guess we're saying "omakase" these days. Who really gives a fuck?

Well, a lot of people don't give a fuck, and that's the problem the post addresses. They want Rails to not be opinionated, or to cater to _their_ opinion.

>The reason DHH is getting loud complaints is because people feel that they carry a legitimate grievance but also feel no way to voice that opinion (or are trolls). Douchetastic talking down to them like exemplified in this post won't help (and will encourage trolls).

I don't see anything bad (sorry, I guess we're saying "douchetastic" these days) about the post. Sounds like a legitimate complain from the creator of a popular framework.

I also fail to see how people feel they "carry a legitimate grievance" but at the same time "feel no way to voice that opinion".

If they don't participate in the Rails project, then, no, they don't have a "legitimate grievance". They just have a personal grievance.

If, on the other hand they do participate, then they have lots of ways to voice their opinions.

I also fail to see how people feel they [...]

This is the kind of thinking I was referencing. You don't see it because you're not in their shoes, that doesn't mean it doesn't exist. It's fine and all that people do disagree, that's just the context for my post.

If you want someone to see things your way, build a bridge over the gap in their misunderstanding. DHH's blog post its just preaching to the converted. That's why I asked the context and audience. Saying "Rails is omakase" is a lot like saying "git stores a directed acyclic graph of revisions" or "A monad is just a monoid in the category of endofunctors". Almost nobody gets it unless they already get it, and the behavior he seemed to be complaining about was critcism from the unwashed masses. It just doesn't fit. I asked who gives a fuck because what small sliver of his audience is going to both understand what he is trying to express AND take anything new away from the post?

My initial read was wrong, because (to stretch his abused metaphor) he is actually talking about the fact his chefs and regular customers really seem to think 2 tsp of spice in the soup would be better than the 1 tsp he is insistent on using. Which makes his post make even less sense. He could have have ditched the flowery prose, meandering critcisms of criticism and just said "This is important to me, I'm pulling rank."

Maybe it's just something to link to when people complain to him about coffeescript (or any other Rails default) for the umpteenth time.

> If they don't participate in the Rails project, then, no, they don't have a "legitimate grievance".

Why don't non-contributing users of a software project have a 'legitimate' opinion?

I wonder if this attitude in the late 90s / early 2000s accounts for Linux's level of success as a desktop OS.

>Why don't non-contributing users of a software project have a 'legitimate' opinion?

Because their opinion gets any legitimacy only by what you paid for it, either by money or work.

Some core developers of OSS are accommodating enough to listen to the opinions of random users, but this only happens if said developers are either:

1) really nice guys than enjoy the interaction and/or pushovers.

2) getting something back from it (i.e they play nice because they also sell support or extra stuff and don't want to alienate potential customers)

Other than those 2 cases, non-contributing users can have whatever "grievances" they want, but it means nothing at all.

And that's exactly the reason Linux never took off on the desktop. It's very difficult to gain new users if you're constantly dismissing them and asking them to put up or shut up with code.

These things aren't built for users, they're built for developers scratching their own itches. DHH built rails for himself first, and happened to share it for those who like his way of doing things. If you don't like his way, use another framework.

>And that's exactly the reason Linux never took off on the desktop. It's very difficult to gain new users if you're constantly dismissing them and asking them to put up or shut up with code.

And it's also why lots of OSS developers could not give a flying duck is Linux took over the desktop or not. They do it for their own fun and benefit, not for some entity called Linux to gain market share.

That is a completely understandable view and one that I hold myself. However, it's difficult to hold that view, and then simultaneously complain about things like driver support, which only come from attaining a modicum of popularity.

> Because their opinion gets any legitimacy only by what you paid for it, either by money or work.

I think this confuses validity of opinion with obligation. Certainly nobody from Rails has any obligation to a stranger. But it's another thing to tell Rails users their opinions are invalid.

For the record, I run a reasonably sized OSS project and constant get bombarded for feature requests and free assistance. I'm not a pushover, I don't sell support (although I've been asked to) but I am polite to people and I do believe user's opinion carries some weight, because I want my app to be successful.

I know very little about Rails. It's just that 'Rails is Omakase' reminds me of 'Debian is By Developers for Developers', which didn't work out well for the folks that wanted Debian to take over the world.

I really don't understand this point of view - why release open source software if you don't care about your users, and only care about your contributors? To me you'd be better off NOT releasing it, and just keeping it all wrapped up and closed, then you wouldn't have to deal with the non-contributing users who want changes.

This is one of the fundamental problems around many (most?) OSS projects. The elitism that comes with believing you are somehow better than everyone else because you contributed, or started an OSS project.

This attitude also stumps your growth - many people who probably would contribute often end up staying in the shadows, not wanting to look stupid, or offend the sensibilities of the OSS team.

Perhaps a more welcoming attitude might not only make people more supporting of OSS, but might find you some more willing contributors as well?

What are you building open source software for, if not to be used by consumers? If you're building it for some sense of self-aggrandisement, why make it open source in the first place? Just keep it nicely closed, so that only the elite chosen few ever get access to it, and keep out those who's opinions apparently don't matter.

Open source (for many) is a way to pay it forward, and give back. Kinda strange that the very people you're supposedly helping by providing free software don't matter.

>I really don't understand this point of view - why release open source software if you don't care about your users, and only care about your contributors? To me you'd be better off NOT releasing it, and just keeping it all wrapped up and closed, then you wouldn't have to deal with the non-contributing users who want changes.

What is there NOT to understand?

You release it, because (not all at the same time):

1) You want and value the CONTRIBUTING users (that's your actual software's community).

2) You want it to be used by people but as it bloody is.

3) You want to make money off of it, and think the open source + support/extra services model works.

What I really don't understand are the complaints. Isn't one of the core benefits of open source that you can _change_ the source? If you don't like what DHH is doing, fork rails to your liking. But no, they want it there way AND in the upstream repository.

> Because their opinion gets any legitimacy only by what you paid for it, either by money or work.

I'm sorry, but that is just fallacious. There are plenty of people who aren't involved in any given project, but would still be qualified to give decent advice.

Developers should consider random opinions, just not if they conflict with the direction of the software. If a number of users have similar grievances, that is an indicator that something needs to be fixed, or maybe the direction of the software should be changed slightly.

That's if the developer intends the software to be widely-used, of course

>I'm sorry, but that is just fallacious. There are plenty of people who aren't involved in any given project, but would still be qualified to give decent advice.

It's not about qualifications. It's about the willingness to hear them. I'd rather write my OWN project, MY way, that a better project in some other's terms. That's why people start their own projects after all.

So, the might be qualified, but the open source project creator could not care less about their advice, valid or not.

He might have his own opinions and long term ideas about the project. He didn't start to write software to be a slave to other people's ideas.

If he _wants_ other people's opinions, he'll ask for them.

And if he, like DHH, even posts a lengthy blog post telling them to shove them, then it's clear that he doesn't want them in this particular case.

>That's if the developer intends the software to be widely-used, of course

Developers can also intend for their software to be "widely-used" but only if it's _in their own terms_.

E.g RoR is widely used just fine, for example, despite being "opinionated".

So, "wanting your software to be widely used" does not necessarily imply that you "should consider random opinions".

It's contradictory that you would do whatever you like regardless of anyone else's opinions, ever and expect your software to be used by a large number of people.

Obviously you aren't obligated to accomodate anyone when you are doing your own project, even if you are doing your own project and then making it available publicly. But acting like a tiny dictator on a power trip is not the correct behavior if your purpose is to make a tool for public consumption.

If you want to "write your OWN project, YOUR way" you are not making a public tool, you are making a private tool that is available publicly.

>It's contradictory that you would do whatever you like regardless of anyone else's opinions, ever and expect your software to be used by a large number of people.

Who said you expect or want "a large number of people" in the first place?

You might put your project out there just for the potential valuable contributors to help with the code, not for the end users.

And one can imagine someone creating something unique with no regard for what people are saying, and still expecting them to embrace it. Because he thinks his vision is perfect or better than what exists. Kind of like Ford's quote "If I had asked people what they wanted, I would have given them faster horses".

But the problem with all the above is the absolutism. You don't have to "_never_ listen" as you imply. A project leader might listen to user opinions sometimes, and don't care at all about their opinions on other aspects of his program that he feels adamant about.

E.g it's not like DHH _never_ listens and does whatever he likes "regardless of anyone else's opinions". He only does that for FEW aspects of the project.

>If you want to "write your OWN project, YOUR way" you are not making a public tool, you are making a private tool that is available publicly.

Yes. A lot of projects are like that and people should understand that and respect your decision, instead of bitching about it.

You are the one that stated absolutely you shouldn't listen to random opinions, with rhetoric such as "If he _wants_ other people's opinions, he'll ask for them" and "developers can also intend for their software to be "widely-used" but only if it's _in their own terms_."

I don't see anything bad (sorry, I guess we're saying "douchetastic" these days) about the post.

"My pet theory is that it feels like meaningful activism in the moment. They haven't really paid much attention to how things are run on a day-to-day basis, but here's an opportunity to paint some signs and get on the barricades. Yeah, I've done my part! I've taken a stand! Down with.. uhm.. Turbolinks? Or was it CoffeeScript we're protesting this week? Or Bundler? Oh fuck it, down with SOMETHING! YEAH!!!"

I mean, you really don't see this as douchey or talking down? How? To me it actually seems impossible to read that and say "Sounds like a legitimate complaint from the creator of a popular framework" unless you already had your mind made up DHH was right no matter what.

you're completely passing over the fact that there are people with illegitimate grievances, the response to which genuinely should be "well, don't use rails then". i thought dhh's post provided a good analogy for people who don't get that on a software stack level to relate to.

So? There are tons of people, including both rails core and ruby core contributors with legitimate grievances, in the exact thread in question, that are lumped in with this group DHH is mocking. Its an absolutely terrible analogy and is completely disingenuous to the current situation.

This summed it up best in my eyes:

"Reading this feels exactly like reading the passive aggressive facebook posts of someone currently in a fight with their boy/girlfriend. "

If you follow the mass of Rails community, you'll get it. Mostly. And perhaps this piece also explains how painful and yet very commonly faced situation (being trolled with expertise) this if for most open source creators/leaders in their line of work.

A sort of professional hazard.

Sooner or later, this has to get better I am sure.

Reply on news.ycombinator.com