GitHub discontinues building gems

http://github.com/blog/515-gem-building-is-defunct

by jseifer • 17 years ago

41 23 17 years ago

rbranson• 17 years ago

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.

jimmybot2• 17 years ago

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.

pjhyett3• 17 years ago

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.

jamesbritt3• 17 years ago

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

cxvii2• 17 years ago

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.

jotto• 17 years ago

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

cxvii2• 17 years ago

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

jrockway• 17 years ago

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

pjhyett3• 17 years ago

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

oomkiller• 17 years ago

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!

himmel• 17 years ago

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

hernan43• 17 years ago

Booville.

compay2• 17 years ago

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. ;-)

jamesbritt3• 17 years ago

"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.

compay2• 17 years ago

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

pjhyett3• 17 years ago

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.

gommm2• 17 years ago

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.

petercooper2• 17 years ago

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/

gommm2• 17 years ago

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...

hypermatt• 17 years ago

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?

petercooper2• 17 years ago

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 :)

jamesbritt3• 17 years ago

"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.

GitHub discontinues building gems

Related Stories