[Container-tools] Naming the "Container App Spec and Libraries" project

[John Mark Walker]

----- Original Message -----

> To atomic or not to atomic is

> pro: associates it with red hat project, shows our leadership

> con: associates it with red hat project, getting other to join

That is indeed the question, and I've now come full circle. 

Who is the target audience here? 

If it's on the more traditional ops side of the house, strong association with Red Hat brands is a big plus. 

If it's on the more dev side, we don't have a lot of cachet with them. 

Given that container tech right now is mostly in the hands of early adopters and developers, I'm not sure that a strong association with RHT brands wins us much. BUT If we're able to convince developers (and in this case, I'm referring to developers for open source projects) that we'll help them reach more enterprise users (read: people likely to pay $$$) then it may be a winning strategy. 

What we don't want is a plethora of competing app initiatives that diverge from our Atomic vision, which is why I initially favored removing the container app definition. 

Bottom line: superior tooling and a better user experience are going to win over open source projects and their users. In that case, building a critical mass of users is the top priority, and early adopters as well as developers will choose regardless of where the app definition sits. 

Because there are no other pre-existing app definitions out there with any significant mindshare, we have a chance to be first to market and establish a foothold. If the Atomic tooling is good, and our offering is comprehensive, then I'm on the side of pushing everything under Atomic and investing heavily into developing that brand, of which the container app spec is a part. 

We need to build out (and sell to other communities) the Atomic brand: scalable, policy-based application runtime. 

-JM 

> I like the suggestion of Tomas' suggestions.

> Carl.

> On 04/14/2015 01:21 PM, Daniel Riek wrote:

> > Atomic App
> 

> > - Consistent with Project Atomic
> 
> > - Consistent with the atomic-run tool - which is the first half of this
> 
> > concept.
> 
> > - Makes sense because it implements the concept of immutable
> 
> > infrastucture and aggregate packaging that the 'Atomic' naming scheme is
> 
> > trying to convey
> 
> > - Gives some urgently needed content to Project Atomic
> 

> > And not to forget: it's the original name I had in mind, when I started
> 
> > the project...
> 

> > Cheers,
> 

> > Daniel
> 

> > On 04/14/2015 01:02 PM, John Mark Walker wrote:
> 

> > > Hey gang,
> > 
> 

> > > Because there's an obvious namespace collision between CoreOS' appc
> > > efforts
> > > and our own container app spec, I've been wondering what to name our
> > > thing.
> > > Here are some potential names. Vote on 1 or submit your own:
> > 
> 

> > > - supernetes - I originally liked this, but then realized it doesn't send
> > > a
> > > realistic message. Connotes some type of orchestration that sits "above"
> > > k8s. I don't think that's what we're creating. I include it here for
> > > completeness.
> > 
> 

> > > - intercon - short for "inter-container" - because what we're doing is
> > > about
> > > defining multi-container applications that can utilize a number of
> > > "providers" and host environments.
> > 
> 

> > > All the other names I'm thinking about are variations on this theme:
> > 
> 

> > > - interpod - same as above, except adopting the term "pod" from the k8s
> > > universe
> > 
> 

> > > - hyperpod, hypercon - same theme as above, just using a different term
> > > of
> > > art to connote "more than one pod"
> > 
> 

> > > I kind of like intercon, although I could see arguments for something
> > > else.
> > 
> 

> > > Once we have a name, we need to figure out where it lives. I don't think
> > > it
> > > belongs under the Project Atomic org on github.
> > 
> 

> > > github.com/intercon is available :)
> > 
> 

> > > -JM
> > 
> 

> > > -JM
> > 
> 

> > > _______________________________________________
> > 
> 
> > > Container-tools mailing list Container-tools at redhat.com
> > > https://www.redhat.com/mailman/listinfo/container-tools
> > 
> 

> > _______________________________________________
> 
> > Container-tools mailing list Container-tools at redhat.com
> > https://www.redhat.com/mailman/listinfo/container-tools
> 

> _______________________________________________
> Container-tools mailing list
> Container-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/container-tools
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20150414/6aad44ed/attachment.htm>