Exceedingly well put. <span></span><br><br>On Sunday, May 12, 2013, Monty Taylor wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 05/11/2013 08:58 PM, Anne Gentle wrote:<br>
><br>
><br>
><br>
> On Sat, May 11, 2013 at 6:43 PM, Monty Taylor <mordred@inaugust..com<br>
> <mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'mordred@inaugust.com')">mordred@inaugust.com</a>>> wrote:<br>
><br>
><br>
><br>
> On 05/11/2013 05:48 PM, Anne Gentle wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Sat, May 11, 2013 at 3:12 PM, Monty Taylor <mordred@inaugust..com<br>
> > <mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'mordred@inaugust.com')">mordred@inaugust.com</a> <mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'mordred@inaugust.com')">mordred@inaugust.com</a>>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On 05/11/2013 04:07 PM, Asher Newcomer wrote:<br>
> > > Or even better, just continue to call it openstack<br>
> networking. The<br>
> > code<br>
> > > names only serve to confuse the uninitiated. They needlessly<br>
> > steepen the<br>
> > > learning curve and slow uptake.<br>
> ><br>
> > The problem with OpenStack Networking (or getting rid of<br>
> codenames) is<br>
> > seen with pre-incubation->incubation->integrated cycle.<br>
> ><br>
> > A project cannot call itself "OpenStack Foo" until it actually<br>
> _is_<br>
> > openstack foo. So any new project by necessity has to start off as<br>
> > something else.<br>
> ><br>
> > But - if we then require them to drop that name and become<br>
> openstack foo<br>
> > when they become incubated or integrated, then we've got<br>
> what's become a<br>
> > stable project with a decent amount of contributors renaming<br>
> itself.<br>
> ><br>
> > Every. Time.<br>
> ><br>
> > The code names aren't just cute. I kind of wish they were,<br>
> because it<br>
> > would make several things much easier if we could just ditch<br>
> them and do<br>
> > a pure openstack. code namespace. But the reality is that it<br>
> gets really<br>
> > really tricky to deal with a bunch of things if they go away.<br>
> ><br>
> ><br>
> > I told Monty and the TC this at the Summit (sorry I couldn't<br>
> attend the<br>
> > session about code names).<br>
><br>
> I promise, it wasn't the world's most fun session. :)<br>
><br>
><br>
> I'm sure. :) I think I don't have much regret but do feel sorry that I<br>
> don't know more.<br>
><br>
><br>
><br>
> > I find this trickiness a weak argument in the<br>
> > face of the invented names that are getting to be as bad as U.S.<br>
> > pharmaceuticals. Plus it forces us to put a "lookup" table in the docs<br>
> > forever. [1] Let's find a process for naming that meets a few reqs:<br>
> > - describes the service<br>
> > - goes through a legal review<br>
> > - enables new eyes to understanding it by reading the English word<br>
> that<br>
> > the service represents (that can be translated into a meaningful<br>
> word in<br>
> > other languages)<br>
><br>
> I don't think it's a weak argument at all. There are real technical<br>
> issues.<br>
><br>
><br>
> The technical issues, to me, and I may be missing something, are when<br>
> the name is used as:<br>
> - service/daemon name<br>
> - command/CLI name<br>
<br>
And the directories in the code where those things live, and the name of<br>
the python package that gets installed, and the name of the client<br>
library used to connect to it.<br>
<br>
> You can use any pet name you want for your team and project while<br>
> addressing technical issues some other way?<br>
><br>
> Here's another way I'm looking at the naming autonomy/process. Why<br>
> incubate?<br>
> - you get to pick your cool name<br>
> OR<br>
> - you get access to infrastructure, tools, events, community, and<br>
> branding that is OpenStack<br>
><br>
> The naming can't be THAT crucial. I get that we want projects to be fun<br>
> to work on. But it can't be just the naming that brings the fun.<br>
<br>
I don't think "having a cool name" is interesting or important at all.<br>
Not one little bit. If any part of this was about esprit de corps or<br>
team bonding or identity I'd be 100% on board with the no-codenames<br>
approach.<br>
<br>
Also, to be clear, I don't think there are any problems with using<br>
non-codename for identification. Already, as part of the upgrade of our<br>
build stuff to PBR I've been setting the project short description to<br>
the non-codename. So, nova's is "OpenStack Compute" I think that's a<br>
great idea, and it's important.<br>
<br>
Equally as important, although harder, is that we should all try our<br>
best to use the non-codenames when we're talking about official<br>
projects. It's not going to work or be 100% covered - but we should all<br>
make a best-effort.<br>
<br>
(these are all things that did come out of that session - perhaps one of<br>
us should do a writeup on that?)<br>
<br>
The thing that _I'm_ sticking on is the above list of technical issues.<br>
What is the daemon named? What is the command line tool named? What is<br>
directory in which the code lives?<br>
<br>
Those may seem trivial, but those are the primary interface that a<br>
developer and deployer has with the project. And it's an issue because<br>
of the lifecycle of these code projects before they are integrated. It's<br>
not ok for moniker to call it's API daemon "openstack-dns-api" until<br>
it's actually openstack DNS. It has to call itself something though.<br>
That's where names come in. It's a practical thing that there must be a<br>
name.<br>
<br>
And let's be honest - it's my least favorite part of making a project.<br>
So much so that our CI project which makes jenkins jobs from yaml files<br>
is called "jenkins-job-builder" and the tool we use to manage our<br>
projects in gerrit/github and launchpad is called jeepyb - which is a<br>
phonetic re-working of "G P B" which stood for Gerrit Project Builder.<br>
Shoot me now.<br>
<br>
There's another rub with descriptive names. Jenkins Job Builder has<br>
become WILDLY successful. People use it all over the place in areas<br>
completely unrelated to OpenStack. I believe there's a guy on an oil rig<br>
somewhere who is not only using it, but contributes patches. It's great.<br>
AND ... a couple of weeks ago Jim and I met one of the guys from the<br>
Eclipse Foundation...<br>
<br>
You may not be aware, but the original codebase for Jenkins was called<br>
Hudson, and it was a Sun project. When Oracle bought Sun, the screwed it<br>
up like they screw up just about everything Open Source, so the core<br>
team left, forked it, and many of us, including OpenStack, followed the<br>
Jenkins fork. (If you've ever wondered why you get messages from jenkins<br>
under the email name of "OpenStack Hudson" - that's why - we haven't<br>
ever renamed the original hudson service account) In any case, Oracle<br>
finally realized that they didn't know what they hell they were doing,<br>
so they gave hudson to the Eclipse foudation...<br>
<br>
which brings us back to - Jim and I and the guys from wikipedia and the<br>
guys from Eclipse are going to have a talk about how we can all work<br>
together better ... turns out Eclipse already uses gerrit too. We'll<br>
tell them all about the things we've built that make things work<br>
smoothly - like Zuul and Jenkins Job Builder.<br>
<br>
Oops.<br>
<br>
Jenkins Job Builder. That's going to be awkward. Zuul will be fine - it<br>
reads gerrit event stream and makes jenkins API calls. Hudson has the<br>
same calls, it should just work. Jenkins Job Builder creates xml<br>
snippets. It SHOULD just work technically - but we're going to wind up<br>
asking the guys running the hudson project to use "Jenkins Job Builder"<br>
to manage their CI.<br>
<br>
Naming is important - and not for cute hipster reasons. There are real<br>
logistical challenges that a unique non-descriptive name help with.<br>
There's a reason that Ivory doesn't just call itself "Pure White Soap"<br>
Our brains process pattern and names in a peculiar manner, and it helps<br>
us to communicate specifically. We also none of us have problems dealing<br>
with made up word names - we've got 13 years of dot-com era dopplr and<br>
yelp and bing and iphone and whatnot. It's not a problem.<br>
<br>
One of the things that IS an interesting intersection of problems here<br>
is actually the real issue. It's not that short names are bad for any<br>
technical reasons. It's that they're potentially problematic from a<br>
legal perspective, but there is no avenue for us to engage with that in<br>
a way that is consistent with our community values.<br>
<br>
We, from the beginning, and to this day, spend a MASSIVE amount of<br>
effort in doing everything in the open, because Open Process and Open<br>
Governance are just as important to a community as Open Source is. This,<br>
however, it turns out, is directly at odds with just about everything of<br>
how corporate entities work. We've way more meta-discussion at the board<br>
meetings about the need for our private executive sessions. We don't<br>
like it, but there are times that for legal reasons we actually HAVE to<br>
not do some things publicly. I think it's crap and one more way in which<br>
the man is trying to keep us down, but it is a fact of life.<br>
<br>
Why do I think that's relevant?<br>
<br>
It's because we don't get the benefit of private codenames for work and<br>
then public marketing names. Rackspace Cloud Servers internally is<br>
called Ozone, am I right? Cloud Files was called Swift before it was<br>
part of OpenStack. And it still is.<br>
<br>
Our problem is directly related to our value - which is that we market<br>
ourselves directly through telling people they can look at our code.<br>
That means that as much as we can have a project called swift that the<br>
business folk call OpenStack Object Storage - there is no escaping the<br>
fact that the technical folk are going to talk about it as swift in<br>
their technical conversations. In fact, we've done such a good job as a<br>
technical meritocracy that people consider our<br>
non-marketing/non-business choices as marketing/business actions - and<br>
they consider them potential grounds for lawsuits.<br>
<br>
So we're going to have this problem. It's not going to go away - because<br>
we're doing something different, and we're doing it in a way that isn't<br>
compliant with the box that the world wants to put us in.<br>
<br>
In theory, it should be hurting adoption for us to have 18 different<br>
projects with completely un-understandable names. I'm pretty sure that<br>
the last couple of summits have shown that, of the problems we have,<br>
that is not one of them.<br>
<br>
There is one more problem with coupling the technical part of the<br>
project to the branding - and that's one from the opposite side of<br>
incubation. What if we eject a project? What if the TC decides to get<br>
together and say "you know what? We don't think swift has enough<br>
production deployments at scale (hahaha) and doesn't meet our criteria<br>
for a good OpenStack project. Monty and Jim wrote a shell script that<br>
stores objects in mercurial. Mercurial is in python. We want to use that<br>
for OpenStack Object Storage instead." Now what? Does swift have to<br>
rename their project again? If they decide "cool, we don't need you,<br>
we're going to continue life as part of the Eclipse foundation" - do<br>
they need to rename the innards of their project from<br>
openstack/storage/object back to swift? Which law forces them to do<br>
that? Because I'm pretty sure that would be trademark. That would mean<br>
that we'd have a non-free trademark usage policy concerning forks -<br>
which would make us DFSG incompatible which would mean that Debian would<br>
stop shipping us.<br>
<br>
I would really like to keep our trademark out of our source code,<br>
because it opens a giant can of worms.<br>
<br>
I would really like to keep the marketing/business folks out of our<br>
source code.<br>
<br>
Most importantl, I would really like to keep the lawyers out of our<br>
source code.<br>
<br>
Occasionally this means we're going to get stuck, like with Quantum, and<br>
we're going to need to do a project name change. Ok. I think we've now<br>
learned that we as technical people have GOT to check more than just "is<br>
the project name available on github/launchpad/debian/redhat and pypi" -<br>
cause we already do that. We should do things like "does a quick google<br>
search of my project name and core elements of it return, you know, a<br>
business." I mention our erstwhile nascent DNSaaS project as an example<br>
of pre-incubation... hopefully someone in that project will do the thing<br>
I just mentioned and will come to us at incubation time with a name that<br>
is not a CLEAR violation. I mean, we can't be perfect, but we can at<br>
least try. Because if we try, then it keeps the lawyers out of our<br>
business - and that's really better for all of us.<br>
<br>
> I think you believe I have some strict naming process in mind, so I'm<br>
> trying to explain my position more.<br>
><br>
> It's more that I believe we can have team/project names without naming<br>
> technical things (repositories, CLIs) with that "cool/fun" name.<br>
><br>
> Go with kumquat, but don't call the CLI kumquat. Call your team kumquat<br>
> and your repo kumquat.<br>
><br>
> That assumes that OpenStack is involved with the project pre-incubation.<br>
> That's was the case with Quantum and Ceilometer and Ironic. On the other<br>
> hand, the heat folks had <a href="http://heat-api.org" target="_blank">heat-api.org</a> <<a href="http://heat-api.org" target="_blank">http://heat-api.org</a>> and a<br>
> heat github org and other<br>
> things before they started down the stackforge road. Looking right now<br>
> at non-incubated projects just off the top of my head:<br>
><br>
> Libra is an LBaaS solution that was started on stackforge and which it's<br>
> increasingly unlikely will go to incubation rather than just atttempt to<br>
> merge stuff in with Quantum LBaaS. Moniker is a DNSaaS that hasn't<br>
> applied for incubation, might do so, but as of right now has been around<br>
> for almost a year yet has no formal relationship with OpenStack.<br>
> healthnmon may or may not be an incubation candidate.<br>
><br>
> Before that, reddwarf was not-incubated for pretty much the entire time<br>
> OpenStack has existed until just now.<br>
><br>
> All of these things have had to have lifecycles during a period of time<br>
> before they have any interaction with us formally.<br>
><br>
> On the other hand, if we did checking pre-incubation, we'd be in a very<br>
> odd position of granting permission/blessing/tentative interest in<br>
> projects before they come close to sorting things out. Moniker is great,<br>
> but 6 months ago there were as many as 4 different DNSaaS possibilities.<br>
><br>
> In any case, I don't think there is any way that we can, become directly<br>
> involved in projects before they are incubated.<br>
><br>
> Stackforge helps already, in that moniker is stackforge/moniker rather<br>
> than openstack/moniker. But neither has any effect on the fact that<br>
> there is a directory named "moniker" in moniker repository. If we go<br>
> with 'descriptive' names, then there are two choices:<br>
><br>
> a) moniker starts life with a directory structure underneath<br>
> openstack/dns inside of its repository, even though it is not an<br>
> openstack project.<br>
><br>
> b) moniker starts life with a moniker directory, and then when<br>
> incubated, renames that directory from moniker to openstack/dns.<br>
><br>
><br>
> Yeah I'm not too concerned with repository names, though I do understand<br>
> the need for uniqueness there. We incubate for a reason, to experiment a<br>
> bit. In that experimentation I hope projects are considering their users.<br>
><br>
><br>
> We can't stop anybody from doing (a) of course, but let me tell you -<br>
> you wanna talk about confusing and bad messaging - we had apt repos at<br>
> the beginning of the project with giant letters on them "FOR TESTING<br>
> ONLY" but because they had our name on them people assumed we supported<br>
> them.<br>
><br>
> (b) sound easy, until you reckon with things like line-wrapping changes,<br>
> sort order changes, and client library/API consumption changes. If<br>
> something is using python-monikerclient and thus the monikerclient<br>
> namespace of the API, that person would have to port their code to now<br>
> do something like openstack.dns.client or similar.<br>
><br>
><br>
> I totally get how hard the CLI work is. But what I don't get is why a<br>
> unique name that is meaningless is so valuable?<br>
><br>
><br>
> Even ignoring people who may have already been using the code (many of<br>
> these things start life as a service by one of our member companies and<br>
> then enters incubation when it's become baked a little bit - reddwarf<br>
> was in production at RAX and HP before it got incubated, moniker is in<br>
> production at HP, etc) and just focusing on our own code base, the<br>
> massive undertaking that it is to change the name of the project inside<br>
> > <mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'openstack@lists.launchpad.net')">openstack@lists.launchpad.net</a>><br>
> > <mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'openstack@lists.launchpad')">openstack@lists.launchpad</a>.<br>
> <mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'openstack@lists.launchpad')">openstack@lists.launchpad</a>.>.net><br>
> > > > <mailto> > </blockquote>