Project name ownership and conflict

[Emmanuel Gomez]

I recently had a discussion with a fellow Ruby developer that revealed a
significant variance in our views about project names.

In 2008 I published a Ruby project on GitHub with an MIT license and
registered a RubyForge project at the same time. This code was available
as a Gem from GitHub while GitHub was hosting Gems (ie, I included a
gemspec in the project). I never publicized my code, though I think it
is worthwhile, and I did not publish a Gem to gemcutter.org or
rubygems.org once GitHub stopped hosting Gems. My Gem was no longer
installable with `gem install X` after that point.

In 2010, my fellow Rubyist published a gem using the same name as my
project without notifying me. When I contacted him about this, he
indicated that in his view, first to publish in the public Gem namespace
is the only claim a developer can make on a name for a Ruby project. He
didn't say so, but I assume he only recognizes the authority of
rubygems.org with regard to the Gem namespace. Citing this view of
project name 'ownership', he refused my request that he rename his
project.

I was disappointed, but I was also curious. Clearly the authority of
rubygems.org as *the* public Gem namespace is important, but I
personally search for existing projects on GitHub, RubyForge and Google
before considering a given name as 'available'. I consider it reasonable
and polite to do so, but more so, I consider it *my responsibility* to
perform such a check before publishing. I don't take `gem install X` as
the only meaningful test for project name availability.

What is the community view of project name 'ownership'? Was my fellow
Rubyist right to publish his Gem without checking Google, GitHub or
RubyForge for existing projects under his intended name? Or am I right
to expect Ruby Gem authors to perform at least a minimal search for
existing projects prior to publication?

I appreciate your input in this matter,
Emmanuel Gomez

 

[Peter Hickman]

What was the name of your gem? Would googling for it have returned
anything meaningful given that you made no effort to promote it?

Is this actually a problem for you?

 

[Roger Pack]

What is the community view of project name 'ownership'? Was my fellow
Rubyist right to publish his Gem without checking Google, GitHub or
RubyForge for existing projects under his intended name? Or am I right
to expect Ruby Gem authors to perform at least a minimal search for
existing projects prior to publication?

Yeah typically all we check if "can I push this gem?" before grabbing
the namespace. Unfortunately.
Hopefully you can work it out civilly
One option would be to keep with your original github gem name
username-gemname, since apparently that was good enough at one point?
-r

 

[Richard Conroy]

[Note: parts of this message were removed to make it a legal post.]

Yeah typically all we check if "can I push this gem?" before grabbing
the namespace. Unfortunately.
Hopefully you can work it out civilly
One option would be to keep with your original github gem name
username-gemname, since apparently that was good enough at one point?

Is this issue growing in significance? I have heard of cases of gemname
'squatting'
going on.

Is there even some kind of community ad-hoc guide for naming gems?

While 'first to publish claims the name' sounds harsh, in practice I don't
see any other
reliable way for enforcement.

 

[Emmanuel Gomez]

What was the name of your gem?

My project is called Clockwork. http://github.com/emmanuel/clockwork

Would googling for it have returned anything meaningful
given that you made no effort to promote it?

Before this name conflict, my project's GitHub and Rubyforge pages
appeared in the first page of Google results for the query 'ruby
clockwork'.

Is this actually a problem for you?

Neither my life nor livelihood is threatened.

That said, this does matter to me.

I'm not sure what form of answer you expect.

 

[Emmanuel Gomez]

Yeah typically all we check if "can I push this gem?" before grabbing
the namespace.

Based on responses received so far, this seems to be the prevailing
view. This speaks to the letter of my question.

Unfortunately.

This speaks directly to the spirit of my question. Namely: what
expectation would the community prefer to hold Gem authors to?

Hopefully you can work it out civilly

I'm sure we will. I have no interest in being uncivil in this matter. My
fellow Rubyist seems to have little interest in the matter at all.
Posession is nine-tenths of the law, after all.

One option would be to keep with your original github gem name
username-gemname, since apparently that was good enough at one point?

Thank you for the suggestion. I think a new, non-conflicting name is the
only acceptable solution in this case. My inflexibility: how many Gems
with Github username prefixes are in general use?

 

[Emmanuel Gomez]

Is this issue growing in significance?

I can't speak to this as a trend at all.

I have heard of cases of gemname 'squatting' going on.

That is an interesting and related but separate issue. My query is
specifically about gemname 'sniping' rather than squatting. That said,
if either is a problem, there may be a common solution to both.

Is there even some kind of community ad-hoc guide for naming gems?

