Please excuse the language, but what the fuck is happening to our world right now?
What the hell has happened to "I want to build something, so I'll build it"? Now you have to [1]pay $100 for the privilege of reading the mailing list for an open source project? And some guy needs $25,000 just to start it?
Guys this is...not good. Can you imagine if apache's kickstarter never got funded? If the linux kernel's didn't? What if MySQL didn't properly manage their prize levels? Now it's "I want to build an alternative social network. Bootstrap me with $200,000" or whatever that was.
Kickstarter is really cool for a lot of things, I see it [and contribute to it] for large-scale art projects (burning man), but now every hacker I know has got a $25,000 wall in front of them called "kickstarter" and they don't want to start working until they scale it.
Stop this. This is really bad.
[1]: From the page: > [$100 gets you] access to the internal list for the project, where I'll be soliciting feedback about how to nail this. Great open source projects rarely come from the ideas of just one person, and your input will guarantee that Rails 4 is as great for beginners as it is for experienced developers.
What the hell is this? I have to buy a ticket to "help steer the project"? What happened to community? We're charging a cover at the door now?
Let me get this straight: so a prolific, proven open source contributor makes some money, and the community gets a problem fixed. This is a bad thing? Who loses here?
What if Yehuda's company gave him 25% of his time to work on open source - would that be different? He'd get that same $25k (or whatever), and the software would get built (and open sourced). Only difference I can see is the source of the money, so are you against the idea of companies letting their devs work on open source?
There's this attitude in the open source world that somehow developers getting directly paid for open source is evil. This is -- excuse me -- fucking bullshit. I can't think of anything better than the idea of developers getting paid to write open source software. We need to grow the hell up and understand that paying developers to write open sourced software is a good thing -- open source devs get money, and the community gets software. Again, who loses?
I don't use Rails, and I probably never will, yet I kicked in some money to help see this through. I can think of about a million worse ways I could have spent that cash.
There's no problem with open source contributors making money from their work. The problem is, there is a chance that this subtle change in perspective will evolve into an unhealthy culture.
Especially since this is coming from Yehuda Katz. I've seen several people using things like Gun.io to fund patches and small additions to open source libraries, but it always seems to come from people you never see in the community - outsourcers, or people who just aren't that into coding but still code. But once a leader in the community does this... It's up in the air what this will do long term.
Here's one possible outcome. It becomes "cool" to crowd fund open source projects, so a few of the up-and-coming coders with new open source projects start doing this too. In a year or two, a big chunk of the top coders are charging to do open source work. It's a badge of worthiness... Coderwall.com get's it's "$25k+ achievement" badge.
Then one of two things can happen. The unlikely thing is, it evens out, there's a happy balance - some people charge, some people don't. Much more likely is people either start charging ridiculous amounts, the quality of free open source projects drastically decreases, or people start keeping their projects to themselves. This eventually leads to rebellion, and the true ones left start ANOTHER Free Software Foundation that gets back to the roots.
This kind of stuff happens, out of seemingly innocent and well-intentioned moves.
Like everyone's said, companies like 37signals and all the companies we work at fund open source projects, so one way or another we're getting some sort of payment. It's totally cool to make money off your open source work like this, nobody really sees it even though we all know. It's this indirectness that keeps the community healthy. It creates a feeling of open-ness. A culture. Asking for money directly like this doesn't make things feel open anymore, and like everything it will spiral.
I, for once, don't see a problem with getting paid doing open-source software.
With kickstarter I get an assumption that if for some reason he won't raise enough money - he won't work on the project. That, in my opinion, is wrong. It shouldn't matter if one raises money or not, as long as you like what you're doing. Otherwise why bother in the first place?
Opportunity cost. If the world can't come up with $25k to fund this project, then it must not actually have enough of a market to be worth Yehuda's time. He can go find something else to do for $25k worth of his time that will likely benefit someone more than this would have.
It's not like we're investing $25k of angel funds to have him build something that he is then going to sell for $500k without sharing the profits. We're simply paying the living expenses of someone who wants to solve a perceived need for the development community.
This might just be me, but here's my point of view: I like writing software. It's pretty enjoyable. But you know what's more enjoyable? Eating. Having a roof over my head. Being able to pay for my wedding without selling any major organs. If the time I spend writing software detracts from those other things, I'm sorry, but the software either has to go or has to pay for itself. If you want to be absurdly altruistic, you are free to do as you will, but I don't think it's reasonable to demand it from Yehuda, especially as he's already given so much.
I agree...I don't use Rails for production work (yet); however, I dig what is going on here and I've also donated. The Rails community definitely takes care of business and seems to have a much more entrepreneurial spirit than most (if not all) other dev communities that I've witnessed. I'll have some of that please!
The problem here is the ego, you have to notice how Yehuda put an accent on how important his contributions to rails 3 were. I'm not arguing they're not, but as Plato put it, when you think you reached the absolute wisdom you couldnt be further from it
Oh, I see. So the problem isn't that Yehuda's asking for money, but that he had the temerity to state his qualifications.
Again, we gotta grow up. Yehuda's contributions to Rails 3 were important. What's wrong with taking credit for that? I'm often critical of the Rails community for an excess of ego, but this is not one of those cases.
It seems pretty clear that the idea of an open source developer asking for money seems vaguely filthy to a bunch of people. I think this is unhealthy and poisonous. It condemns open source to be the provence of academics, the unemployed, those able to snatch free time away from their friends and familier, or those working at the largess of their corporate employers. That's a shitty limit on the scope of free software.
I read the accent as being on his track record of delivering on open source software efforts. In other words, he's demonstrating the soundness of investing your money toward his goal. Regardless, count me in.
Part of using Kickstarter (and IndieGoGo, and the others) is establishing that you're qualified to do what you say you'll do with the crowd's money. He did exactly what he was supposed to do.
What this is is Yehuda Katz, who has built a reputation with contributions to open source products over many years, realizing that his market value is better than "kudos" on some website.
The alternative to stuff like this is Yehuda Katz writing code for some startup that you will never see. Here's Katz finding a way to make a business out of writing open source...
... and this is a bad thing? What's wrong with you?
You seem to forget that he has almost always be paid for his contribution:
* Merb / Rails - EngineYard
* Sproutcore / Ember - Strobe (and via contract work)
I myself struggle with the concept of asking $25k to build what he wants to build. But at the end of the day what I think doesn't matter what I think or how many people disagree. If enough people agree with him and support him, then the project will happen. If you don't like the idea, just don't give your money.
If you are worried this attitude becomes a trend then be active and release your stuff differently.
If Yehuda Katz' market value is too high to build this kind of thing without sponsorship, then maybe someone else can build it gratis and he can save his time and energy for paying work.
Lots of companies hire people to work on open source projects. It is how most of it gets written. He could probably get a job where working on this is part of it in a heartbeat.
(not that I disagree with this project or method, I think he should do the same as what Google Appengine does with its installer - it is seriously awesome)
Though I'm quite thankful Engine Yard chose to fund his work, I'd categorize doing so as an investment than a generous act. Nothing wrong with either, of course.
I would certainly agree (especially his work on Merb, since they began offering commercial Merb support and such while he was doing that). The "generously" was partially true, partially facetious. :)
A lot of programmers have hangups about money. Consider whether you do as well, and if so whether this is something you've purposefully chosen because you really like what it does for your life or whether it is just accidental. If it is accidental, you may want to consider stopping.
a) $25k is not a lot of money for very well-known programmers. There are fairly straightforward methods to get that much in a month (a salaried job), a week (contracting+), or a day (training event, $500 a head).
+ Stipulate that in addition to Rails he has at least one talent which makes money and this is not unreasonable at all.
b) There was no time at which OSS was not predominantly the work product of the global rich employed at corporations. This is observably true for Rails, since the list of contributors since DHH extracted it is both public and short. The Rails core team works on Rails like it is their job because...
c) ... Rails was designed to, and succeeds at, making companies great piles of money by increasing the efficiency at which they can churn out CRUD apps. Please note that is in no way a criticism. Apps running on Rails go from BCC (five figures a year) to Basecamp (eight figures a year and will probably hit nine eventually unless they already did).
d) OSS developers making money by it - I.e. The traditional accepted way to write it - does not make you personally worse off, because it increases software available to you. You may perceive that people will listen to you less because monied interests will drown out your voice. This is irrational: since the $100 you think is a lot of money only buys maybe 30 minutes of programmer time anyhow, the opinions that mattered in OSS were already those of companies which coul actually pay salaries, and someone freer with their last $100 than you are will only have epsilon more impact on "the community" than you when compared to IBM (a consulting company which staffed most Linux development) or Google (an advertising company which directly or indirectly pays the salaries of the majority of programmers working on either of the two big OSS browsers.) apache's Kickstarter was IBM realizing that they'd happily pay a billion dollars to have IIS not become the dominant server platform so they proceeded to do so.
a) $25k is not a lot of money for very well-known programmers.
What if Linus said, "I have this great idea for a version control system, but I need the community to raise $100k to make it happen"? Of course he would never do that. The reason for making git was to give the kernel project what it needed for a version control system. Linus' time is at least an order of magnitude more valuable than Yahuda Katz' time. Just as git arguably makes the kernel project more successful, rails.app ought to make Rails more popular. Wide deployment of Linux in turn makes Linux developers' skills more valuable, just as wider deployment of Rails enriches Ruby developers.
c) ... Rails was designed to, and succeeds at, making companies great piles of money
d) OSS developers making money by it
That can be said for just about any popular open source project used in the business world.
Why? Maybe he was paid by the linux foundation during that time? Other sources of income? The gratuit "of course" is not clear to me.
Maybe I'm misunderstanding what you try to say, but:
" rails.app ought to make Rails more popular [...] wider deployment of Rails enriches Ruby developers". Are you saying that Yehuda should not make money from his efforts, but the Ruby developers in turn can use the results naturally for their gain?
Why? Maybe he was paid by the linux foundation during that time? Other sources of income? The gratuit "of course" is not clear to me.
And Rails is sponsored by 37Signals. You'd be hard pressed to find very many large open source projects without commercial backing.
Are you saying that Yehuda should not make money from his efforts, but the Ruby developers in turn can use the results naturally for their gain?
That is generally how things work. Companies specializing in open source technologies have a business interest in their specialty software(s) becoming more popular. A core Rails developer will command the highest speaking and consulting fees.
I think the reservation many people have about all of this is that it feels backwards. Asking for sponsors is one thing, but making the open source project pay-to-play flies in the face of the spirit of FLOSS.
What is "FLOSS"? Free/Open Source software? The fact that you can't even refer to it without an acronym that conflates two opposed philosophies suggests that maybe the "spirit of FLOSS" is less well-defined than you think it is.
In any event, it is better than Katz should work directly for people who are going to use his software than that he work for some giant company that incidentally finds it valuable to task him with something useful.
At the same time I do not get how this is a problem for people to accept wrt software, while it is the common suggestion to artists in copyright questions on HN: go crowdfunding!
Just chiming in to say that Yehuda Katz has given away so many work hours to Ruby, Rails and JavaScript projects - Thor being one of my favorites. If he decides to raise $25K to work on some open source project, he's more than earned the right to do so.
Another point worth making is this: let the market decide. If the market will bear $25K (one-time payment) for a Rails.app, then so be it. Your opinion doesn't matter, frankly neither does mine.
I don't really see this affecting open source projects either. You've always been able to make money from free (as in beer) open source projects (directly or indirectly), even for projects that are not widely used.
Patronage is a model that has existed as long as artists. You wouldn't be able to go see Michaelangelo's work without this model. But people have, and do, paint for free, too.
I don't see why it's a bad thing that in modern times, skilled and famous artists continue to do work for hire. The fact that Yehuda is asking for crowd funding instead of funding from an individual is just in the details.
This is something that would be personally valuable for me. He could just as easily build this and sell it on the App Store; I'd buy it too. Instead I'll donate so you can get it for free.
Who says OSS has to be all about altruism and self-sacrifice?
I fail to understand why some programmers don't like to see other programmers get paid directly for their efforts.
If open source work is not paid for directly, it is paid for by corporations. Even when people do work in their 'spare time', it is being subsidized by the corporate job that puts food on their table.
Arguing against directly funded open-source is tantamount to arguing that developers should only be able to make a living working for a corporation.
There's nothing wrong with choosing to work for corporations, but what's wrong with having alternative economic mechanisms as well?
As far as I can remember open source always has been a sponsored or subsidized undertaking as far as it concerns meaningful or central projects.
Without it, the linux kernel would be only teaching material on Finnish universities, MySQL would not exist, Erlang would be a Danish mathematician and a waiting cue formula. The basis for the ASF is the web server which was developed at the NCSA. So you're on the right track with the "Can you imagine..." question.
Whats wrong with someone who want to make a meaningful addition to OS and asks money to be able to give full attention to the project? Isn't that more realistic than to hope for loosely coordinated efforts of spare time developers?
[note: I use this term not to criticize the persons in question but to point at the focus of the contribution. Also scratching-own-itch projects can easily err on the wrong side of the pareto ratio]
No, the amount is a donation. Are you saying that people who donate to apache foundation dont have influence? you are living under a rock if your think that in open source money plays no part.
Sure you can fork an open source project and request a pull, but if the core team disagrees with it then its all the same as the above.
Kickstarter is simply a marketing technique to raise the funds from an eventual corporate sponsor I bet.
There's a lot of "you don't want someone to get paid for their work" replies to this comment. But the OP has a really good point:
> [$100 gets you] access to the internal list for the project, where I'll be soliciting feedback about how to nail this. Great open source projects rarely come from the ideas of just one person, and your input will guarantee that Rails 4 is as great for beginners as it is for experienced developers.
That is a non-starter.
This is also not a $25,000 project.
I admire and am thankful for Yahuda's contributions and I'd have no problem funding a "Yahuda should get paid" Kickstarter but this particular project is lame.
well said. when i saw the link i was confused why this would be on kickstarter...just feels odd to have software development on KS, unless there is some extenuating circumstances..
As much as I like yehuda, he's tackling a non-issue here and I'm at a loss to understand how he even arrived at the project scope as he describes it.
Installing Rails on a Mac is largely trivial. It's literally 5 shell-commands, depending on the current level of breakage of rubygems (but that's a different story). Write a tutorial in your blog if you really feel this is hard for newbies.
The hard part is installing the exact same Rails on multiple Macs and deploying the exact same Rails to production servers that are not Macs. And when I say "Rails" then I mean the entire dependency chain which reaches far beyond Rails and Mysql. The hard part is having controlled service startup/shutdown scripts that work locally and across any number of servers in your production deployment. The hard part is configuration management and safely toggling dev/production/staging modes across all involved services. There's lots of hard parts; bootstrapping a vanilla rails is not one of them.
In fact: Naive bootstrapping can be harmful, just like the still virulent code-generator brain-rot in rails itself.
I make a living managing these things and have evolved multiple approaches ranging from chef/puppet, over canonical git-repositories that work cross-platform, to VMs. There is no one-size-fits-all once your stack outgrows Rails+MySQL, and it always outgrows that.
If you wanted to solve the real problems surrounding all this then a single-platform bootstrapper is nowhere near cutting anything.
For that you'd have to start writing a better chef/puppet, which are indeed more than ripe to be superseded. But this is far beyond the scope of a kickstarter project and I hope Yehuda will rather keep his focus on Ember...
As you pointed out, your problem and the problem he is trying to solve here are completely different. Your problem definitely exists, and lots of people are working hard on solving it, whether that means those working on improving chef and puppet themselves, or on other less flashy configuration management systems, or on new projects that are attempting to improve on the existing solutions in a more fundamental way. Presumably Yehuda is simply less interested in contributing to that work than in trying to solve this other unrelated problem. You may argue that this problem does not exist, but the many articles decrying how hard rails has become and the competing projects that are also working on this suggest that you are wrong.
Also, it's way more than 5 shell commands and even if it were only 5 it would be worthwhile to make it easier.
4. mkdir proj && cd proj && rbenv install 1.9.2-p290 && rbenv local 1.9.2-p290
5. gem install rails && rbenv rehash
6. rails new foo
Honestly, we can argue if this was 5 steps or 8. We can also argue if 'rbenv rehash' should be necessary (I'm not even sure it really is, wrote that down from top of my head).
But if someone fails on these instructions that fit on a Post-It™ then they should overthink their ambitions towards a programming career.
And if they run into bugs during that procedure then these bugs must be fixed. Because this is (and should be) the canonical way to install a vanilla Rails on OSX.
Dude, take a step back and forget that you know this stuff already and do it professionally. That list is not easy and far from obvious, even for real programmers coming from other environments, let alone for actual programming beginners.
Your list is far from canonical even at this very moment and hasn't even been common for very long. To figure out your list, I have to:
1) know that homebrew is the "right" way to install software that rails depends on, rather than MacPorts or Fink, or the Mac app store, or download.com, and oh yeah, there is this thing called sudo, and I should install homebrew recipes using it, or should I??,
2) know that rbenv and ruby-build are things that exist and that they are competitors to RVM but are either more or less in vogue depending on who I talk to,
3) understand that rbenv doesn't just work in the current shell without closing and re-opening it,
4) know that the "right" version of ruby to use is 1.9.2-p290 (I have to know the patch-number?!) and that I need to install it and set it as my local version (wait, what does that mean, why do I need a local version?),
before I can get around to actually installing rails and using it.
Now, I could just blindly follow someone's list from a blog post (randomly chosen presumably, because the theory here is that I don't know enough about these things to make an informed decision). Maybe I would even get lucky and find a list that works properly with the version of rails that the official documentation is talking about, but it would still be a much better experience by far to go to the official rails site and be told: "hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!".
No. You have to know none of that. You just have to copy/paste the steps from the rails-homepage (where they should be prominently listed, the lack thereof is the real bug).
"hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!"
Wait, how is that different from above?
Yes, you may be done 2 minutes faster. But you just deprived yourself of at least getting a glimpse on which parts are involved, even if you don't understand them yet. That means you're now even more hopeless when stuff breaks later (and stuff always breaks later).
And as a fun fact: Any sane bootstrapper would use the exact same script behind the scenes anyway. There simply is no other way unless you plan to re-invent homebrew and rbenv along the way.
I'm really troubled to understand who we're trying to care for here. It sounds like you want to make this Really Easy for absolute beginners who can barely setup a printer.
That is a noble goal (for a printer driver), but if you want to teach someone programming then there's a point where you have to stop dumbing it down artificially. And that point is as early as possible.
The worst you can do to a newbie is to put him into an opaque sandbox with different behaviors and errors from what the "big guys" are using.
4. mkdir proj && cd proj && rbenv install 1.9.2-p290 && rbenv local 1.9.2-p290
5. gem install rails && rbenv rehash
6. rails new foo
-------------------
"hey, download this all-inclusive, up-to-date, guaranteed to work disk image straight from us!"
Wait, how is that different from above?
-------------------
Really? You really have to ask how those two processes are different?
"stop dumbing it down artificially"
If (sometimes competing) complexities weren't continually added, there wouldn't be a need to 'dumb it down'.
"(and stuff always breaks later)"
Wow. Most other web framework communities don't have that much problems with 'stuff always breaking later'. Maybe Rails has reached a tipping point?
"There simply is no other way unless you plan to re-invent homebrew and rbenv along the way."
Or until someone else does 'reinvent' one of those, and all the cool kids start using it, leaving everyone who learned the 'legacy' way out in the cold without an upgrade path beyond "start over".
with different behaviors and errors from what the "big guys" are using
I think part of the purpose of the kickstarter project is having one of the 'big guys' behind it. Supposedly that would mean at least one (or more) of the 'big guys' would indeed be using the same process as the 'newbs', reducing this chasm.
Sounds like you're threatened some by this - it was hard for you, therefore it should always be hard for everyone for now and forever.
Sounds like you're threatened some by this - it was hard for you, therefore it should always be hard for everyone for now and forever.
Yes, I'm threatened by this. But not in the way you think, because as shown above, it's not really hard. It's 5 lines. What's wrong with kids these days?
I'm threatened because I'm the guy who comes in to clean up after "junior programmers" who couldn't even be bothered to learn 5 lines to install their dev-environment and who consequently also don't have the slightest clue about basic realities such as "diskspace is finite" or "No, /Users/Bob/rails/tmp is not a valid path in production".
At least give the kids a chance to learn. Don't lure them with shortcuts that result in unsustainable habits that cause great frustration in the long run. Unlearning is harder than learning.
Rails with its false sense of simplicity is breeding plenty diletantes already as it is. We need less of that, not more.
It's not "5 lines", and it's not about "junior programmers". My designers need to work with my Rails apps, and learning the intricacies of setting up a Rails stack is not their job description. Just like maintaining their dev environment isn't mine. There's a bigger issue here than "those kids will never learn things the hard way".
Would you mind scrolling up to my original comment where I posted the exact 5 lines?
My designers need to work with my Rails apps
Then you should have noticed that installing rails is the least of your worries. Database seeds, missing dependencies, test-users, broken fixtures, broken mocks, missing external APIs, version control conflicts, gem screw-ups, failing migrations, rails upgrades, differences to the production setup. Those are the daily timesinks over here in the real world.
The initial rails installation doesn't even register in the grand scheme of things.
I can't tell what you're actually arguing for or against in this thread. There seem to be two different things:
1) The rails.app project wants to solve a problem that doesn't exist. There are a lot of comments here from other people who think getting started with rails is confusing, and who point out that your much-touted five steps are not complete, canonical, or easy, so I won't further beat that dead horse.
2) There are many harder problems you'll come across when doing rails professionally. This is incredibly true, nobody disagrees, but it's irrelevant to the rails.app project.
Actually I agree with previous commenter. These steps are easy and only take like 10minutes and give great power handling versions and gemsets to projects.
If you are someone who doesn't know what it means you should learn. Isn't that what a programmer needs to do?
The steps aren't hard, it's knowing which ones to do that is hard. And yes, you should learn what all those things mean and why everyone does them, but it shouldn't be the very first thing you learn.
Reading your short list triggered a flashback. I struggled with everything you listed, probably more.
When I made a run at getting an existing RoR project running on my Mac (~1 year ago), there was no shortage of howtos and advice. The problem was resolving all the contradictory information.
As moe points out, the project home page should have the single source of validated truth on how to get RoR running on a Mac. Minimally.
That such a source of truth didn't exist led me to conclude that Rails was run by amateurs and to not be taken seriously.
I've just spent a few years being paid to maintain a lot of simple scripts exactly like this one, so I'm in a good position to say: These kinds of scripts really are incredibly simple. Until they break.
But, they break.
Would you like to start a pool on how long it will be until this recipe breaks, or becomes hopelessly obsolete because some portion of it is now out of date?
Hint one: To get an idea, one could try the problem in reverse: How far back in time can you go before you reach a time when this script would not have worked yet? (Hint one, sub-hint A: The first commit to Homebrew's Git repo was in May of 2009.)
Hint two: Homebrew formulae aren't guaranteed to build at all times. They sometimes have bugs, especially when any of their dependencies (including the version of OS X itself) has recently changed. Those bugs tend to manifest as scary messages from (e.g.) the linker.
Hint three: Better get that version number out of the recipe before placing the bet. 1.9.2-p290 could become hopelessly obsolete at literally any minute; we're always just one zero-day away. It would be more reliable to pull that number from some canonical source like… um, any ideas? What is the answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?" I don't know what your answer might be, but mine would be "pay someone like Yehuda Katz or the Rails core team to continuously recompute the answer, and to maintain the website that hosts the answer".
Well, that was the most reasonable response so far, at least you know what you're talking about.
But, they break.
The rails-answer would be "so is life". My answer is: Then fix it, damnit. Not you personally, but the maintainers. We must stop accepting constant wreckage as an inherent property of the rails-ecosystem. It is not inherent. Other systems such as debian APT work pretty flawlessly under significantly more complex conditions (thousands of packages on multiple architectures, for starters).
Isn't rails the one with the 17 different testing frameworks and TDD kool-aid?
How about adding structured tests for the installation procedure, too?
Keeping a ruby/rails installation procedure functional is not rocket science. And in defense of the actors: I do consider the current state-of-the-art (rbenv, bundler) to be fairly close to something that one could call reasonable.
Hint one, two, three
The exact same applies to any installer that you may come up with. It either has to perform the famous 5-steps behind the scenes, or it has to re-invent all the tooling that is only now barely stabilizing (square 1 again, really?).
answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?"
That is the wrong question. The correct question is "how do I install a self-contained rails runtime environment on my current machine" (which includes ruby and all core-dependencies).
The current answer is the above script. If the preferred tools change for a platform then update the procedure accordingly. Keep the current procedure in plain view in the documentation (Section 1: Installation).
It's not as hard as you make it out to be, really.
Install Xcode;
1) Install in App Store
2) Still not actually installed, start it, that finished the installation
3) You still don't have what you need, find where they've moved "install command line tools" to and install that
4)The compiler you have isn't the right one as Lion no longer has GCC as its default compiler and you want to use RVM
5) ......
Once you've done it a few times it's not that hard and you get used to knowing where to look for problems but the first few times it can easily be half a day lost just trying to get the environment working.
but the first few times it can easily be half a day lost just trying to get the environment working.
The above steps are reasonably robust and implicitly teach you things about your programming environment that you must learn (or at least have seen) as early as possible.
We should decidedly not dumb that down. There must be one canonical installation procedure for everyone and it must be as easy as above. There must not be "an easy way" and "a hard way". The above is as easy as you can make it without hiding crucial information from the user.
Rails has plenty of harmful padding already, we need less of that, not more.
You don't need to learn those things as early as possible. You need to learn them eventually, as you're getting closer to gaining expertise. Accidental complexity early along the road to expertise is a hinderance not a help.
The complexities of setting up a system so you can develop rails on it exist to solve problems that experts have discovered through years of working with the system, but which people coming to it fresh don't, and shouldn't need to, know that they have yet.
IDK. The barriers to entry for RoR on the Mac are pretty high.
I was keenly interested in an open source open government project (Sunlight Foundation). I tried to get it running on my Mac, on my personal time. I had direct expert help (friends who dev using Ruby, Rails, etc.). I understand the tool stack was churning, something about mismatched versions, runtimes, whatever.
I gave up after three weeks.
I don't care care how "awesome" Rails is. If it doesn't work out of the box, like all the LAMPs distros, devs will find something that does.
I hate Spring, Maven, ORM and all the other webby enterprisey Java crap with the passion of a billion burning suns. But the RoR nonsense was a whole 'nother level of insanity.
I'd rather take a bat to the face, or use PHP, than try RoR again.
(I should add that my bad experience was ~1 year ago. Maybe things have improved. Alas, I've moved on to greener pastures.)
I propose a different funding model for this project. Why not approach Rails hosting vendors like Heroku, Engine Yard, etc. to fund this project, in exchange for built-in one-click deployment to their hosting environment.
Would be a win-win for the user and hosting provider.
There is a slot on the donar list for larger sponsors. I like this model, because the demand from the community will encourage those sponsors to participate. It would have higher risk of return if it wasn't in this public space.
Yeah, it could also be an ongoing funding partnership. My impression would be that this is something that Heroku et al would be very interested in supporting, and even developing themselves.
It would also make an ideal teaching environment: getting students to learn to navigate the Rails installation is half the challenge of getting them started.
If there's someone I'd trust to do a project like this through Kickstarter it's Yehuda. And since his time isn't cheap I understand the $25,000 price tag.
To me the elephant in the room is simply would people do this for free like most open source? The Rails community is large and dedicated. If the core team started this as an official Rails project would the result be at least the same, possibly taking a little longer?
I'm interested in whatever Yehuda Katz comes up with, but I've been a Rails dev at a Mac shop since 2007? and I have never been too frustrated by getting Rails running.
Does anyone here have specific problems? From my experience, it really has been a matter of "gem update --system; gem install rails".
That'll throw a permissions error on a default OS X install-- and your Rails newbie will definitely not know that that means "you should really use rvm".
With that said-- a shell script that installs homebrew, git, rvm, the latest ruby, the latest rails, and a handful of useful gems, then drops you right into a shell of you brand spankin' new Rails (and Heroku!) project seems... pretty straightforward. Dealing with the common edge error cases and making it look nice and user friendly might take a couple hours. I'm curious to see where the time gets spent on this project.
Yehuda obviously intends to make it polished, useful and generic enough that it could be used for other players of the Rails ecosystem.
The Mac packaging itself will take some time.
Making sure that the project is versatile enough that it won't break but flex nicely at the sight of the next Rails release (or RVM or rubygems or whatever) in itself is no small feeat.
I've been a Rails dev since about 2007 as well and I've had some serious, serious problems dealing with Rails, gem dependencies, the version of RubyGems itself, and so on. rvm has helped a lot with that, but my last computer got so messed up when I upgraded to Snow Leopard it took me hours of configuration to get it working properly, and I had to abandon rvm entirely and start using rbenv. And then I couldn't work on half of my older projects.
In fact, it was so messed up, it motivated me to go out and buy a new Macbook (I needed a new computer anyway, but it provided a major impetus to go out and get one).
And that's just me. Even worse is the fact that I work on a lot of Rails projects with a designer who lives in Montreal, which is a good six hour drive from where I live. I've helped him get Rails set up on his computer, but it has not been easy - far from it. As a non-techie his computer is prone to all sorts of weird shit, he hates the CLI, he needs to be walked through, line-by-line, any situation involving some weird gem dependency nonsense - it's a horrible waste of my time. Imagine trying to debug someone's effed-up gem environment via a laggy screen-sharing connection while you're on deadline - it's awful!
To sum it up: this is a project worth supporting and I'm going to support it as soon as I click the 'reply' button on this comment form.
Lately it is has been getting a lot harder. The problem right now is that so many things have moved so far, that there simply isn't a known pattern that will work.
Generally speaking, you now need a compiler. If not to install something other than a quite old system ruby, then to install common gems like nokogiri.
XCode seems to change significantly every release. Not long ago, you had to download it, or get it from your system CDs. Then you had to buy it from the app-store. Then you got it for free from the app-store. Then you got the installer for free from the app-store, and had to run the installer. And today I think you get the installer, which you run, and then you go through a series of menus to get to "install command line tools" (like gcc).
Once gcc is there, then you need a ruby. There's RVM and rbenv. Those need to be found, installed (by running a curl command piped through bash), and then a ruby needs to be installed. I use RVM, which is easy enough for me, and it does install bundler by default (which is good).
Once you have a modern ruby, you probably want a database other than sqlite. For that, you usually need homebrew. Again, install homebrew, and then have homebrew install postgresql/mysql.
At this point you are almost ready to install the rails gem.
Oddly, a lot of the newer complexity has less to do with Rails, and has more to do with the Ruby ecosystem getting both older and more complex at the same time.
Every time I help a new developer get started with the rails environment, I too am amazed at how much has changed since I setup my own laptop one year ago.
If I'm getting set up, I really don't distinguish between Rails itself being irritating and one of its dependencies being a PITA. Those dependencies are part of the architecture of Rails, so it gets the blame. It's not like I need foo version of ruby if I'm just doing some quick scripting.
That's 3 days you could spend curing cancer. Tongue in cheek aside, I use to rage when I had to spend 3 days doing server admin and configuration. Along comes heroku and dotcloud and it's a godsend.
I find the install even easier now thanks to RVM, which is just a copy and paste into the terminal. Same with POW, which is good for the server part of development.
But then again, all this seems easy to me, can't speak for people entirely new to development.
Getting a rails dev environment setup used to be pretty painful, but thanks to a bunch of great tools (brew, rvm, rb-env, bundler, pow), and many blog posts, things are much better now than in the past. I can easily get brew, ruby, rails, Xcode, zsh, emacs and my entire dev environment set up on a brand new computer in a few hours these days (bounded only by network and CPU), and then get to work right away.
It is a different story for someone completely new. When I have time to sit down and help my brother and friends interested in getting started building websites, I recommend Rails (or Sinatra these days). The entire first session is usually devoted to helping configure their environment, and explaining the various tools they may need to know about when they are on their own. This is before even getting to the bit about learning HTML, CSS, Javascript, and Ruby. All of this is usually a complete waste of time because they have most likely lost me after typing in "cd" or "mkdir" for the first time. Yehuda's proposal nicely solves the configuration step for a beginner (the only class of developer for whom I think it is a seriously debilitating problem), but that is really the least of worries for someone new to web development in this day and age.
I installed rvm + some gems for the first time 4-5 months ago and ran into all kinds of problems. IIRC the problems stemmed from poor documentation, not poor tools. The existing tools work just fine. The problem was that the docs and intro guides are not written for someone who knows absolutely nothing about Ruby development.
I had problems installing it on older versions of OSX (Leopard), mainly because I was VERY new at managing the command line and understanding the relationships between ruby, rails, gems, etc and all of the various versions. I later got a new MBP and installing from a new install was very straight forward, but having to upgrade everything first and then installing it wasn't fun for a n00b like me. I would be interested in seeing this project as I think it would be easier for new kids on the rails block.
I've done it recently and it wasn't too bad, with the help of rvm. Getting the entire ecosystem (git, heroku, postgres, etc...) running is a bit more work, but pretty straightforward.
Perhaps part of the confusion is that there are a number of old blog posts that you'll dig up via google, and if you make the mistake of following an older one, you'll run into problems. I made this mistake trying to get rails set up on Ubuntu before I knew about rvm, and it was pretty painful.
I don't understand why this needs $25,000 in funding. He doesn't seem to mention where the money is all going to (I'm assuming just as 'salary' to work on it?)
Yah, rather then funding a project to make Rails easier to install on OSX (because it's not with the plethora information guides and bootstrap scripts), why not tackle real problems like concurrency and websockets in Rails.
While I understand the frustration, wycats, like any other open source developer gets to pick his battles.
Lowering the Rails entry bar is a good thing, making things simpler is a sign of maturity for a product.
To address your bit about concurrency and websockets in Rails, people are working on the issue, see the talks given by Ilya Grigorik for example, concurrency will be coming to Rails at some point. And so will the integration with client-side framworks like Backbone or Ember. It just takes time.
Agreed, but isn't this a good cause to fund to expatiate development.
A year or two back if you ask, "how do I built my bleeding edge web application" the answer normally was 'use Rails'. My point is the Rails has been sorely lagging behind other invitations.
oh god yes please I am a rails n00b who tried fooling with Rails a couple weeks ago and found the installation process INTENSELY FRUSTRATING. Especially compared to the unthinking ease of MAMP.
Gimme one .app and a directory structure I can just throw into /Applications (and later throw away if my experiments come to naught), gimme a nice control panel to stop and start Rails. Let me get it up and running on my system without hassling with the Terminal. Because I really really avoid the Terminal as much as possible.
"Because I really really avoid the Terminal as much as possible"
I don't mean to sound condescending, but if you're interested in using Rails (or any similar web platform), you need to be comfortable with the command line. It's not hard to learn, and there's even a good Peepcode video called "Meet the Command Line" that serves as a gentle introduction.
If you're really adamant about staying away from the terminal, you should look elsewhere.
I feel like this is overkill. I have been using RailsReady (https://github.com/joshfng/railsready) to setup several Mac and Ubuntu boxes and it has never been more than one click.
To be fair, he said he didn't necessarily want to duplicate the effort of others. I'm sure he will garner any information he can from those projects to help make that app awesome.
As Rails founding fathers complained of Java frameworks bloat, today's micro-framework fans complain of Rails bloat. Quite a cycle we've come through, isn't it ?
He's not complaining about bloat. Unlike many other high-level languages, Ruby has several viable execution environments (MRI 1.8, MRI 1.9, Rubinius, and JRuby) and Rails works on all of them. OS X ships with a system Ruby. The result seems to be that some people have trouble getting the right combination of runtime and libraries running.
I don't think it's fair to characterize Rails' early accusations against Java webdev as "The frameworks are too large." They accused Java frameworks of requiring too much ceremony, repetition and verbosity, but I can't think of many instances where early Rails advocates attacked Java for having too many features.
If someone won't make the effort to learn how to get an environment up and running, what makes him think that environment will have any real user once it's ready? There's a certain value of the commitment one takes when they decide to push forward and figure things out necessary to proceed.
I tried the locomotive solution back in the day and there was a reason it died. It sucked. Installing Rails was not the problem. Learning it was.
And again, the problem with Rails 3 today isn't the install. Instead it's that:
1. There is a shit-ton of old Ruby/Rails documentation out there that confuses the living shit out of people, and this is a duck-typed language, which is fine, but it means that people are even less likely to know what the fuck is going on when the code they are trying to use from someone's blog doesn't work.
2. Most of those using Ruby on Rails are not new as they once were, so since the majority know a little more about what the fuck they are doing, they are less likely to write things for those that don't know what the fuck they are doing.
But, writing an .app won't solve that. Instead, spend that time trying to take bundler, Gemfiles, rvm, the more complex Rails directory structure, asset pipeline, etc. and simplify the whole damn thing to create Rails 4, and chalk 3 up to an oops. A lot of the changes in Rails 3 were warranted, but the additional complexity will drive people away, and that is against the soul and original intent of Rails.
Want something that people would be really interested in? A framework that makes both development and scaling EASY. Development was easy with Rails years ago, but scaling was nearly impossible because that wasn't the intent. Now people scale Rails, but it is still hard, and development has gotten much harder. That's bad, because there are already ways to learn to develop quickly, and other solutions for scaling well. Being halfass at both is a sure way to fail miserably over the long-term, and Ruby and Rails is awesome; it shouldn't fail like this.
Setting up a vagrant script would be worth more. Portable development environment (Ubuntu running in a virtual box), cross platform support, easily configurable and duplicatable, and segregated from host machine.
You never know what kind of things people are doing on their machines, don't deal with that, use vagrant.
P.S. I'm sure a rails script exists for vagrant so he could just improve that with whatever he's going to do.
I can't help but wonder how these developers that are struggling to install rails on OSX will go when it comes to setting up rails in a production environment.
and that's been heralded as the best thing ever, so people don't have to futz with all the server setup/management.
But with regards to people looking for similar ease of use on the desktop for local development, they're all blithering idiots who shouldn't be allowed to touch a computer because they don't understand the intricacies of rvm vs rbenv.
There seems a bit of a disconnect here. Most people are proud of all the hard-won knowledge (sometimes through months or years of experience), and feel that everyone else should have to go through similar hell to attain some magic level of guru-ness. But... don't take away my heroku account!
So did DHH give permission to use the Rails logo for this project?????
"The use of the logo is restricted as it always is when talking about a trademark. When the logo is used in a commercial setting, such as part of the promotion of a book, it legally requires that the trademark holder has been involved and stands behind the quality of the book. If that's not the case, you're on the way to lose your trademark.
So I only grant promotional use for products I'm directly involved with. Such as books that I've been part of the development process for or conferences where I have a say in the execution."
I think crowd sourcing is a great idea. Being a professional programmer doesn't mean doing it for 120 hours a week. I'm more than happy to throw a little bit of money at something like this to have a good job be done of it.
Open source is amazing! But people have to eat. If people with great ideas and the ability to execute have to pull a contracting gig to pay their rent which takes away from important side-projects, I think that's a shame.
I'd like to see more things like this. If it means more high quality open source that helps people and saves them time, then great! I have donated $25 to this project. The direct impact it will have on me when it's complete is:
* I will be able to get designers/front-end developers up and running on a reliable rails setup without much hassle to myself.
* It's very likely they'll be able to set it up themselves.
* Programmers from other environments might be playing with Rails in 10 minutes on a weekend, enough to whet an appetite that will potentially give us a broader pool of developers to hire from.
This is great! Crowdsourcing is great! I hope he raises the cash required to focus on this and I can't wait for the result.
I decided to learn Rails this week, and just went through the process of following http://railstutorial.com (actually I'm about half through it.)
The tutorial made it extremely easy. I was up in running in an hour or two, and it only took that long because I am taking it rather obsessively slow, following all reference links, and brand new to Ruby.
Having been a Rails developer I don't have much trouble getting Rails up and going on a system. However I do have several friends who seem to have no end of trouble getting theirs setup working reliably. Given they are not full time developers, but they complain about how hard it is to get everything configured so I can see how useful something like this can be for many people looking to try out Rails.
I agree. I have been thinking about a shell script to setup a Django dev environment for my coworkers when needed, mainly the frontend developer because they are not familiar with or have many of the tools I take for granted. This idea is rather brilliant. It would be nice the app could open or setup a sublime text or textmate project for an app as well.
Installing Rails on OSX is trivial. If one really needs this process streamlined, maybe you shouldn't be coding? Or maybe you should just stop using a computer?
Similar to the Svbtle drama, this is yet another post lingering on the front page that has no business here.
I thought this was hacker news. Seems more like "check out my super cool project that you can't use unless you're awesome or you pay me" news. :(
Why shouldn't this turn out the same way? The person who started the HubCap project is a prolific open source contributor. I'm glad he didn't drop everything else to work on HubCap, as he made many great contributions to API client development last year.
I hope Yehuda changes his mind about this sooner rather than later. I really like seeing what Yehuda comes up with and this doesn't interest me at all. I use the command line, and I recommend homebrew to anyone on OS X who's serious about learning ruby, and so far it hasn't failed me. I've seen the Google App Engine launcher and I think it's pretty good but I still prefer the command-line tools.
I think the money would be better spent on creating a comprehensive beginners guide since the 4th edition of Agile Web Development with Rails is lacking.
I think that installing and configuring a database like Postgres or MySQL would be useful since it's often a non-trivial step in getting a production app ready (e.g. for Heroku).
OSS development has to be funded somewhere and to date it has been the benevolence of bigger organisations that have awarded grants or developer time. This gives the opportunity for a developer to offer to solve a problem and for the community to vote with their pockets. It empowers developers and the community to get behind a problem space and if people don't want it it won't happen.
JRuby will be in GSoC, and may also have a separate "summer of code" via an as-yet-unnamed benefactor. Perhaps we should just get Yehuda to mentor a student to build a single "Rails.app" that runs on all platforms, rather than just OS X?
Seems like this is connected to rails 4 release:
sidebar:
"and your input will guarantee that Rails 4 is as great for beginners as it is for experienced developers."
The main link to Rails 4 is that we've announced that Rails 4 will drop Ruby 1.8.7 support, which means that some sort of install will be mandatory on OSX beginning with Rails 4.
Ubuntu has a rails package already, and nobody uses it. It only serves to confuse new users. Trying to mix deb and gem just hasn't worked well so far.
Making a Rails.app for Mac is different though, because everything would be isolated in your .app, while a .deb would install the files to the system and track them in the package management database, so trying to modify them outside of apt-get/dpkg just b0rks everything.
I don't know. There are many good observations about what happened to Rails the last years in the comments. Rails is complicated and to get fluent in Rails takes some time. But this complexity came with a great flexibility. And that's a sign that we are facing a phenomenal ecosystem. I admit starting rails is frustrating, so many new concepts but everything like rvm has a reason why and even beginners will realize this quickly.
Yehuda's approach reminds me of the early days of webdevelopment where you could install a WAMP stack with one click on your windows systems. I never liked those one-click-installers—you don't know what happens to your system and deinstalling was a nightmare with still running db servers somewhere for years.
You can't wipe away Rails complicated entry with such an one click-installer. After you installed Rails with one click things aren't getting easier your still have to figure out next steps and which frameworks to choose (i.e. ERB or HAML, SCSS or LESS, MySQL or Postgre, etc.). Or something breaks within rvm: with an yehuda's approach you are completely clueless because you don't know anything about rvm, gemsets because the installer did all the work for you.
Sometimes there is even too much magic in Rails. I am still wondering if ActiveRecord is too much abstraction and if there are better more direct ORMs like DataMapper, I am used to ActiveRecord but still I can not fluently create data models, there's always something I forget, using the plural or singular, saving the updated migration, rolling back the migration, etc. Otherwise it's far beyond any ORM from other Frameworks I have ever seen in terms of speed. And its usage in Ruby is very consistent. Also Rails shell commands are very consistent, once you understand the rails syntax (like rails generate or destroy something you can quickly build anything in minutes), I tried several times to find something similar with python/django but there the entries seemed to me even more complicated, don't follow any system and felt restricted, i.e. Django's automatic Backend (no offense, i know not enough about django and python to say anything serious but that was just my first impression).
Another last great example of Rails: once you managed to install Rails, just put haml, less, less-bootstrap-rails and simple_form in your gemfile and run bundle. with this setup you can build web apps in minutes with perfect design and they are fully customizable. some years ago you needed hours or days to get to similar results. It takes time to get there but once you are there you have the power.
this pace and variety in the rails ecosystem comes from so many talented people who contribute. trying to set one standard for how things are done would slow down this pace.
finally, I think that Yehuda doesn't want to raise money, he just wants to get attention and the approval that he had the right idea.
The second is personal, so please take it with a grain of salt. I pointed out that Yehuda's Bundler gem has an automated condescension feature; if you try to use it without saying 'source :rubygems,' it heckles you and mockingly asks you 'did you mean to say source :rubygems? if so please go back and type it in.' this is pretty anti-Rails in my opinion, insofar as Rails is about sane defaults and programmer happiness. But I raised this issue, and the only response I got was 'fuck you.'
If I've had that kind of interaction with you, and you want my money, you better have an absolutely rock-solid plan for world peace. This is something other than an absolutely rock-solid plan for world peace, I've had that kind of interaction, he's not getting my money.
Not proud of taking the conversation there, but I do at least want to be honest. I gave Ze Frank $600 on his Kickstarter, but this project isn't getting a dime from me. I had in fact been thinking of contributing some amount in that range but after a brief attempt at talking to Yehuda spent it instead on a music class I wanted to take. :-)
Anyway, another objection: I've never heard of him doing anything with Objective-C and have no idea if he's ever even used the language before.
(If you follow @jm on Twitter you know where I'm stealing a lot of these ideas from.)
Another objection goes back to the first one, the XKCD 'standards' thing, and comes from a @jm tweet as well as from an undervalued comment buried way, way, WAY the fuck down at the very bottom of this page: we already have several projects of this nature. For instance:
Giles, you're acting like a prima donna over what is really a minor quibble with the way Bundler works. How many people do you honestly think get hung up on a warning from Bundler that gives you clear instructions on what to do next? And I know you like to exaggerate things to make a point, but do you really think that warning was added to heckle and mock people? Because that's ridiculous.
I can tell you one thing: there are many, many people who have benefited from the fact that Bundler fixes a boatload of issues for developers and in general makes my life, and their lives, better, even if we have to type "bundle exec", which I have conveniently aliased to "be" (try it).
I'm also willing to bet that a lot of people would benefit from this project if Yehuda takes it on. I don't know if he knows Objective-C either, and I don't care. Why? Because this is a guy who knows how to produce useful software. No, it doesn't let you produce music in your browser, or program beats in Ruby. But it is useful.
Archaeopteryx was the first time I came across you in the Ruby world and I thought it was really cool when I tried it out. Then again, I didn't find it particularly useful. I find Bundler useful every day, and I'm willing to bet lots of other people would too.
I realize I'm making this personal, and I'm sure that opens up a great opportunity for you to disparage my own accomplishments, or perhaps engage in some deliberate heckling and mockery, as opposed to the mockery you mistakenly perceive in a program's error message. I'll save you some time: I suck at programming compared to Yehuda, and I'm probably not as good as you are at it either. But one thing I'm far better at than you is appreciating people for their contributions instead of behaving like a jerk. So give it a rest, it's tiresome and juvenile.
well yeah. here you are making this personal, and what I said is I'm not going to give Yehuda any money because I criticized his PROJECT and he responded with
'fuck you giles.' so he made it personal, and you're making it personal too.
I'm not saying Bundler should be destroyed and it's a thing of evil. I said it was super useful but had very aggravating flaws which indicate that Rails went off the rails. If you guys can back off from all the making things personal about me for five minutes you might actually notice that "Rails went off the rails and is no longer entirely true to its original principles" is not such a vicious thing to say.
But is "fuck you giles" a response which is going to prevent you from getting my money? Yes, of course it is.
> what I said is I'm not going to give Yehuda any money because I criticized his PROJECT and he responded with 'fuck you giles.' so he made it personal, and you're making it personal too.
Well, that's reasonable enough. I'll be honest, when I read that, I assumed it was hyperbole. If it was a literal "fuck you", well yeah, that would bother me too.
I think you are missing the reason for the project.
In the php world, MAMP on osx is one of the reasons so many newbie jump into php. a simple app, abstracting away apache, php and mysql. you simply create a new vhost and click start.
This is the target audience - not the people who know how to clone a git repo and run a script in terminal.
He is trying to make it easy for new users and programmers. I know high school teachers that would use this to teach ruby web programming without all the error prone manual configuration.
Right, this would be very valuable as a teaching resource, and thus indirectly valuable to the, I believe, sizable chunk Ruby/Rails community at large who enjoy doing it as their "day job".
Bundler's "condescension" was a real error message, albeit a terse one. I expanded it 18 days ago. If you think it's still condescending, please suggest a better way of phrasing the error.
what I felt was rude was not the thing Bundler said but the thing Bundler does. if you know people are expecting rubygems to be the default, you don't tell them "oops you forgot to type rubygems, sucks to be you." you just make it the default.
you had an issue open for this on GitHub but it was closed with very little explanation. mind if I reopen it?
Joel Spolsky [1] beat XKCD to that punch by several years:
> (By the way, for those of you who follow the arcane but politically-charged world of blog syndication feed formats, you can see the same thing happening over there. RSS became fragmented with several different versions, inaccurate specs and lots of political fighting, and the attempt to clean everything up by creating yet another format called Atom has resulted in several different versions of RSS plus one version of Atom, inaccurate specs and lots of political fighting. When you try to unify two opposing forces by creating a third alternative, you just end up with three opposing forces. You haven't unified anything and you haven't really fixed anything.)
In your Gemfile Bundler requires you to tell it where to lookup for gems. For 99.99% of people that is going to be rubygems.org, but it doesn't have to be. There has been talk about making this the default and then allowing someone to turn it off.
edit: The RubyRouges podcast has a great episode with the maintainer of Bundler where a lot of the difficulties with Bundler are discussed in depth. That's the "talk" I was referring too.
well, this is what's insane about Rails these days. we have a value which is correct in 99.99% of the cases, and we are (at best) debating whether or not to make it the default.
I say at best because obviously in my case I did not see a whole lot of debate. the GitHub issue for it is likewise extremely not-discussion-y. wherever the discussion for this incredibly controversial idea is taking place, I haven't seen it.
actually I hate to say it but one of the early (2006? 2005?) blog posts about the diff between Python and Ruby was that in Python's console, if you hit "q" or escape or ctrl-C or something, you get an error message like the 'source :rubygems' error message, which says "hit ctrl-D to escape." the blog post was saying this is basically the diff between the two languages, that Python would correct you if it knew what you wanted but you asked it the wrong way, whereas Ruby would just either support the most obvious option, or support both the most obvious option and the 'correct' option as well.
the idea in Ruby, and especially in Rails, is that if you know what the default is which most people are going to expect or try, you should support it. to say "we know you thought source :rubygems was the default, but it's not, you have to type it explicitly" is a little un-Ruby and a whole bunch un-Rails.
> in Python's console, if you hit "q" or escape or ctrl-C or something, you get an error message like the 'source :rubygems' error message, which says "hit ctrl-D to escape."
Ah, I think I know what you're talking about. I wasn't using Python back then, and I know exit() was added after that (the only way to leave the console before that was to Ctrl-D), but when you type "exit" in the console, Python responds:
Use exit() or Ctrl-D (i.e. EOF) to exit
This bugs countless Python devs, myself included. It wouldn't be so bad if the console had no idea what "exit" was and responded with a NameError, but the fact that it realizes what you were trying to do but tells you to do something else inconsequentially different is a minor annoyance.
This seemed a little odd to me as well, but mostly because I haven't been a noob for a long time and so am out of touch with that feeling of "this is hard" when it comes to installing rails.
I don't think that installing rails got any harder relative to where it was in the 1.0 days. vanilla rails locked to one version with globally-installed gems is just as easy as it ever was, so I don't know if its quite fair to say step one is "make rails hard"; the current state of the ruby world is a lot more enterprise-ready and that comes at a complexity cost and automating that away is inconvenient.
What the hell has happened to "I want to build something, so I'll build it"? Now you have to [1]pay $100 for the privilege of reading the mailing list for an open source project? And some guy needs $25,000 just to start it?
Guys this is...not good. Can you imagine if apache's kickstarter never got funded? If the linux kernel's didn't? What if MySQL didn't properly manage their prize levels? Now it's "I want to build an alternative social network. Bootstrap me with $200,000" or whatever that was.
Kickstarter is really cool for a lot of things, I see it [and contribute to it] for large-scale art projects (burning man), but now every hacker I know has got a $25,000 wall in front of them called "kickstarter" and they don't want to start working until they scale it.
Stop this. This is really bad.
[1]: From the page: > [$100 gets you] access to the internal list for the project, where I'll be soliciting feedback about how to nail this. Great open source projects rarely come from the ideas of just one person, and your input will guarantee that Rails 4 is as great for beginners as it is for experienced developers.
What the hell is this? I have to buy a ticket to "help steer the project"? What happened to community? We're charging a cover at the door now?