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

[Luke Kenneth Casson Leighton]

On Fri, Jul 14, 2017 at 2:18 PM, Jean Flamelle <eaterjolly at gmail.com> wrote:

>>  well... would you like to help evaluate some of the long-standing
>> well-known free software projects out there?   i vaguely recall making

> I would be glad to do that!

 yay!

> I think it would be very important to focus on projects that create
> software or firmware, which are of particular relevance to
> non-programmers. I think this because they'll likely be under
> significantly disproportionate proportionate pressure compared to the
> amount of contributions to code that they receive. Blender, Gimp, and
> Aperture, are just a few that come to mind immediately, but projects
> like RISC-V and Kicad would arguably also count since there are still
> large portions of their audiences likely specialize very far away from
> the type of software programming knowledge required to contribute.

 oo good point.  yeah feel free to add some to the list.

 doing the samba one, it really didn't take long.  took about... 4
minutes?  looked to see if they have a charter (they don't), looked at
their "dev" page to see if they have a VCS (they do: git), etc. etc.
oh - i forgot one column: IRC channels!

 http://rhombus-tech.net/proposed_best_practices/

 added.

> I think for most people the inclination to donate to any software
> projects fiscally, would be predictable (with a high confidence value)
> by the the ratio of technical programming knowledge and their
> dependence on the software created by that project. For that reason
> you could also say, it would be a higher priority to evaluate gnome as
> as a software project than debian, because ubuntu is more often
> pitched to a less technical audience.

 ok the first phase is: get the info.  evaluation comes later.

> Of course, the fsf already
> evaluates distributions

 not like this they don't.  they evaluate them for *freedom* related
(ethical) criteria.  the purpose of this exercise is to first compile
a list of projects and then "distil" the best and most efffective
*development* practices, by demonstrating provably that, of the top
NN% most highly respected projects, this is what they do.

 that's very very different... and means that the FSF's development
practices (ok actually the GNU projects') are "on the list for
evaluation".


> and doesn't endorse ubuntu anyway, so it would
> probably be perceived in really bad taste if the libre community
> started listing reasons why they gave gnome a poor evaluation score if
> that was the outcome, so I suppose it would be best to avoid it all
> together and only evaluate desktop environments as software projects
> if the are made available in an fsf-endorsed distribution by default.
> (I know I've heard people say trisquel is based on ubuntu, but I don't
> know what desktop environment it uses by default).
>
> All in all, for a base, I think aperture would be a good starting
> point, since GIMP and Blender get a lot of flack that aperture doesn't
> atm.

 well.... we would get to find that out as part of having a look at
exactly what each of those projects do, and then seeing if there's a
correlation, yes?

 but first we need to collect the information.

 oh.  also, we need to make some sort of measure of the
"effectiveness" of the project.  whether it's caused people hassle
(taken up inordinate amounts of time), whether the developers are
liked or despised, whether they are welcoming and supportive of
contributors (or not), how many people use it, and so on.

 it'll actually be quite a fascinating study.


> I realize most of what they are doing is hardware, but their is a
> lot of firmware involved. Also, I haven't heard very many complaints
> about inkscape, so that would be a decent one to start with. I'm
> hesitant to talk about OpenShot or libreoffice early on, because they
> are (as we like to say in the wikipedia community) POV-forks than
> independent projects. In other words, it's impossible to honestly and
> sincerely evaluate LibreOffice as a project without comparing it to
> OpenOffice and likewise OpenShot to Blender and in small part
> Audacity.

 that's *exactly* the point of the exercise.... but that should not be
done *right now*.  at the moment all i would like there to be is a
collation of "info".  3-4 minutes per project, "do they have a charter
yes no do they use version control yes no is their infrastructure
libre-hosted yes no".

that's all.


> Since I don't feel especially confident in my ability handling this
> topic, I would probably sooner get feedback through this thread than
> add any "evaluations" I make straight to the wiki.

 right now all that needs to be done is find the website for the
project, and record what you find.  take a look at the samba one as a
starting point.

> Because of this, I
> think it's important I start by documenting on which ever of the "good
> candidate" projects attracts the most interest in this thread, at
> least on the philosophical level of how they "go about their business"
> if not on a fundamental level of "I really like this project".

 we can discuss that later.  and make sure that ideas on how to
evaluate / compare projects are recorded in the wiki.  but... later.

l.