Ownership, Governance, TM, etc

[mikeal]

I hate to be "that guy" but I would like to know what the plan is here in terms of ownership, governance, and the trademark, although I'm skeptical you could actually trademark "rocket" :P

The post announcing this project cited some divergences in philosophy from Docker (the project and the company). It would be good to know if this project intends to be a pure community effort or if this is just CoreOS disagreeing with Docker.

It would be great to see a contribution policy that laid out how people get involved in the project and contribute to decision making and how contentious issues like the ones that have coalesced in Docker that lead to this project would be resolved. If not it would seem like people are just trading Docker (the company) for CoreOS (the company).

[polvi]

We would love your opinion on it. Our plan is to break App Container into something that is more independent once we see outside adoption. We are happy to structure that in whatever way makes the contributors comfortable.

[mikeal]

As far as contribution policies, I'm a fan of @rvagg's OPEN Open Source model https://github.com/rvagg/node-levelup/blob/master/CONTRIBUTING.md Would be great to apply that model to membership in the org that owns the repository.

Eventually you can image the spec and the implementation being in separate repos as well, which would allow people to edit the spec and participate in the decision making process that are working on alternate implementations.

[polvi]

Yes, we nearly shipped with them as separate repos, but we thought that'd be too confusing to explain to people since there are not other implementations yet available. Will take this feedback and we develop the project.

[polvi]

Please re-open if you want to keep chatting about it, not sure what else to discuss at this point until things evolve.

[polvi]

Also, this feels a little like a quick close-- sorry about that. Again feel free to reopen if you want to keep exploring. Not avoiding the topic at all. Just not sure what the answer is yet.

[rvagg]

The benefits of being fully open are:

• Huge buy-in from contributors outside of the sponsoring company, you essentially give away a slice of ownership to anybody making meaningful contributions
• Community building--the community builds itself because people flock to something they see they can have a real impact on, you don't need a community manager because the community runs itself
• Relevance--people come and go as their interests and needs change but because you're effectively offering people a chance to have a say in how the project should work and where it should head you end up attracting people who have real needs and want to solve real problems

For me, and a lot of other people I know, I now find it very difficult and frustrating to be involved in (or release my own) projects that are not properly open and able to adapt and change to people making serious contributions. BDFL and corporate-driven open source is an anti-pattern for collaboration and community. In the Node community at least, extreme openness as a governance model is spreading surprisingly fast.

Of course the downsides are all about control and whether you're interested in giving it up. I personally get a thrill out of having to engage in tough discussion with people to argue my case for how things should be and potentially be out-argued or our-voted or convinced of alternatives by people with passionate opinions. This is generally not the case for highly opinionated developers who have a vision solidly within their heads and just want to drive towards that without too much distraction.

As for Rocket, I'd love this to be community-driven! I've been bemoaning the rise of Docker as a narrowly focused way to achieve containerisation and would love a flexible alternative that can fit a wider range of use-cases!

[timothysc]

IMHO we should keep this open, as it should be an ongoing thread until it takes shape.

One of the largest frustrations with Docker was the closing of issues even though there was no resolution.

[jonboulle]

@timothysc I will re-open for now, do you want to add some thoughts on how you would like to see the project governance structured?

[timothysc]

@jonboulle perhaps enumerating the options makes sense.

I'm most familiar with:
https://wiki.openstack.org/wiki/Governance
http://www.apache.org/foundation/governance/

From there, a cost+benefit analysis can be done.

[tnachen]

I'm only familiar with apache, but definitely suggest going that route.

[davelester]

@tnachen +1 to the suggestion of Apache

[ConnorDoyle]

👍 for ASF governance

[mikeal]

-1 on ASF.

[tnachen]

@mikeal Have a better alternative?

[mikeal]

@tnachen Honestly, there isn't really one. jQuery has put together a pretty compelling offer for web projects and I hear Dojo is trying to do the same. If you get some traction the best option is actually to start your own through the Linux Foundation's Collaborative Projects initiative.

[caniszczyk]

+1 to ASF or similar foundation (I would be OK with the LF or EF as options too)

[tnachen]

@mikeal thanks for the suggestion, definitely need to learn more about the LF initiative.

[ConnorDoyle]

It might help to be explicit about what people care about to find common ground. @mikeal could you outline the aspects of ASF you'd like to improve on?

[technicool]

I created a separate github organization & repo for the app container spec at https://github.com/app-containers/app-container-spec

I am open if and when the community wants to use this as a launching point for the separation of projects.

Hopefully this is helpful, and is not in any way confusing or an issue.

Looking forward to the development of Rocket and a truly open container format!

[mikeal]

+1 Great to see :)

[philips]

Hey guys, it is great that you all want to get involved! We certainly want to figure out how to build a community around this and separate the spec from this repo in the future. But, I want to hold off until we have a clear set of maintainers outside of the Rocket devs.

Here is how I propose we figure out who maintains the spec: Once there are two more independent implementation of the app-container standard then we have a nice quorum of parties to guide the development of the spec. We can then move the spec to a dedicated repo and establish those parties as the official maintainers.

Until we get this quorum of folks in the short term it is helpful to keep it in the rocket repo here because there are a number of in-flight issues (see below) that need exploration in code and the spec at the same time. What I am hoping to avoid is designing the spec in a vacuum from real code in the short term.

How does this sound to folks? There is a lot to figure out and I want to keep focused until this community gets organized.

@technicool Does this address your concerns for now? Would you be willing to remove your repo with this being the plan?

#187
#186
#185
#182
#127

[technicool]

That makes sense... I'll update the repo to point out that all spec work should happen here until further notice.

I am interested in possibly adding on support for Docker or LXC directly, so I'm glad to see how the community is shaping up.

