Acceptance Factors

I'd say a combination of various things, but I don't think they are all required. Some languages considered mature nowadays clearly do not satisfy some of these.

I'd say a combination of:

• Tooling:
  • mainline: At least one stable "official" or widely-accepted (de-facto or vendor-recommended/supported) tool suite (compiler, interpreter, vm, editor).
  • alternative: Some stable and not-so-stable alternatives of the above tooling (closed or open source variants, free or commercial variants, extensions, etc...).
• Community: An active , but not necessarily large group of followers and contributors.
• Recognition:
  • Some degree of recognition and use by some industrial actors (even if in a niche).
  • Some degree of recognition in popular culture (even if in a niche).

On Fame, Recognition and Maturity

Note that the differentiator here is on having strong and active criteria validators, not large or numerous ones. To clarify, consider these vastly different examples:

• Ruby was for a long-time a language with a large community-backing, an official reference implementation and so forth but could hardly be considered mature until it ironed out some of its rough edges. It was famous before being mature.

• On the other hand of the spectrum, some once very-widely used languages (COBOL, FORTRAN...) are now less visible but are still mature in every possible sense. They were once famous and mature.

• Also, some niche-languages are in my view definitely mature, inspite of their small (but established) market penetration. Consider Oberon or Limbo. They are mature but never got famous. Others, like R, are relatively famous in that their "niches" aren't really niches (bugs me when people call things like Scala or Clojure "niche languages", which they definitely aren't), though their field of applications are not exactly what you'd call mainstream.

On Stability

What's stable anyways? It's quite relative...

• Compliance?
  • To the standard (if there's one)?
  • To a reference implementation (if there's one)?
• Number of bugs? (hardly a good measure)
• Use in critical environments?

In general, stability simply means I don't get surprised on a daily basis when going about my average job using the language's toolkit, and I can get definitive answers on what should or should not happen when I attempt to do something with the language and its toolkit, whether it's at the build-time or runtime of my programs.

But stability for someone writing smartphone apps and stability for someone writing medical or avionics systems is a different kind of bird.

Disclaimer.IANAL();

You can't copyright a programming language no more than you can copyright a spoken language. You can license a particular implementation of the language and even sell that compiler much how Borland did with Delphi for many years.

Many languages today have a BDFL (Benevolent Dictator for Life) who determines what goes into the language and what doesn't. Python, Ruby, and Perl are all examples of that.

Other languages have officially designed standards by one of several standards boards, typically ANSI, ECMA, or ISO. Examples include C, C++, and Javascript.

Some languages fall into murkier areas due to politicking between companies. Java is an example because Microsoft sits on some of the standards boards.

Some languages move from one to another, typically from BDFL to Standardized, C is a good example.

Depending on the specification of the language, some compiler writers may implement different features in different ways (CPython vs PyPy for example) or add features (Microsoft C++ vs GNU C++ or MySQL vs PostGreSQL vs SQL Server)