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

[John Luke Gibson]

> "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 economic model for sustaining itself. It requires closed
source software development to survive. That's naughty.


>  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, it'll be
controversial if we do.
The overall point I was try to make in that clause is, 'everyone
thinks to collaborate on source, but no one thinks to collaborate on
assets'.

I don't think many realize it's possible for 100+ people to
collaborate on a single drawing using version control and effective
curation. It'd be absurd, but it'd be possible. As it stands, most
assets are designed entirely by a single person, because people don't
realize the collaboration tools and methodologies out there.

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

Hmm.. *searches 'Agile development methodology'* I agree.
I always hated those cause they felt like a tight 'inside of the
inside box' structure.
What I'm suggesting here is Definitely a collaborative methodology and
-I think- a pretty abstract and general one.

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.

Yes, I the principle is of focusing on the individual, but there's
nothing more important to remind a collective to do.


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

For two,
Some projects have a goal besides open source or profit. I really like
Star Citizen*. They show us EVERYTHING, except their source. Obviously
they can't because what they are trying to do, Requires modding closed
source software. It's very open, even if it's very closed. If an
organization like that wants to contribute to the development of some
libre software they are borrowing, we should recognize them. Maybe if
we buildup a strong rapport with them, they'll release their game into
the public domain one day just to say 'thankz, for all the lulz'.

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

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

Both. Most languages today are pretty esoteric, even today. And, the
problem isn't so much with the docs, as these languages were designed
for people that already new another language equally esoteric, etc.

I would think Lisp's resurgence (as well as developing Guile) is a
demonstration of GNU trying to break away from that paradigm.

>> [blah blah blah about making programming easier]
>
>  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.

I'm not suggesting any project change to prioritize this. To the
contrary, I think I was quite clear: a project should only dedicate
'extra' resources to this type of endeavor.

>> 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.
I think it is important to develop universally acceptable principles
(i.e. things people find interesting to hear, but not necessarily want
to hear) which are useful.

>  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. Redundancy is nice, but can be confusing. I think it would
probably more effective to just let any libre hosting service which
has criteria A call themselves savanna, but I don't think were a
person stores their code should be a huge point of tension.

Ultimately, in a 0-to-1 paradigm, we are trying to develop closer to
perfection, rather than closer to more competitive. Having multiple
types of libre hosting services is like having multiple
https://en.wikipedia.org/wiki/WP:POVFORK 'es.