What are the ethics & etiquette of forking someone else's github project to release it as a gem?

I'm doing some spare time coding around CultureGrid. They have a SOLR API to access 1.2m cultural artefacts. I've released a gem to consume their service, but I've got a nice idea about using Datamapper with a SOLR adapter backend to do it in a better way.

I just found a project from last year on Github handily called dm-solr-adapter. It's a fork of someone else's work from 2008 and to use it you have to clone the project and run a rake task to install it (not much use on heroku, so I'd have to vendor it). Unfortunately that task is now broken because they didn't pin their gem versions, and Bones has changed considerably between version 2 and 3.

Basically - it needs a bit of a recode to get it to be a gem, and if I'm going to do that I might as well release it myself and do it the way I know - using Jeweler instead.

So, of course I'll drop all of the authors a line, but I just wondered what the ethics and etiquette are here. Do I include my u开发者_如何学Csername in the gem or do I use the original gem name? Could that potentially trash someone else's installation, even though the gem is not listed on Rubygems.org? Do I follow their numbering convention? They seem to have chosen "1.0.0" and stuck with it, with no further activity. Or do I just start again from version 0.1.0?

Failing that, do I just grab the bits I want, include it in my new project and give a hat tip? That doesn't sound very useful for others who might want to do the same things.

Or perhaps I take the bits I find useful, make an entirely new gem called something like dm-solr-backend and go from scratch?

Oh, the dilemmas - what would you do?

---

So, if you're not going to release a gem, just go ahead and fork (assuming the license allows it) and don't worry about it. That's 100% OK and even expected behavior at this point. Forks are actually one of the easiest ways to accept patches from contributors. The network graph is often a good way to evaluate both the health of a project as well as the potential areas for improvement.

If you intend to release a gem because the original has become unmaintained, you should either:

• Release it as username-originalgemname
• Contact the original author and offer to take it over. Then push new gems under the original name.

If you intend to release a gem because you need changes to the gem that would not benefit the community as a whole, you should either:

• Unpack the gem into a vendor directory and never release
• Release it as username-originalgemname

In most cases, there is no problem with a gem release named username-originalgemname. This was the model that the GitHub gem repository took, so that's how most people handle forks at this point.

---

The only example of this I know of currently is the cache-money gem. It has been forked a few times, in this order:

• nkallen's fork
• kbrock's fork
• ngmoco's fork

In each case, the project had gone dormant for quite some time. Aside from the link on GitHub showing from where the fork came, there was no attribution to the original code in any of these cases (the middle fork even forgot to update the documentation to specify which fork to install when installing from gem).

As long as you make a good-faith effort to contact the original maintainer and the project has been idle for some time, go for it. Just make sure you update the documentation. ;)

---

With regards to checking a project's status, there's a new site called http://stillmaintained.com/ where some people register whether their project is either maintained, looking for a maintainer, or abandoned.