[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 Mon, Jun 5, 2017 at 10:47 PM, John Luke Gibson <eaterjolly at gmail.com> wrote:
> Alrightie~!
>
> Foremost, since "existing" free software and cultural works aren't
> likely to be sold, I think a libre software standards organization
> wouldn't certify individual works or pieces of code, so much as
> projects as a whole including roles performed by non-developers

 indeed.

> Version control is almost ubiquitously used for source code, to the
> point it should hardly need mentioned;

 absolutely dead-wrong.  it needs *absolutely* to be clearly defined.
the practice of saying "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.

 a good example is all the folk tunes of medieval times: *nobody knows
them any more* because quotes everybody knew them quotes so NOBODY
WROTE THEM DOWN.

 so no, john: it *is* critical that everything that's ubiquitous and
quotes obvious quotes be formally documented.

 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.


> however very rarely are
> non-source project files, such as .blend files, collaboratively
> designed this way. I don't think people are unwilling to use version
> control in this way, rather they just don't think of it since most
> artists aren't developers and art has been digitally designed for much
> longer than version control systems have been easy to use. So I think
> uploading files to repository and saving changes as commits, would be
> a good 'non-developer' "best practice" to apply to a software
> certification standard.

 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.


> Anyways, developer 'best practices'.
> Having idle hands study and document code, particularly esoteric parts
> or parts they, the contributors, are unfamiliar with (so they can
> learn it*). Generally, the instinct we are taught from criticisms of
> our artwork, is that 'if we can't do something well, it's best not to
> do it at all', however with our version control systems generally the
> opposite is much more likely true, leaving room also for the hopefully
> soon to be colloquial: "if a task seems too easy, it is best leave it
> for someone else more novice; if a task seems too difficult, it is
> best to do it sloppily, so someone else won't have to do it start from
> nothing". So I think doing the best we possibly can do to develop the
> worst code and worst documentation we possibly can, (xD) is another
> good developer 'best practice'.

 ok... there are two different definitions of "developer best
practices".  the above goes into detail on how an individual developer
should best carry out the development process; the document that i
would like to see written is one which helps people (covering both
users *and* developers) to work as TEAMS.   what INFRASTRUCTURE and
general mind-set will help people to work together.

not "as a developer we must apply Agile or other Methodology".  that's
not appropriate: we have no proof that Agile or other "Methodology"
will be more effective than any other, and i don't believe it to be
appropriate for us to even research that.


> 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.

> Likewise libre software is often perceived as insufficient as-is,
> however proprietary software can be close enough that it is more
> practical. In these cases, we need to respect reality, however also
> ensure all is carefully weighed. The biggest pitfall is looking at all
> the forks, addons, and extensions, then also looking at what you would
> like to do that one can't with proprietary software out of the box.
> Whilest being careful not to berate preferences, looking at how
> modifiable the base program is and what it could accomplish rather
> than what it can accomplish, is an important thing to make sure both
> project's developer's and non-developer's occasionally remember to do.
> So, considering what we could do more proportionally with what we can
> do, is an important developer and non-developer 'best practice',
> especially since as least occasionally they'll make one of their
> could-do'es someone else's can-do.

 i don't understand where you're going with this.  what is the main point?

> Another practice that kindof ties in with the other one, and an often
> unsung aim of the GNU project as a whole, is make programming easier.

 to make *programming* easier or to make *collaboration* easier?

> Occasionally, a project will have extra resources or
> volunteers/contributors than their described roadmap warrants. Not
> always is this obvious from the beginning when it does happen. In
> fact, usually it isn't till the end that it becomes apparent. The
> ideal would be say 'even if proprietary software is more practical,
> use/extend free software for the benefit of everyone when you have the
> resource', but the reality is very rarely will you know you have the
> resources until it's far too late. Instead, a good programming
> practice might be to use the extra resources to modify the language
> itself or some api to make the code smaller. We all should know line
> counting is a trap, but we should also know we are more likely to read
> a pamphlet than a book. So, it should be a good developer 'best
> practice' should be to use extra resources at the end to make your
> code intuitive and concise, and to fork others so hopefully
> adaptations to libraries and compilers that make your code more
> concise and intuitive get upstream.

 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.

> 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.

 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".

 where it says "we recommend mailing lists on gnu.org" put instead "we
recommend the use of software libre hosted mailing lists".  a later
revision should go into further detail as to *why* "announce",
"users", "dev" etc. is recommended.

 etc. etc.

 this is a completely different focus from advising people on *coding
methodologies*.



> I really like the analogy of medicine to software development,
> particularly the use of the Hippocratic Oath as a point of reference.
> I was looking at the 'original' oath, and there is an interesting
> intersection with the morals of free software.

 indeed there is.... but that is simply not understood by the majority
of people associated with free software.  you can usually tell who
they are because they use the words "open" and "source".

 which is why i feel it should be part of the recommendations.  again:
it is one of those things which is never really discussed because
those people who *do* understand it just... follow it (without talking
about it) and that means that those people who *don't* understand get
really *really* confused and misled.

l.