[ddbenson]

Why not separate spec from the rocket implementation now? I think it's more confusing to keep them together. What is the likelihood and timing of two additional implementations of the spec at this point? Just rip the bandaid off now.

[errordeveloper]

+1 separate spec. A good example would be rust-lang/rfcs, which is a place with a lot of activity and having that in the code repo would be unbearable.

[jlhawn]

+1 for separating into a org and with repositories for specification and implementation.

I often shy away from getting involved in long discussions on IRC or Github, but having a standard image format is Very Important to me, and I would love to begin working on supporting this as a standard Image format for Docker, too. Users should be able to run an app container image with either Rocket or Docker without having to go through some conversion step first. I think the teams from Docker, Inc., CoreOS, Inc., and the broader community should work together towards a v1 specification and implementation/library in Go that can be used by both Docker and Rocket. I don't see much of a point in having separate implementations if we could be more productive developing a shared implementation.

There's also been a lot of discussion and explorative implementation on https://github.com/docker/docker about changing the image format used by Docker to something much better. We've just been calling it "v2 images" with a lot of work revolving around a new JSON image manifest, content-addressable rootfs layers, and changes to the registry API. I'd be very happy to move all of these discussions to one central place where we can all work together on shaping this new image format and openly discuss issues directly related to images: content discovery, distribution, trust/provenance.

I even had the same idea as @technicool and made a new org: https://github.com/app-container (it's funny that one of us thought plural and the other singular!)

Once [...] we have a nice quorum of parties to guide the development of the spec. We can then move the spec to a dedicated repo and establish those parties as the official maintainers.

As a Docker, Inc. employee I'd very much like to be a part of this.

[polvi]

@jlhawn collaboration on the container spec is exactly the type of work we would love to do with Docker, Inc and docker itself. We are even open to helping implement the spec inside of docker itself, if fitting.

We are still planning to break the spec out (should happen this week). We have github.com/appc and github.com/containers available as well. Right now we are leaning towards github.com/appc. That way we could do appc/spec, appc/tools, etc. Thoughts?

[jlhawn]

I don't have any strong opinions on the name of the organization as long as its role is clear, community-lead, and ends up being the place to discuss the specification and implementation of tools/libs around the app container image. As you suggested, appc/spec and appc/tools sounds fine. Seems a bit short perhaps, but naming things is one of those hard problems ;-)

[jonboulle]

There's also been a lot of discussion and explorative implementation on https://github.com/docker/docker about changing the image format used by Docker to something much better. We've just been calling it "v2 images" with a lot of work revolving around a new JSON image manifest, content-addressable rootfs layers, and changes to the registry API.

@jlhawn could you link to some of these explorations?

[jlhawn]

could you link to some of these explorations?

Sure thing!

There is an issue for a high-level goal of self-describing images: moby/moby#6805

An initial proposal issue was opened a while ago: moby/moby#8093 This gives an early design of an image manifest which includes content-addressable IDs for image layers and wraps their corresponding v1 image JSON (In v1 every layer had its own JSON manifest and randomly generated ID). It also lightly describes the v2 registry API and docker has actually been using this for pulling and verifying all official images since the 1.3 release 2 months ago.

There's a proposal for the next-generation registry API: moby/moby#9015 with development currently being done over at https://github.com/docker/docker-registry/tree/next-generation.

I've got a proposal for a new signed token based authorization scheme to be used for the next-gen registry: moby/moby#9081

And I've got a branch on my fork where I completely changed the image format in Docker. https://github.com/jlhawn/docker/tree/imagestore I haven't updated it in a while (it changes so much that it's unmergable with upstream) but it works like regular docker except no push or pull. It instead relies on docker load and docker save. The bulk of these changes can be found in this package: https://github.com/jlhawn/docker/tree/afd8f5e0d486e30f70d67920cb4c5fab15cef747/imagestore and then I changed various things throughout Docker to get it to use that new format - changes to the builder and daemon/container handling.

I think this is pulling the thread off-topic now, but to circle back.. it'd be great if we had one place to discuss all of this 👍

[justinsheehy]

+1 for the image format being community driven.

I'm very happy to see this turning toward an open and collaborative process.

(-1 on emulating OpenStack's governance in any way, however)

Having all such tools (whether from Docker, CoreOS, or other participants) be able to use the same images without cumbersome conversions will help us all to build better systems that work well together. This would be a tempting place for a privileged party to exert control over an ecosystem; preventing that control will make it more likely for a healthy community to grow.

[unknwon]

+1 on ASF

[tzolov]

+1 on ASF

[lgs]

@jlhawn @polvi @ALL

RFCs is the way, if you want a standard on Internet, since Steve Crocker on 1969!

Here are some good drafting examples on github:

https://github.com/igrigorik/http-client-hints
https://github.com/http2/http2-spec
https://github.com/zeromq/rfc
https://github.com/rust-lang/rfcs

More extensively RFC on GitHub

Collaboration on the container spec should start. Ownership, Governanceovernance and Trademark should be monitored too.

+1 @mikeal (see previous O.G.T)
... and please, realize that trademark sucks (see: Docker is a trademarked product)

[mnot]

Governance, IPR, etc. are important to establish first; standardisation comes pretty much last. The only RFC you really need here is a media type registration if you want such a thing for a container format...

[philips]

This issue was moved to appc/spec#21

[jonboulle]

appc and rkt are now clearly separated and the dependent issue here (appc/spec#21) is now resolved (via appc/spec#282) so I am going to close this out. We are always interested in feedback (and actively seeking more external maintainers for the spec itself) so please don't hesitate to reach out if you have any further questions or suggestions.