GitHub discontinues building gems | Hacker News Reader

GitHub discontinues building gems

github.com

41 pointsjseifer23 comments

Glad to see GitHub get some focus. As a paying customer, I think they've let their free users degrade the service for those that finance the site.

Isn't that exactly the danger of running on a freemium business model?

Everything goes according to plan, you establish a new market, lots of free customers get introduced to your product and love it and you skim off the cream that want power or enterprise features as your paying customers. What stops a new competitor from swooping in and saying they have something very similar, they aren't going to be spending anything supporting free customers, and with presumably lower costs, charging their customers less? With complete focus on paying customers, they might provide a better product too.

I'll venture a guess you've never heard of the git hosts that only offer private plans. Allowing people to post public code for free is fundamental to our business model and a major reason why we're successful.

I haven't, though I haven't had the need for one either. But if they exist and they're decent, you don't think I would find them if I researched for a git host?

I don't argue with you that freemium works in the short and probably medium term, and it's great advertising. You have a great service going, and I think in your case, you build a lot of good will among developers hosting public code for free. But in the long run, in the general case, and assuming no network effects, I think there's a way to undercut such business models by focusing 100% on the paying customers.

As a paying customer, I'm disappointed they dropped one of the services that prompted me to move to GitHub.

That's really a bummer... I loved being able to fork a ruby lib, make some changes and have the gem available for any servers I used...

I also think that they should have given advance notice. Cutting features that I (as a paying customer) rely on without notice and then telling one week later that they won't bother to bring it back is not a good way to keep my trust.

That's really a bummer... I loved being able to fork a ruby lib, make some changes and have the gem available for any servers I used...

You still can. See: http://litanyagainstfear.com/blog/2009/10/09/on-gem-forking/

Yes of course, but I like having the fact that it's done automatically on push... And I don't really like having to go back through my projects to change the gem dependencies...

I liked this feature, but I think it makes sense for them to remove it. To me it highlights the fact the Github has grown way beyond just hosting Ruby projects.

I'm currently in Rio for the Lua Workshop and many people here have said they'll be moving their projects from CVS or SVN over to Git and Github. I am guessing that within a few months Github will be the defacto standard place to host Lua projects just like it is for Ruby. Hopefully they have at least 50 megabytes of free space to accommodate all of us. ;-)

"I liked this feature, but I think it makes sense for them to remove it. To me it highlights the fact the Github has grown way beyond just hosting Ruby projects."

Then another option would have been to do the same thing for non-Ruby projects. Integrate with CPAN; build eggs (or whatever it is that Python uses); create Cabal packages.

I think it was far easier for them to achieve consistency through subtraction rather than addition.

That was the conclusion we came to: either do them all or none of them.

The problem is with the amount of time we spent working on, maintaining, and fielding support requests for rubygems, the last thing we wanted to do was multiply that work supporting additional systems.

This decision wasn't made lightly, but the service and support will be better off with it gone.

I understand that in the end this is for the greater good, but shutting it down just because you can't be bothered to fix a few things is just ridiculous. At least offer gem building while you still support gems.github.com so people have time to migrate.

they are supporting gems.github.com for 1 year, see article

I know, I'm saying they should support the actual gem building as long as they are supporting gems.github.com.

Surely there is some way they can find to make this work without too much trouble, or at least integrate seamlessly with someone who wants to. Just about every howto article out there that uses custom gems uses the <username>-<gemname> format which tells you its coming from GitHub. As a paying customer, this is something I would very much like to support!

just use rip, it builds gems from git repositories..

Too bad. We never got CPAN indexing (as promised) either.

I don't recall anyone promising that, but I apologize if you feel mislead.

Damn I really liked this feature, most of my gems are installed from github ;( I wasn't quite clear what this means now, gemcutter is handling it? or Are we supposed to move back to ruby forge?

Just use Gemcutter. It's really easy. Take your existing Github project, build the gem, then gem push it to Gemcutter (assuming you have the Gemcutter gem installed). It's that easy.

If your Github project is a fork, then edit the gemspec and prepend your Github username to the gem name.. then build and push. Problems all solved :)

"Are we supposed to move back to ruby forge?"

I moved my gems to gems.neurogami.com. It's easy enough, and I trust myself more than the Next Hot Host.

While I appreciate the value of It Just Works when comes to installing gems, there's also value in users making deliberate choices about where they get they code they are installing.

Booville.

Reply on news.ycombinator.com