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