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
The only example of this I know of currently is the cache-money gem. It has been forked a few times, in this order:
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. ;)
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:
username-originalgemname
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:
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.
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.