Anonymous Open Letter to the Ember.js Core Team
gist.github.com
gist.github.com
(Both the open letter and the response from Tom Dale seem to acknowledge that there's two sides to this issue, which is refreshing. Usually you get these really boorish "dude, it's open source, just fix it yourself will ya" responses.)
It makes me wary of pushing any of my projects. I still open source pretty much everything I do, but usually with a big fat "for your edification, don't expect any support or ongoing development" disclaimer.
(Also see fat's "What Is Open Source & Why Do I Feel So Guilty? at http://www.youtube.com/watch?v=UIDb6VBO9os)
If there is no affirmative declaration of "I will be actively supporting this beyond my own personal needs" then assume that the code will not be supported beyond the personal needs of the project owner.
Or people can just ask, instead complaining (however well-intended) that their assumptions have turned out false.
This is like people who build a business on some aspect of Twitter or Facebook then complain that Twitter or Facebook is shutting them out. If you are using someone else's code or API make sure you get some positive, unambiguous statement from the owner about what to expect.
Things can still go south, but then you at least have a legitimate gripe.
Edit: BTW my money is ready and waiting!
*.github.{com,io}Why show the domain at all if you can hover over the links? For a minimalistic interface like HN you'd think there would be a reason for it. And if people are identifying content based on that URL, it's probably best to make it descriptive when subdomains have very different content.
Plus, many touchscreen devices don't have an easy way to see where a link is pointing to, even on devices with 'hover' functionality.
Ember is actively trying to compete with angular (backed by google) and others - and I think the people rooting for ember are just people feeling let down after deciding to move forward on it in production.
edit: Tom's actual quote: "trying to solve are novel computer science problems"
At the very worst, it lets the devs know where the users want new features. At the very best, it helps crystallize aspects of the problem that make a solution easier to find.
User feedback is always a gift. Even if they are yelling at you, they're giving you valuable information.
1) Require the code to be consistent. Tell the submitter how to do this.
2) Merges have to be straight forward, or you don't accept the submission. I think Linus Torvalds has the same strategy for the kernel - you figure out the merge, I'll accept it.
3) That depends a lot on how you set up your tests and documentation. If you make it simple to write both, it's simple to require them. If they're not simple, you should make them.
They might actually be one of the contributors.
I'm trying to come up with similar software schisms: vi vs emacs? GNOME vs KDE? Linux vs BSD? C vs C++? C++ vs ObjC? All of these differences sound more substantive to me.
Unfortunately, that seems to lead to a lot of acrimony between them. I wonder if a big part of it is that each side is convinced there won't be space for both in the future, and that a clear winner has to be declared - which I don't think is true at all. This town is certainly big enough for the both of them :)
As for drama within the Ember community itself, that's a little more complex. I think a big part of it is that Ember seems to have a lower barrier to entry than Angular at first glance, but certainly has its own catches and hang-ups, and running into those when you thought you had found a holy grail can be extremely frustrating.
Angular.js OTOH is run by Google, and like everything done by Google is part of their strategy to collect data and increase advertising revenue.
I think the approach of something like jQuery works best: do one thing well. Add polish, not features. Let other people start their own projects that extend yours.
A way to scale back expectations even more is to provide sample code, not a drop-in library. If you want to use it, copy and modify it so you know how it works and can fix the bugs yourself. This ensures that people don't think of themselves as just users.
If you want a framework that can be used for a large, complex project without you having to do infrastructure work yourself, then you have to use a framework where someone has already done that, and there's an established organization that's in the "fixing little bugs caused by slight variations in developer use cases" stage. End of story.
Various posts have made the front page here and I don't recall many (any?) caveats saying it's only for thrill-seekers, either.
I can easily imagine certain future employers seeing the author because of this rant / critique as a liability.
Tom Dale said it himself, ember doesn't have enough manpower. I find it odd, that Dale & Katz, are unable to raise funds to increase the level of manpower on it. A simple kickstarter may help.