Adding new programming languages in OpenStack is possible by following the
process described below. Every new language addition goes through careful
consideration on both, technical and community, aspects. When considering a new
programming language addition, the community must consider whether this language
may or may not fragment the community, what the impact is on the infrastructure
team and systems, how this language impacts the release model, etc.

Innovation is highly encouraged. However, teams experimenting with new languages
should keep under consideration the points mentioned above and the process
explained in this document. New programming languages in OpenStack are added
under specific circumstances where the existing, already accepted, languages
have been proven to not meet the technical requirements and the concerns
at the point evaluation.

The process for adding a new language consists of two separate steps that
require some work up-front. The first step involves the analysis of the need for
a new language and the second one the support for the new language in the
OpenStack ecosystem.

After reviewing and agreeing on the need for a new language, the team driving
this effort should start working on the second phase. The needs of a new
language should not be questioned during the evaluation of the second phase,
unless the team working on it decides the language is not needed anymore.

The TC will evaluate the use case for the new proposed language in this phase.
Members of the community interested in this addition are expected to have
started a discussion on the mailing list before presenting the request to the
TC. It’s encouraged to let the mailing list discussion mature before it’s
brought to the TC.

The discussion should evolve around the needs of the language, the technical
difficulties at hand and the reasons why existing languages are not good enough
for the task. Adding a new language should not be the norm and it comes with a
cost, as explained earlier in this document. Projects should strive for
consuming the existing languages in the ecosystem.

Once the discussion has matured, the request should be brought up to the TC for
further discussion, evaluation and voting in the form of Resolutions.

Work with the documentation team to define the processes for generating,
publishing and maintaining the documentation for projects using the new
language. All projects should use Sphinx for their project documentation and
follow the api-ref standards for their API documentation, should they need one.
The use of language specific tools for other type of documentation (developer’s)
is fine.

Work with the infrastructure and requirements team to define a process for
managing dependencies for the new language similar to the existing
requirements process used for Python dependencies. This process should
describe:

How the dependencies for the new language are consumed

How the dependencies for the new language can be managed, pinned, etc,
if necessary

Most OpenStack projects rely on a set of base common libraries that provide a
seamless experience to operators and users of OpenStack. The team proposing a
new language must provide a compatible behavior with these libraries either by
developing a counterpart version of the library in the language or proving that
the language itself (or any existing library) is capable of guaranteeing
compatibility.

The following libraries have an impact on the operator’s and user’s experience,
therefore their behavior is considered critical and it must be guaranteed by any
new language:

oslo.config

oslo.log

Once the above requirements have been addressed, a final resolution should be
brought up to the TC. This resolution will mark the language as an official
language in the ecosystem. OpenStack projects consuming this language can be
released from this moment on.