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

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


On Tue, Jun 6, 2017 at 1:01 PM, John Luke Gibson <eaterjolly at gmail.com> wrote:
>> "well everyone does it so we don't need to take
>> special note of it" is how, historically, utterly valuable knowledge
>> has been lost through the ages.
>
> That's a very valid point. However I think the point of a standards
> organization should be to spread information about their standards
> that aren't widely or commonly known and it highly useful. Ultimately
> there will be some very new people looking for information, and for
> them knowing about the usefulness of version control would be
> important. Again, though, if only mundane things like that were taken
> on as a core tenets, I don't think anyone would take the organization
> seriously.
>
>>  then, not least, you will discover that actually, everybody uses
>> github "by default".... which, when you read (and take) the software
>> engineer's hippocratic oath you find that it's very hard to honour
>> that oath and use github at the same time.
>
> I don't think there is much wrong the way github is designed, so much
> as it's

 ... you mean the word "its", not the two words "it" and "is" which
are abbreviated as "it apostrophe s".

> economic model for sustaining itself. It requires closed
> source software development to survive. That's naughty.

 it does deeper than that, in a very seductive and insidious way.
what is the primary focus - what does github drive people to do, that
distinguishes it from sourceforge, savannah, alioth, codeforge and
other group collaboration systems?


>
>>  if they're "developing" then by definition they *are* developers,
>> whether they think of themselves that way or not.  in the hippocratic
>> oath (both the original and the engineering version i found) it
>> mentions that both practices combine art *and* science.
>
> We really don't want to throw around that label,

 what ambiguous concept are you referring to with the word "that"
which has not been made explicitly clear?  there are about 40 words in
the paragraph that you are referring to: i have no idea which one the
word "that" refers to.

> Essentially the point is, in a large open development, odds are there
> will be people more senior and more novice to you. To develop the most
> difficult code 'for you' possible, we prioritize personal development
> over project development. I think that's a pretty solid general rule.
> If the code is really sincerely important, someone will clean up your
> mistakes and use your successes.

 not if they are there to further their own personal agenda because
there is no "Charter" to keep them goal-focussed, they won't.  there
are a number of large software libre projects where individuals have,
over time, used their technical expertise to become the most vicious,
horrible, deceptive bullies you will ever encounter in a technical
environment.  their peers become *so afraid* to do something about it
that these people *remain* in power, abusing others whenever the
opportunity presents itself.

 this is something that i have encountered not just once but
*multiple* times, in several extremely high-profile strategic software
libre projects.


>>> Most of us know it's not uncommon for very large projects to receive
>>> access to proprietary source code under NDA, just to mod it**.
>>
>>  we are automatically excluding advice to proprietary software groups,
>> so this is not a concern.
>
> For one,
> I think that's problematic. There are some projects to advance
> humanity stuck in closed-development, sometimes for honorable
> not-profit-motivations. Take radar development for example. Or, AI
> development. The last one is a hot-button topic, but I think AI
> development has to be relegated to those careful to avoid AI hating
> us.

 true.

 however - and i am applying the "Bill of Ethics" here - the Bill of
Ethics is very clear as to what to do in these situations.
"Creativity" is defined as "resources times intelligence".  therefore,
if someone is using Creativity for unethical purposes (where in this
case we *know* that proprietary software is unethical.... let's not
argue about that), then there are two options to ETHICALLY undermine
their unethical objective:

 (1) reduce their access to resources
 (2) reduce their access to intelligence enhancement.

 now, in the process of writing a standard, we do not have the means
to (directly) reduce the amount of resources that unethical
proprietary software teams have access to, but we *can* reduce their
access to intelligence enhancement... by *SPECIFICALLY* designing the
standard so that it targets ETHICAL software development, and that
means LIBRE SOFTWARE ONLY.

 i am NOT going to aid or assist unethical practices - period, luke.
i will NOT be involved in ANY WAY in the development of a standard
which could be utilised for the advancement, augmentation,
acceleration or improvement of unethical software development
practices, and that really is the end of the matter.

