I'm going to try arguing the pro case. The big tent has us bringing any *team* that want to work the way we do: in the open, collaboratively, in concert with other teams, into OpenStacks community.
Why are we using implementation language as a gate here? I assert that most deployers don't fundamentally care about language of the thing they are deploying; they care about cost of operations, which is influenced by a number of facets around the language ecosystem: packaging, building, maturity, VM behaviour-and-tuning-needs, as well as service specific issues such as sharding, upgrades, support (from vendors/community), training (their staff - free reference material, as well as courses) etc. Every discussion we had with operators about adding new dependencies was primarily focused on the operational aspects, not 'is it written in C/$LANGUAGE'. Right now our stock dependency stack has C (Linux, libc, libssl, Python itself etc, Erlang (rabbitmq), java (zookeeper). End users emphatically do not care about the language API servers were written in. They want stability, performance, features, not 'Written in $LANGUAGE'. As a community, we decided long ago to silo our code: Nova and Swift could have been in one tree, with multiple different artifacts - think of all the cross-code-base-friction we would not have had if we'd done that! The cultural consequence though is that bringing up new things is much less disruptive: add a new tree, get it configured in CI, move on. We're a team-centric structure for governance, and the costs of doing cross-team code-level initiatives are already prohibitive: we have already delegated all those efforts to the teams that own the repositories: requirements syncing, translations syncing, lint fixups, security audits... Having folk routinely move cross project is something we seem to be trying to optimise for, but we're not actually achieving. So, given that that is the model - why is language part of it? Yes, there are minimum overheads to having a given language in CI - we need to be able to do robust reliable builds [or accept periodic downtime when the internet is not cooperating], and that sets a lower fixed cost, varying per language. Right now we support Python, Java, Javascript, Ruby in CI (as I understand it - infra focused folk please jump in here :)). A Big Tent approach would be this: - Document the required support for a new language - not just CI - Any team that wants to use $LANGUAGE just needs to ensure that that support is present. - Make sure that any cross-service interactions are well defined in a language neutral fashion. This is just good engineering basically: define a contract, use it. Here is a straw man list of requirements: - Reliable builds: the ability to build and test without talking to the internet at all. - Packagable: the ability to take a source tree for a project, do some arbitrary transform and end up with a folder structure that can be placed on another machine, with any needed dependencies, and work. [Note, this isn't the same as 'packagable in a way that makes Red Hat and Canonical and Suse **happy**, but thats something we can be sure that those orgs are working on with language providers already ] - FL/OSS - Compatible with ASL v2 source code. [e.g. any compiler doesn't taint its output] - Can talk oslo.messaging's message format That list is actually short, and those needs are quite tameable. So lets do it - lets open up the tent still further, stop picking winners and instead let the market sort it out. -Rob __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
