openstack
/
governance
Code Issues Proposed changes

OpenStack programming languages resolution 

Clearly frame the benefits and costs of adding a new programming
language to OpenStack, and clarify under which conditions new
programming languages may be added to OpenStack in the future.

Change-Id: Ife17393b7e119a69952ead0d3d426697ed5a7ed9
This commit is contained in:
Thierry Carrez 2015-08-27 15:24:04 +02:00
parent 91d4b383b5
commit 48ae706431
1 changed files with 46 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
resolutions/20150901-programming-languages.rst Normal file
View File

@ -0,0 +1,46 @@
============================================
2015-09-01 OpenStack Programming Languages
============================================
Every programming language is designed to solve a slightly different
problem space and comes with its own benefits. OpenStack started out
with only Python, a "batteries-included", operator-friendly, highly
readable and easy to learn language. Over time, we added bash and
JavaScript, which both address slightly different problem spaces where
Python was either suboptimal (system scripts) or not available (in-browser
execution). At the date of this resolution, the supported languages in
OpenStack are therefore: bash, javascript, python. However we should *not*
limit OpenStack service projects to these three programming languages in the
future, as it would either mean using suboptimal tools, not being able to
address specific problem spaces, or artificially excluding specific project
teams.
At the same time, we recognize that supporting more programming languages
comes with a community cost. Every added language needs to be properly
supported by cross-project efforts (like infrastructure, QA, release
management, vulnerability management, documentation...), efforts which
already struggle keeping up with the current set of languages (JavaScript
is still not totally supported by those). Every added language also further
fragments our community, and requires extra care to converge to our common
culture, which defines "are you OpenStack" in the context of the big tent.
Because we recognize these considerations, the OpenStack Technical Committee
will allow additional language support in OpenStack projects on a case-by-case
basis, carefully weighing the technical benefits of supporting the new
language against the community costs of supporting it.
We already recognize a number of standing exceptions to this rule:
* short-term experimentations in feature branches
* temporary legacy code, as long as the medium-term plan is to completely
remove it
* downstream packaging, which uses the specific language of that particular
trade (like Ruby Puppet recipes)
* project infrastructure configuration files, plug-ins or extensions, where
the language is dictated by the tool being used or integrated
* downstream language SDKs, which obviously are implemented in the local idiom
The general idea is that this resolution applies to upstream OpenStack
services and libraries which are our main deliverables, not to downstream
integration projects or development infrastructure. The Technical Committee
will use common sense when considering those requests on a case-by-case basis.