5 ms·
> We’re growing at a rate of over 400 new users and 1000 new repositories every day and these rates are only increasing with time Crazy. Interesting how the re
by Maciek416 17y ago
> We’re growing at a rate of over 400 new users and 1000 new repositories every day and these rates are only increasing with time
Crazy. Interesting how the repo growth is faster than the new user growth. That's a lot of projects :)
The point-by-point listing of requirements in this post almost reads like an outline of what EY cannot do. I know that the split is supposedly amicable (on the surface), but this doesn't look so great for EY.
Also interesting is how the requirements of a given application gradually shatter through various ceilings of performance requirements, one notable one here being the following:
> The benefits of running bare metal are obvious and have been empirically proven. We need to have the option to run bare metal when it is appropriate to the task at hand
- pyre 17y ago> Crazy. Interesting how the repo growth is faster than the new user growth. That's a lot of projects :) Not that surprising. I see a lot of people fork repos only to do nothing with them. It's like forking on github is a 'packrat-ish' form of the 'watching' feature. I'd be more interested in a number that excluded either all forked repos, or forked repos with no new commits since the fork.
- icefox 17y agoI read the 1000 new repos as actual new repos, not forks. But yah if it is just forks that it isn't as impressive.
- pjhyett 17y agoForks represent around 30% of the total repos on our site, so the new, unique repos created daily still outpace new users.
- staticshock 17y agoIIRC, github's pastebin (gist.github.com) creates new repositories for fresh pastes.
- mojombo 17y agoThat's true, but we are not counting Gists in these Repository stats.
- pyre 17y agoThat's impressive then. I wonder if there are any stats on the size of these repos (i.e. are people creating new repos for everything -- even tiny one-off scripts -- rather than just rolling the smaller stuff into a single repo?)
- sachinag 17y agoThe split probably was amicable, frankly. No one disputes that Rackspace can do things that EY can't at this point. People outgrow things all the time. You start just accepting PayPal, and then you add credit cards when enough users want that. You start with an AIR app, but go to dedicated Windows/Mac/Linux apps when you have enough users on each that are worth it. There's been nothing that I've read - anywhere - that would suggest that someone else shouldn't use EY for their Rails app.
- dcurtis 17y agoExcept for the incredible price of EY, of course. It's probably coincidence, but I noticed that all of those other beginning technologies you mention are cheaper than the next step up. Not so with Engine Yard. It's like buying a Porsche, realizing you need more seats, and then switching to a nice, reliable, high-end Civic.
- rufugee 17y agoYes, and I was told by someone that once worked for EY that their price was the only selling point. In other words, their product wasn't better, but their price made a lot of folks believe that it was. If they hadn't charged more than everyone else and hired Ezra and a few other community luminaries, they'd be just another niche hosting company.
- sachinag 17y agoWait, Rackspace is more expensive than their EngineYard costs, which were free. And, actually, processing credit cards yourself is cheaper than PayPal, but there's the setup step that takes time and up-front costs. And your last analogy is really faulty, Dustin. If you need more seats, your needs have changed. Then you re-evaluate the options based on your new criteria. That's what Github did. Man, I thought I got through to you during our train ride. :)
- pjhyett 17y agoYou're correct that Rackspace is more expensive than our current arrangement with Engine Yard, but it would have been quite the opposite had we elected to stay.