LibrePlanet discussion list archive (unofficial mirror)
 help / color / mirror / Atom feed
From: Chad Larson <BPYZs1fx@mailtoo.hungrycats.org>
To: Michael Pagan <michael.pagan@member.fsf.org>
Cc: libreplanet-discuss@libreplanet.org
Subject: Re: 7 Reasons to Avoid Open Source?
Date: Sun, 3 Dec 2017 21:12:55 -0500	[thread overview]
Message-ID: <20171204021255.n5atlesyayeeeuyw@hungrycats.org> (raw)
In-Reply-To: <87lgijhb1b.fsf@member.fsf.org>

On Sun, Dec 03, 2017 at 02:22:08PM -0500, Michael Pagan wrote:
> On 2 Dec 2017 at 23:45, Mary-Anne Wolf <mgwmgw@comcast.net> wrote:
> > This
> > https://www.designnews.com/content/7-reasons-open-source-software-should-be-avoided/100858102757881
> > says, "As much potential as open source software can provide, there
> > are several reasons why embedded software developers should avoid it
> > like the plague."
[...]
> _Let us dissect his arguments, point-by-point, shall we?_
> 
> * Reason #1 – Lacks a traceable software development life cycle
> 
> Incorrect – free software can actually /provide/ a traceable software
> development life cycle.  Anyone who uses a [version control system][0]
> (VCS) knows this to be extremely common among free software projects.
[...]
> The root word of *traceable* is trace, which is a synonym of the word
> *track*, hence VCS allows editors to trace/track each other's edits.
> Yes, free software does not *have* to be version controlled; however, it
> is the norm, and it is wrong to assume that ALL free programs are
> developed without any form of version control.  _Reason #1_ is a lie!

In embedded project context, "traceability" refers to a matrix
of requirements on the integrated product (e.g. "must implement
fire suppression mechanism", "must avoid catching fire"), the
VCS entries in the software that implements them (e.g. "function
thermostat_control_loop() implements an algorithm to avoid excessive
heating"), and the test results that prove the software was implemented
correctly (e.g. "this is the callgrind output from a functional test case
in which the thermostat has failed, showing that the software detected
the condition successfully and actuated relays to disconnect power to
the heating elements").

Merely using a VCS is not sufficient.  Traceability requires identifying
individual persons responsible for determining requirements for the
code, establishing their competence to design and implement the code, and
demonstrating that the code implements the requirements correctly for each
product that uses the code.  Industrial regulations require traceability
to determine which individual personally made which implementation
decisions and which individual tested and verified the results.

Traceability is very expensive, in terms of both development cost and
liberty for the developers.  If you think of it as a map to know who to
sue when things go badly wrong, you're not entirely wrong.

Practically, if an embedded project requires traceability, it can
only import software that was developed with traceability, free or not;
otherwise, the project typically has to assume liability for the imported
software.

> * Reason #7 – Integration is never as easy as it seems

This is usually true in software projects, free or not.
Underestimation of integration costs is an endemic phenomenon.

Many of the other points are equally true for all software.  Only the
association of those points specifically and exclusively with free
software is incorrect.

> 
> Truthfully
> -- 
> Michael Pagan (pegzmasta)
> GPG Key ID: B942 AD12 82B1 6D14 27A0  86AE 119E 451E 71B4 6D72



> _______________________________________________
> libreplanet-discuss mailing list
> libreplanet-discuss@libreplanet.org
> https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss


_______________________________________________
libreplanet-discuss mailing list
libreplanet-discuss@libreplanet.org
https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss

  reply	other threads:[~2017-12-04  2:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-03  4:45 7 Reasons to Avoid Open Source? Mary-Anne Wolf
2017-12-03  8:05 ` Andrés Muñiz Piniella
2017-12-03 10:44 ` Thomas Harding
2017-12-03 12:32   ` N.Thomas
2017-12-03 15:29   ` C.W. Epema
2017-12-03 19:22 ` Michael Pagan
2017-12-04  2:12   ` Chad Larson [this message]
2017-12-04 14:51     ` Thomas Harding
2017-12-04 15:06     ` Caleb Herbert
2017-12-04 19:02       ` Chad Larson
2017-12-04 23:59         ` Thomas Harding
2017-12-04 16:20   ` Adonay Felipe Nogueira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/libreplanet-discuss

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171204021255.n5atlesyayeeeuyw@hungrycats.org \
    --to=bpyzs1fx@mailtoo.hungrycats.org \
    --cc=libreplanet-discuss@libreplanet.org \
    --cc=michael.pagan@member.fsf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).