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

[John Luke Gibson]

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

Version control is almost ubiquitously used for source code, to the
point it should hardly need mentioned; 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.

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

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

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

This is just a rough start, but I wanted to post it here and get
feedback before putting it on the wiki.

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. Take a look at this:

"to impart precept, oral instruction, and all other instruction to my
own [kids], the [kids] of my teacher, and to indentured pupils who
have taken the physician’s oath, but to nobody else."***

That last bit of 'teaching no one else' is a little tongue-and-cheek
for the free software movement xD But, still, it has this aura of
freedom of information that's interesting for ancients.

In fact most of the last two and the first two clauses, mutually apply
to software.
I'm the artistic type who would take the original oath and edit it to
apply to software****.


* https://www.youtube.com/watch?v=tkm0TNFzIeg
** https://www.youtube.com/watch?v=yisaDxvBH9s&t=5m50s
*** https://en.wikipedia.org/wiki/Hippocratic_Oath#Text_of_the_oath
**** https://en.wikipedia.org/wiki/Intertextuality

On 6/5/17, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> On Wed, May 31, 2017 at 6:17 PM, Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
>> huh.  hmmm, if it's ok with you i might run that by dr stallman, see
>> what he thinks.
>
>  ok, so i spoke to dr stallman, it took me a while to get across the
> idea, and after clarifying it he said, *in effect*, "please could you
> write up some developer best practices as long as every GNU Project
> would automatically conform to them".  he didn't exactly say that, so
> please do not quote me on it.
>
>  the starting point should be to take this "list of project *SERVICES*
> offered to the GNU project"
> https://www.gnu.org/software/devel.en.html
>
>  and turn it into a list of *GENERAL* project *RECOMMENDATIONS*, using
> the GNU server services as... like... the "Gold Standard".
>
>  the one thing that is missing from this list is a "Charter" - like
> how the Apache Software Foundation has a Charter.  i am not entirely
> sure what to advise / do on that.  over the past 20+ years i have
> witnessed many high-profile projects treat good people in some pretty
> horrible ways - not once and not on just the one project but many many
> times.
>
> the Apache Software Foundation on the other hand, whilst they have had
> problems, their Charter has allowed them to (formally) keep things
> "civil", including being able to remove a project leader who clearly
> did not understand the harm he was causing to the project, through his
> actions.
>
> also worthwhile considering is adding the recommendation for
> developers to take the "Hippocratic Oath for Software Engineers".
>
> http://farmerandfarmer.org/medicine/printable.html
>
> the nice thing about that oath is that it can just be added simply to
> make people aware of it... *without* actually requiring that they take
> it.
>
> anyway i have started a page here in order to coordinate ideas and the
> actual proposal:
>
> http://rhombus-tech.net/proposed_best_practices/
>
> l.
>
> _______________________________________________
> arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
> http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
> Send large attachments to arm-netbook at files.phcomp.co.uk