[Arm-netbook] Standards Organization as a Potentially Universal Free/Libre Software Developement Sustenance Model

[Luke Kenneth Casson Leighton]

when i began a property business i read several books on the subject.
one of them had this wonderful quirky advice to view 100 houses before
putting any money down.  i booked several viewings a day with multiple
estate agents, spending at most 10 minutes in each.

after about 80 houses i came across one that was very strange: the
price was much lower than it was for comparable houses that i'd seen.
without having viewed so many houses i would not have known this.


this same lesson i applied to the development of the EOMA68 standard.
i spent several years studying dozens of successful SoCs, looking for
the common factors between them all.  several iterations had to be
made to get it right.


if we are to develop a standard i feel that it is imperative to do a
similar analysis of what constitutes a successful software libre
project.

this task isn't actually very difficult: it's almost mechanical and
purely logical.  but i feel that it is very important that anything
that goes into the standard is backed up by a heck of a lot of
evidence that whatever advice is in it is demonstrably and
consistently long-term successful across not one but *multiple*
projects.

l.


On Tue, Jun 6, 2017 at 6:47 PM, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:

>  what are the defining (common) characteristics of the following
> high-profile long-running strategic free software projects, and, of
> the superset of those combined characteristics, which projects LACK
> those characteristics?
>
>  * Samba
>  * Wine
>  * ReactOS
>  * Python
>  * Perl
>  * Exim4
>  * sendmail
>  * Linux Kernel
>  * GNU Projects (as defined by that devel.html page)
>  * Webkit
>  * Blink
>  * Firefox
>  * Debian
>  * Ubuntu
>  * Slackware
>  * systemd
>  * mysqldb
>  * mariadb
>  * openoffice
>  * libreoffice
>  * X11
>  * Xorg
>  * Kerberos
>  * Heimdal
>  * OpenLDAP
>
>  make a list of all the things that those projects have in common,
> then, after making that list, identify the things on that list which
> individual projects *do not* have.
>
>  i will then provide you with some illustrations of events that have
> occurred within those teams which have been extremely detrimental to
> the users of those packages.
>
>  we will then cross-reference the things that are MISSING from those
> projects with the detrimental consequences, to see if there is any
> correlation.
>
>  if you can think of any other long-standing high-profile projects
> which should be on that list, feel free to add them.