I am interested in the answer to this question, as well.

While 'first to publish claims the name' sounds harsh,
in practice I don't see any other reliable way for enforcement.

Outside of bureaucratic and/or technical measures, the only thing that
occurs to me is *shame*.

 

[James Britt]

Based on responses received so far, this seems to be the prevailing
view. This speaks to the letter of my question.


This speaks directly to the spirit of my question. Namely: what
expectation would the community prefer to hold Gem authors to?


I'm sure we will. I have no interest in being uncivil in this matter. My
fellow Rubyist seems to have little interest in the matter at all.
Posession is nine-tenths of the law, after all.


Thank you for the suggestion. I think a new, non-conflicting name is the
only acceptable solution in this case. My inflexibility: how many Gems
with Github username prefixes are in general use?

I suggest you call your gem something like improved-clockwork or
better-clockwork or kick-ass-clockwork.

When github was handling gems I found it much nicer than using
rubyforge.org. I've a number of projects that never had a home anyplace
else, and now prefer to just host the gems myself.

I tend to namespace my gems, though, and would prefer that this be the
norm. It's an issue that has come up a few times, not always because of
name ownership disputes.

The name problem I've seen more often is when someone uses a generic
name for a project (e.g. "xml-parser" "twitter", 'json'; BTW, these are
just examples to show the kind of names, not selected because of
anything to do with any real gems).

Then the project falls into limbo, or maybe the code sucks. People
looking for suitable gems for, say, XML or twitter or json, will
inevitable first use the generic gem, even if it's not supported or any
good.

Having some sort of name space prefix might reduce the problem of a
given gem appearing to official or canonical or something.

That was one nice side-effect of the github approach; you couldn't have
a 'twitter' gem, it had to be something-twitter. Yes, there were
opportunities for mischief there too, but it was a step in right direction.

I sort of wonder, though, if the reliance on a single authoritative gem
registry (rubyforge or rubygems.org) exacerbated this. If there was
nothing to stop people from having the exact same name for a gem then
people might find other, less contentious, more secure ways to
distinguish their code. And help make gem signing more common.


As it stands, though, it's a social/cultural issue.


--
James Britt

www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
www.neurogami.com - Smart application development

 

[Intransition]

As it stands, though, it's a social/cultural issue.

It a wider issue than we might realize too. Today I was looking for a
name for a project, and I considered 'figleaf'. There was no gem by
the name, but I discovered that their was a Python project by the
name, and it just so happened that the Python script had an executable
named 'figleaf', and it dawned on me that my project too would have an
executable named 'figleaf', if I choose that name. In which case,
there could be a conflict in a system 'sbin/ directory. A multi-
lingual developer who used both Python and Ruby might run into such a
problem.

I am not sure there is any good solution to this. OS's would need to
build namespacing directly into the PATH lookup system. It's far too
annoying to be naming all one's executables 'figleaf-ruby' or
'transfire-figleaf' or what have you.

 

[Intransition]

My project is called Clockwork.http://github.com/emmanuel/clockwork

Oh, yes. I had a premonition about this today. Rename the project
'orange'. That would be awesome.

 

[Emmanuel Gomez]

Oh, yes. I had a premonition about this today. Rename the project
'orange'. That would be awesome.

I think I'll do just that. Although 'orange' may be too general, I think
'clockwork_orange' is perfect. Thank you for an elegant and, dare I say,
'Ruby-esque' solution, trans. I mean that in the spirit of the wonderful
Ruby community, not necessarily the language itself.

Also, thank you for your insightful reminder about potential name
conflicts with projects in other languages. Seemingly simple things
quickly become complex.

 

[Martin DeMello]

I suggest you call your gem something like improved-clockwork or
better-clockwork or kick-ass-clockwork.

clockwork2 should solve the issue neatly, though it leads to the
prospect of a suffix arms race

The name problem I've seen more often is when someone uses a generic name
for a project (e.g. "xml-parser" "twitter", 'json'; BTW, these are just
examples to show the kind of names, not selected because of anything to d= o
with any real gems).

Then the project falls into limbo, or maybe the code sucks. =A0People loo= king
for suitable gems for, say, XML or twitter or json, will inevitable first
use the generic gem, even if it's not supported or any good.

yeah, ruby could really use some sort of central site where people can
rate and comment on gems, tagged and categorised by function. this
would solve the issue in much the same way that google made domain
names that much less valuable.

martin

 

[Rick DeNatale]

I think I'll do just that. Although 'orange' may be too general, I think
'clockwork_orange' is perfect.

or Droog!

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale