Quality control in open source development

[Samuel A. Falvo II]

On Oct 8, 8:43 am, Dave <dggoodwi... at gmail.com> wrote:
> With the open source licenses that allow redistribution of modified
> code, how do you keep someone unaffiliated with the Python community
> from creating his or her own version of python, and declaring it to be
> Python 2.6, or maybe Python 2.7 without any approval of anyone at the
> PSF? Maybe their code is terrible, and not even compatible with the
> rest of Python! How can the PSF, for example, maintain the quality and
> coheren of new code contributed to be part of Python, or derivative
> works that claim to be some future version of Python? If licensees can
> redisribute as they like, isn't this a huge problem? Is this dealt
> with be restricting use of the Python trademarks?  Just curious..

Most trademark violations have occurred, to the best of my
recollection, by commercial entities trying to usurp the popularity of
an open-source endeavor for their own commercial gain.  It is very
rare that another in the open-source community will commandeer the
good name of another project for his own purposes.

This gives strong credence to the idea that the highly participatory
nature of the open-source community serves as a strong, self-enforcing
deterrent to negative acts of this nature.

As far as quality assurance itself goes, independent, third-party unit
test suites are easily engineered.  Parties who do manage to succeed
in releasing their own "Python 2.7" can do so only by either making
their product compatible with this third-party verification suite, or
by not doing so.  This leads to two situations:

(1) If compatible, then the name "Python 2.7" may well be accepted by
the community, even if only in an allegorical sense (e.g., "If PSF
released Python 2.7, this product is how I envision it'd be like.").
Alternatively, people will recognize the product as being Python-
compatible, but otherwise an independent line of development -- e.g.,
a fork.  The PSF can then release under a new set of version numbers
(where everyone understands that 2.7 is an independent fork not
endorsed by PSF), persue negotiations (ultimately terminating in legal
action) to arrive at an acceptable product name, etc.  If the PSF were
feeling particularly benevolent, they could even accept some ideas
from the 2.7 release into their own branch of development.

(2) If incompatible, the product will gather a reputation of
inferiority rapidly, and those clearly interested in Python will
neither want nor have anything to do with this misbranded malfeasance.

Again, independent verification is an example of the participatory
nature of the community at large, and is a prime example of how
concerned citizens can act collectively in their own interest,
independently, to help ensure the quality of a socially-accepted
product.