> * https://robertsspaceindustries.com/about-the-game
>>> [blah blah, about choosing between proprietary and free software]
>>
>>  i don't understand where you're going with this.  what is the main point?
>
> Most projects will be hardware projects and, like with your decision
> not to use kicad,

 that's mainly to do with the fact that it's shit software.  sadly,
it's only when you've utilised well-written proprietary software that
you realise quite how hostile kicad actually is to getting the job
done.  i'm not very happy about that, but it turns out that i am not
the only person to have tried.

> there will be many incidences where open projects
> need to decide between modding-up open software or using proprietary
> software. Occasionally, the former is just not practical.
>
> A standards organization, would do best to make sure they weighed both
> possibilities realistically and didn't just assume one or the other
> was more practical.

 no.  sorry.  i cannot be involved in anything which is unethical.
that is ABSOLUTE and non-negotiable.  the consequences for me to be
involved in anything that is unethical are too disastrous to
contemplate.

 writing a high-profile standard (which is to be published by the FSF)
that helps proprietary software to improve its success would be
totally unethical.

>>  again, i feel that it is not appropriate to tell people these kinds
>> of things, as it would be a restriction on what they do and learn.
>> counter-example: some projects *have* to have a large code-base, by
>> definition of their goals and scope.
>
> I recognize that intuitive isn't always concise, but often it is.
> I only mean concise when it means intuitive.
> If a projects roadmap demands a large code base that is
> highly-esoteric and unintuitive, then that exhibits fault in the
> underlying language.

 no it does not.  certain tasks *require* specific languages.  for
example: the linux kernel *requires* that you use assembler and c.
UNDER NO CIRCUMSTANCES is c++ permitted to be utilised.

 likewise, python is also developed in c.  you can look up how pypy
has been getting on, to find out how unsuccessful it was to attempt to
implement python in anything other than c.

 also you can look up the efforts by the samba team to abandon c and
to try to write parts of samba 4 in python.  this was also a
spectacular and long-drawn-out failure.

 in the case of samba, it has to be realised that samba is an
amalgamation of something like over TEN different network protocols,
at least FOUR separate and distinct RPC mechanisms, and over FORTY
separate and distinct inter-related services!  the complexity of the
endeavour is just... astounding.

 when samba 4 was first announced i thought it was a joke.  they
intended to implement not only the MSRPC services, but also to
implement their own Kerberos Server and LDAP server.  what the FUCK??
Heimdal is a QUARTER of a MILLION lines of code on its own.  openldap
is likewise similarly large... and samba is probably getting on for
HALF a million lines of code WITHOUT these projects added to it!

 they're completely out of their MINDS if they think that's going to
work... or be accepted by sysadmins... and guess what?  10 years later
they still hadn't finished, and 15 years later they'd driven pretty
much every single large Enterprise (that had deployed samba for years)
right back to Windows NT Server!


 the reason i am mentioning the example of Samba is because despite
following what is known to be "best software libre hosting practices",
they DO NOT HAVE A CHARTER and the developers *certainly* do not sign
up to the Software Engineer's variant of the Hippocratic Oath.

 there is more, but i will relay that another time.

>>> This is just a rough start, but I wanted to post it here and get
>>> feedback before putting it on the wiki.
>>
>>  wrong focus / direction, john.
>>
>>  the first step *really is* to quite literally copy - verbatim - the
>> gnu devel.html page and "generify" it.
>
> No one will want to advice from an organization that bible thumps the
> same points, much less financially support them in exchange for doing
> so.

 do you understand why those software development practices (with the
addition of a Charter) listed on the gnu devel page are so effective?

 ok let's go over it.

 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.




>>  where it says "we recommend savannah" put instead "we recommend the
>> use of a Libre Hosting Service which has a minimum criteria of an A,
>> as defined by the FSF's Hosting Criteria".
>
> Eh, 0-to-1.

 i don't understand this colloquial turn of phrase.  anyway it is not
important: going through the list above is much more important.

>  I don't think were a
> person stores their code should be a huge point of tension.

 i know you don't.  so i therefore need to walk you through the
process of understanding why it is, in fact, one of *the* most
important factors (in amongst many of roughly equal priority).  going
through that list, above, will help to do that.

l.