

GitHub discontinues building gems - jseifer
http://github.com/blog/515-gem-building-is-defunct

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

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

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

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

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

~~~
petercooper
_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/>

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

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

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

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

------
cxvii
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
they are supporting gems.github.com for 1 year, see article

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

------
oomkiller
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
just use rip, it builds gems from git repositories..

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

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

------
hypermatt
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?

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

------
hernan43
Booville.

