7 Reasons to Avoid Open Source?

7 Reasons to Avoid Open Source?

[Mary-Anne Wolf]

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


You would not be surprised that the reasons generally do not impress me.  Somebody who can express it better than I do needs to respond.  Actually, a first person already has, but maybe more than one person should.


"Help!  Somebody on the internet is wrong!"  :-)


Mary-Anne

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

Re: 7 Reasons to Avoid Open Source?

[Andrés Muñiz Piniella]

El 3 de diciembre de 2017 04:45:12 GMT+00:00, Mary-Anne Wolf 
>Actually, a first person already has, but maybe more than one person
>should.
>
>

Actually I would say less is more. The answer is short and to the point, if I answer I would probably sound like a troll. Plus, it will give it more web traffic than it deserves.  I think. But thank you for sharing!

The absolute best solution would be to write another industry/trade article featuring a good quality faif project on the same magazine.  Addressing point by point the "issues" mentioned on this article but without mentioning it. The magazine does ask for content. 

I normally just read one or two comments anyway, if there is only one as reasonable and measured as this one, without a response from the original poster that speaks volumes to my ears.

Looking at the about page [1] it seems to me the problem is mainly with random scripts found on the internet focused on hobbies (e.g. arduino, python code on instructables or make: magazine). Professionals should exercise critical thinking when doing a cut and paste. Also, when professionals do use free (faif) software (not simply open source) AND free hardware,  the industry, in my humble opinion, is be better off. Because best practice could be imitated.

The authour also mentions throughout some good points. The title is missleading, I would say using the word 'plague' is a way to bait for a click. It certainly worked for me. In the past, faif licences have also been refered to viral. 


Thank you for your time!

[1] https://www.designnews.com/about

-- 
Richmond Makerlabs
Ham United Group

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

Re: 7 Reasons to Avoid Open Source?

[Thomas Harding]

Le 3 décembre 2017 05:45:12 GMT+01:00, Mary-Anne Wolf <mgwmgw@comcast.net> a écrit :
>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."
>
>
>You would not be surprised that the reasons generally do not impress
>me.  Somebody who can express it better than I do needs to respond. 
>Actually, a first person already has, but maybe more than one person
>should.
>
8 - The software is not mathematically proven.

9 - Software would likely never pass the tests in order to qualify as EAL 7+++, which is mandatory for a domestic grade standalone heating radiator thermostat (with display *and* clock!). Moreover youl'll had to afford the lab.

>"Help!  Somebody on the internet is wrong!"  :-)


-- 
Je suis née pour partager, non la haine, mais l'amour.
         Sophocle, Antigone, 442 av. J.C.

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

Re: 7 Reasons to Avoid Open Source?

[N.Thomas]

7 half baked fallacies to push some of @Jacob_Beningo's legacy ideas into the IoT market, break stuff and lock the market with abusive IP.

It's a paid hit piece. If this tactic weren't profitable, freedom haters wouldn't use it. Free software scares them. 
_______________________________________________
libreplanet-discuss mailing list
libreplanet-discuss@libreplanet.org
https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss

Re: 7 Reasons to Avoid Open Source?

[C.W. Epema]

I tried to post a comment, however a spam filter blocked my response.

My reaction was:

"
So, if Open Source or Free Software does not comply quality standards, according to your 'investigation', what will?
Closed Software?
Anyone is able to verify quality and integrity of Open/Free software. In contrast to closed software.
My suggestion is that you should take part in open projects, to suggest quality improvements, in stead of posting fake and possibly paid comments about one of the finest things humankind has come with: sharing knowledge
"

Regards,
Kees Epema


On Sun, 03 Dec 2017 11:44:43 +0100
Thomas Harding <tom@thomas-harding.name> wrote:

> Le 3 décembre 2017 05:45:12 GMT+01:00, Mary-Anne Wolf <mgwmgw@comcast.net> a écrit :
> >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."
> >
> >
> >You would not be surprised that the reasons generally do not impress
> >me.  Somebody who can express it better than I do needs to respond. 
> >Actually, a first person already has, but maybe more than one person
> >should.
> >
> 8 - The software is not mathematically proven.
> 
> 9 - Software would likely never pass the tests in order to qualify as EAL 7+++, which is mandatory for a domestic grade standalone heating radiator thermostat (with display *and* clock!). Moreover youl'll had to afford the lab.
> 
> >"Help!  Somebody on the internet is wrong!"  :-)
> 
> 
> -- 
> Je suis née pour partager, non la haine, mais l'amour.
>          Sophocle, Antigone, 442 av. J.C.
> 
> _______________________________________________
> libreplanet-discuss mailing list
> libreplanet-discuss@libreplanet.org
> https://lists.libreplanet.org/mailman/listinfo/libreplanet-discuss

-- 
Groet,

Kees Epema
Rosa Spierweg 20
9408EV Assen
T: 06 100 66 878
M: keesepema@linuxmail.org

Protect your privacy and encrypt your messages. 
Add my key to your keyring:
PGP key: http://osmigratie.nl/keesepema.asc

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

Re: 7 Reasons to Avoid Open Source?

[Michael Pagan]

[-- Attachment #1.1: Type: text/plain, Size: 9586 bytes --]

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."
>
>
> You would not be surprised that the reasons generally do not impress
> me.  Somebody who can express it better than I do needs to
> respond. <SNIP>

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

[0]: https://en.wikipedia.org/wiki/Version_control_system

Direct quote about a VCS from Wikipedia:

    Revision control allows for the ability to revert a document to a
    previous revision, which is critical for allowing editors to *track*
    each other's edits, correct mistakes, and defend against vandalism
    and spamming.

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!

* Reason #2 – Designed for functionality[,] not robustness

This is a half-truth (lie) based on assumptions, and the author does not
provide any real-world examples––although he likes to say "real-world"––
that prove his point.  Phrases like /is often written functionally/;
/generally not robust/; /expects that a wrench will never be thrown/;
/rarely the case/; and /can find/ (not *will* find), only prove that
this author is assuming that free software is not designed for
robustness.  There are thousands of free software projects online, and
he assumes that they are not robust; otherwise, he should have said that
*some* free software is not robust–– this would've been more believable.

The last sentence of his second reason (direct quote) is true for all
software projects, and not just free software.  He does not say this, of
course, and by omitting this truth–– he lies:

    Developers will find themselves having to dig through unknown
    terrain trying to figure out how best to improve or handle errors
    that weren’t expected by the original developers.

_Reason #2_ is a lie!

* Reason #3 – Accidentally exposing confidential intellectual property

The term [intellectual property][1] is a misleading term designed to
cause confusion.  Anyone who uses a free software license uses it for
the explicit reason to publish/expose their software/information.  Free
Software licenses require users to share software/knowledge, hence it is
not accidental–– it is *deliberate* (free licenses make this obvious).

[1]: http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty

Richard Stallman has written extensively about this [confusing term][1],
and you can read those essays via this link (4 essays as of now):

https://www.gnu.org/cgi-bin/estseek.cgi?phrase=intellectual+property+%21+diff&attr0=%40title+ISTRINC+Intellectual+Property&attr1=&attr2=&order=&perpage=10&clip=9&navi=1

_Reason #3_ is a lie!

* Reason #4 – Lacking automated or manual tests

Notice how he did not say "Completely Lacking."  Notice also how he has
looked at Python projects, but has not mentioned whether he has looked
at other types of projects.  Once again, no specific examples of which
tests the free software community is actually missing.  No references to
mailing lists or forums where he has asked for such tests have been
identified.  How can anyone agree with such a statement without proof?

More assumptions and no evidence... _Reason #4_ is *evidently* a lie!

* Reason #5 – Poor documentation or documentation that is lacking
  completely (he said "completely"–– I WILL debunk this)

Has this author ever heard of a [man page][2] (not related to men, `man'
is short for *manual*) before?  How about the [info reader][3]?

[2]: https://en.wikipedia.org/wiki/Man_page
[3]: https://en.wikipedia.org/wiki/Info_%28Unix%29

One of the *main* reasons to use free software is *because* it is so
well documented.  I have yet to find any software in my GNU/Linux distro
that does not come with documentation.  Richard Stallman once complained
about [a lack of free documentation for free software][4]... this was
about _[10 years ago][5]_ and is no longer true!

[4]: https://www.gnu.org/philosophy/free-doc.html
[5]: https://web.archive.org/web/19990224050619/https://www.gnu.org/philosophy/free-doc.html

Now for my strongest point!  Even if free software has no manuals which
document it's use, and not even a command-line "help" option, I dare
say: You can *still* learn how the software works, even without these!

Some of you must be wondering how?  _Here's how:_ It's free software,
and you can access the source code!  Has Jacob Beningo never heard of a
[source code comment][6] before?  Yes, it is possible to learn how
software works––with or without source code comments–– and you can even
generate documentation from said comments.  This type of documentation,
by the way, can ONLY be accessed from free software!

[6]: https://en.wikipedia.org/wiki/Comment_(computer_programming)

Not only is this the norm for free software, but for all GNU
programs... it is [standard][7].

[7]: https://www.gnu.org/prep/standards/html_node/Comments.html

_Reason #5_ is a lie!

* Reason #6 – Real-time support is lacking

No proof is provided here.  No mailing lists have been identified where
he has *personally* asked for support and received none.  No references
are made to any forums, IRC channels, or even wiki pages, where he has
posted or published a request for support.  Every (and I mean *every*)
time I have asked for support for free software that is still actively
maintained (some free software is [abandonware][8]), I always got it.

[8]: https://en.wikipedia.org/wiki/Abandonware

Anyone ever heard of the phrase: "The proof of the pudding is in the
eating!"  A similar phrase can be said: "The proof of a lack of support
is in the requesting of said support."  No requests; no support–– common
sense, folks.  He has omitted requests for support that he "supposedly"
made, hence _Reason #6_ is also a lie (omission of requests)!

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

Perhaps the author (with his constant assumptions) once again assumed
that integration would be easy, but did not do his research about the
process ahead of time.  With a [catalog][9] of so many free software
programs to solve any given task, I usually do my research ahead of time
to determine which free program would be best to use to solve my
problems.  Perhaps the author went with the first free program he found
and just used it without research, and without looking at other free
alternatives.

[9]: https://directory.fsf.org/wiki/Main_Page

Once again, we won't know for sure until he explains.  But can we expect
an assumer who commonly omits information to tell the truth?

In case it isn't obvious by now... _Reason #7_ is a lie!

* (Jacob Beningo's) Conclusions

    By no means am I against open source software. It’s been extremely
    helpful and beneficial in certain circumstances. It’s important
    though not to just use software because it’s free and open
    source. Developers need to recognize their requirements, needs, and
    the robustness level that they require for their product and
    appropriately develop or source software that meets those needs
    rather than blindly selecting software because it’s “free.”

** My conclusions

His (Jacob Beningo's) conclusions reveal him as a hypocrite.  He says he
is not /against open source software/ or free as in freedom (faif)
software, but then states: "It’s important though not to just use
software because it’s free."  I––for one–– ONLY use software *when* it
is free.  He also states that "Developers need to recognize
<SNIP>... rather than blindly selecting software because it’s “free.”
Apparently, I––as well as millions of others–– am/are blind and do NOT
recognize.

What is this guy all about, anyway?  Let's take a direct excerpt from
his article that describes him:

    Jacob Beningo is an embedded software consultant who currently works
    with clients in more than a dozen countries to dramatically
    transform their businesses by improving product quality, cost and
    time to market.

This man is focused on improving product quality, cost and time to
market–– he did not list *freedom* as a priority.  This description of
himself already tells us where his loyalty lies–– NOT with the
community, but rather for businesses (proprietary–– very scary).

Are you blind for choosing [software freedom][7]?  Does anyone agree or
disagree with his nonsense?  I certainly do NOT agree!

[7]: https://copyleft.org/guide/comprehensive-gpl-guidech2.html


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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

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

Re: 7 Reasons to Avoid Open Source?

[Chad Larson]

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

Re: 7 Reasons to Avoid Open Source?

[Thomas Harding]

Le 4 décembre 2017 03:12:55 GMT+01:00, Chad Larson <BPYZs1fx@mailtoo.hungrycats.org> a écrit :
[...]
>> * Reason #1 – Lacks a traceable software development life cycle
>>

>In embedded project context, "traceability" refers to a matrix
>of requirements on the integrated product (e.g. "must implement
[...]
>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.
>
[...]
>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.

So, actually software is not used in that context as a software but as an industral product you can buy with warranty, and possibly discard your own responsabilty on (using) it regardless it's cost (then sue the furbisher).

Moreover, QA would not be done internally on "parts".

That makes sense on a manufacturing process, where you produce hundreds eachs then make destructive tests on some and warranty with fee in each part.

That's not the same on software, and that's why a fully tested " embedded software" can fail : just look at Ariane IV / Ariane V failure where a reused piece of code was untested on the last " because of QA ".

"There is no warranty" from upstream is the safest approach. While more expensive (...)



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



-- 
Je suis née pour partager, non la haine, mais l'amour.
         Sophocle, Antigone, 442 av. J.C.

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

Re: 7 Reasons to Avoid Open Source?

[Caleb Herbert]

[-- Attachment #1.1: Type: text/plain, Size: 1130 bytes --]

On Sun, 2017-12-03 at 21:12 -0500, Chad Larson wrote:
> 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.

Sounds like they want better documentation.  Ask Red Hat.

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

Sounds like they want the benefits of a warranty.  Ask Red Hat.

Reminder: Department of Defense will use software without a warranty IF
and ONLY IF it is free.  Is some company more important than the DoD?

-- 
Caleb Herbert
OpenPGP public key: http://bluehome.net/csh/pubkey

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 183 bytes --]

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

Re: 7 Reasons to Avoid Open Source?

[Adonay Felipe Nogueira]

If the original misinformation article website weren't forcing non-free
client-side software through JS I would vote for mentioning Michael
Pagan's reply there.

Also, I have some points to add to Michael Pagan's reply:

I agree with the bias of "intellectual property", also see the comments
I made on [1].

On the interoperability issues, see [2]. As for the costs, the author of
the article missed it entirely.

Financially speaking, while the acquisition cost of free/libre software
*can be* almost zero or completely so (we can also hook "open source"
here, no matter if it follows the free/libre software *philosophy* or
not), the fact is that they both have maintainance, customization and
training costs just as equal as the counterparts (although people
strangely perceive these differently as having less
transition/maintainance cost, which as far as I can see is caused by
their "path dependency" on the latter).

In the end of the day, however, between "open source" projects and
free/libre software projects (and now I'm refering only to those which
follow the free/libre software *philosophy*, and so disregarding the
"open source" ones), only the free/libre seem to be able to provide
results which are in conformity with their primary goal.

In other words, by making an overview of open source projects --- that
is: which have the primary goal of following the open source development
methodoly and (I assume) do so following the Open Source Initiative's
definition of "open source", which promises quality, reliability and
flexibilty --- with their results and how many times they fulfilled
their promise (of quality, reliability and flexibilty); and by making
the same comparison between free/libre software projects and how many
times they fulfilled the promise of providing a
free/libre-software-*philosophy*-compliant result --- no matter if there
were "quality", reliability and flexibility bugs/issues, because the
main gola/promise was never to have none ---, one can see that the
latter has the primary goal/promise carefully set to something which can
be attested with more ease.

So for the latter case, the "quality" in conformity with primary
goal/promise is accomplished. For a similar argumentation see [3].

As for documentation, +1 for mentioning the importance of GNU
Info/Texinfo pages. ;)

Also, I'm not a developer, but I noticed that at least GNU Guile Scheme
and Emacs Lisp allow "in-declaration (docstring)" documentation that
would enable someone to use a software to display those, similarly to
what is done inside Emacs when someone does M-x describe-function RET or
the same for variables but replacing "function" accordingly. As a plus,
discarding the quantity of parenthesis, at least for me GNU Guile Scheme
and Emacs Lisp are more senile in regards to how to quote or postpone
evaluation of things, besides suffering less from loops. There are other
advantages but I'll limit myself for now. ;)

[1] <https://listas.trisquel.info/pipermail/trisquel-users/2017-November/083315.html>.

[2] <https://lists.fsfe.org/pipermail/discussion/2017-November/012087.html>.

[3] <https://media.libreplanet.org/u/libby/m/mako/>.

2017-12-03T14:22:08-0500 Michael Pagan wrote:
> _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.
>
> [0]: https://en.wikipedia.org/wiki/Version_control_system
>
> Direct quote about a VCS from Wikipedia:
>
>     Revision control allows for the ability to revert a document to a
>     previous revision, which is critical for allowing editors to *track*
>     each other's edits, correct mistakes, and defend against vandalism
>     and spamming.
>
> 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!
>
> * Reason #2 – Designed for functionality[,] not robustness
>
> This is a half-truth (lie) based on assumptions, and the author does not
> provide any real-world examples––although he likes to say "real-world"––
> that prove his point.  Phrases like /is often written functionally/;
> /generally not robust/; /expects that a wrench will never be thrown/;
> /rarely the case/; and /can find/ (not *will* find), only prove that
> this author is assuming that free software is not designed for
> robustness.  There are thousands of free software projects online, and
> he assumes that they are not robust; otherwise, he should have said that
> *some* free software is not robust–– this would've been more believable.
>
> The last sentence of his second reason (direct quote) is true for all
> software projects, and not just free software.  He does not say this, of
> course, and by omitting this truth–– he lies:
>
>     Developers will find themselves having to dig through unknown
>     terrain trying to figure out how best to improve or handle errors
>     that weren’t expected by the original developers.
>
> _Reason #2_ is a lie!
>
> * Reason #3 – Accidentally exposing confidential intellectual property
>
> The term [intellectual property][1] is a misleading term designed to
> cause confusion.  Anyone who uses a free software license uses it for
> the explicit reason to publish/expose their software/information.  Free
> Software licenses require users to share software/knowledge, hence it is
> not accidental–– it is *deliberate* (free licenses make this obvious).
>
> [1]: http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty
>
> Richard Stallman has written extensively about this [confusing term][1],
> and you can read those essays via this link (4 essays as of now):
>
> https://www.gnu.org/cgi-bin/estseek.cgi?phrase=intellectual+property+%21+diff&attr0=%40title+ISTRINC+Intellectual+Property&attr1=&attr2=&order=&perpage=10&clip=9&navi=1
>
> _Reason #3_ is a lie!
>
> * Reason #4 – Lacking automated or manual tests
>
> Notice how he did not say "Completely Lacking."  Notice also how he has
> looked at Python projects, but has not mentioned whether he has looked
> at other types of projects.  Once again, no specific examples of which
> tests the free software community is actually missing.  No references to
> mailing lists or forums where he has asked for such tests have been
> identified.  How can anyone agree with such a statement without proof?
>
> More assumptions and no evidence... _Reason #4_ is *evidently* a lie!
>
> * Reason #5 – Poor documentation or documentation that is lacking
>   completely (he said "completely"–– I WILL debunk this)
>
> Has this author ever heard of a [man page][2] (not related to men, `man'
> is short for *manual*) before?  How about the [info reader][3]?
>
> [2]: https://en.wikipedia.org/wiki/Man_page
> [3]: https://en.wikipedia.org/wiki/Info_%28Unix%29
>
> One of the *main* reasons to use free software is *because* it is so
> well documented.  I have yet to find any software in my GNU/Linux distro
> that does not come with documentation.  Richard Stallman once complained
> about [a lack of free documentation for free software][4]... this was
> about _[10 years ago][5]_ and is no longer true!
>
> [4]: https://www.gnu.org/philosophy/free-doc.html
> [5]: https://web.archive.org/web/19990224050619/https://www.gnu.org/philosophy/free-doc.html
>
> Now for my strongest point!  Even if free software has no manuals which
> document it's use, and not even a command-line "help" option, I dare
> say: You can *still* learn how the software works, even without these!
>
> Some of you must be wondering how?  _Here's how:_ It's free software,
> and you can access the source code!  Has Jacob Beningo never heard of a
> [source code comment][6] before?  Yes, it is possible to learn how
> software works––with or without source code comments–– and you can even
> generate documentation from said comments.  This type of documentation,
> by the way, can ONLY be accessed from free software!
>
> [6]: https://en.wikipedia.org/wiki/Comment_(computer_programming)
>
> Not only is this the norm for free software, but for all GNU
> programs... it is [standard][7].
>
> [7]: https://www.gnu.org/prep/standards/html_node/Comments.html
>
> _Reason #5_ is a lie!
>
> * Reason #6 – Real-time support is lacking
>
> No proof is provided here.  No mailing lists have been identified where
> he has *personally* asked for support and received none.  No references
> are made to any forums, IRC channels, or even wiki pages, where he has
> posted or published a request for support.  Every (and I mean *every*)
> time I have asked for support for free software that is still actively
> maintained (some free software is [abandonware][8]), I always got it.
>
> [8]: https://en.wikipedia.org/wiki/Abandonware
>
> Anyone ever heard of the phrase: "The proof of the pudding is in the
> eating!"  A similar phrase can be said: "The proof of a lack of support
> is in the requesting of said support."  No requests; no support–– common
> sense, folks.  He has omitted requests for support that he "supposedly"
> made, hence _Reason #6_ is also a lie (omission of requests)!
>
> * Reason #7 – Integration is never as easy as it seems
>
> Perhaps the author (with his constant assumptions) once again assumed
> that integration would be easy, but did not do his research about the
> process ahead of time.  With a [catalog][9] of so many free software
> programs to solve any given task, I usually do my research ahead of time
> to determine which free program would be best to use to solve my
> problems.  Perhaps the author went with the first free program he found
> and just used it without research, and without looking at other free
> alternatives.
>
> [9]: https://directory.fsf.org/wiki/Main_Page
>
> Once again, we won't know for sure until he explains.  But can we expect
> an assumer who commonly omits information to tell the truth?
>
> In case it isn't obvious by now... _Reason #7_ is a lie!
>
> * (Jacob Beningo's) Conclusions
>
>     By no means am I against open source software. It’s been extremely
>     helpful and beneficial in certain circumstances. It’s important
>     though not to just use software because it’s free and open
>     source. Developers need to recognize their requirements, needs, and
>     the robustness level that they require for their product and
>     appropriately develop or source software that meets those needs
>     rather than blindly selecting software because it’s “free.”
>
> ** My conclusions
>
> His (Jacob Beningo's) conclusions reveal him as a hypocrite.  He says he
> is not /against open source software/ or free as in freedom (faif)
> software, but then states: "It’s important though not to just use
> software because it’s free."  I––for one–– ONLY use software *when* it
> is free.  He also states that "Developers need to recognize
> <SNIP>... rather than blindly selecting software because it’s “free.”
> Apparently, I––as well as millions of others–– am/are blind and do NOT
> recognize.
>
> What is this guy all about, anyway?  Let's take a direct excerpt from
> his article that describes him:
>
>     Jacob Beningo is an embedded software consultant who currently works
>     with clients in more than a dozen countries to dramatically
>     transform their businesses by improving product quality, cost and
>     time to market.
>
> This man is focused on improving product quality, cost and time to
> market–– he did not list *freedom* as a priority.  This description of
> himself already tells us where his loyalty lies–– NOT with the
> community, but rather for businesses (proprietary–– very scary).
>
> Are you blind for choosing [software freedom][7]?  Does anyone agree or
> disagree with his nonsense?  I certainly do NOT agree!
>
> [7]: https://copyleft.org/guide/comprehensive-gpl-guidech2.html
>
>
> Truthfully

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
  instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

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

Re: 7 Reasons to Avoid Open Source?

[Chad Larson]

On Mon, Dec 04, 2017 at 09:06:10AM -0600, Caleb Herbert wrote:
> On Sun, 2017-12-03 at 21:12 -0500, Chad Larson wrote:
> > 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.
> 
> Sounds like they want better documentation.  Ask Red Hat.

That seems like an odd request, given that Red Hat's history of certified
products is limited to enterprise software running on x86_64 hosts,
not embedded systems.  Red Hat has some products rated at EAL4, but the
traceability requirements for EAL4 are fairly weak compared to other
industry standards (or even EAL6).  The other certifications they have
seem to have even weaker requirements (but I haven't fully reviewed
them all).

I don't know of any free-software projects currently offering a complete
traceability data set.  I know of only two open-source projects (FreeRTOS
and OpenSafety) which offer traceability data at all--but in both cases
the data is only available under a separate non-free license.

> > 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.
> 
> Sounds like they want the benefits of a warranty.  Ask Red Hat.

A warranty is necessary but not sufficient.  If a project is demanding
traceability, they expect more from their suppliers than a mere offer
to refund the purchase price.

> Reminder: Department of Defense will use software without a warranty IF
> and ONLY IF it is free.  Is some company more important than the DoD?

The DoD routinely pays egregious development and support costs that the
private sector will not.  Does some company have deeper pockets than
the DoD?

> -- 
> Caleb Herbert
> OpenPGP public key: http://bluehome.net/csh/pubkey



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

Re: 7 Reasons to Avoid Open Source?

[Thomas Harding]

Le 4 décembre 2017 20:02:41 GMT+01:00, Chad Larson <BPYZs1fx@mailtoo.hungrycats.org> a écrit :
>On Mon, Dec 04, 2017 at 09:06:10AM -0600, Caleb Herbert wrote:
>> On Sun, 2017-12-03 at 21:12 -0500, Chad Larson wrote:
[...]
>> > 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.
>> 
>> Sounds like they want better documentation.  Ask Red Hat.
>
>That seems like an odd request, given that Red Hat's history of
>certified
>products is limited to enterprise software running on x86_64 hosts,
>not embedded systems.  Red Hat has some products rated at EAL4, but the
>traceability requirements for EAL4 are fairly weak compared to other
>industry standards (or even EAL6).  The other certifications they have
>seem to have even weaker requirements (but I haven't fully reviewed
>them all).

Common Criteria EAL evalation is out of vendors scope, especially regarding operating systems :

EAL evaluation is conduced through a defined environment on a specific usage where a defined and reproductible setup has been done on the tested system.

Moreover, enlisted laboratories are so rare and expensive that a vendor will never afford.

If I remain correctly, tests/certification processes were afforded on some RedHat and SUSE setups by German defence.

In any way: asking for vendor to afford for CC / EAL testing and certification does not make sense.

(While traceability and automated tests would help, and CC requirements to EALn includes controlled development process -- from start -- as claimed earlier in thread)

>I  know of any free-software projects currently offering a
>complete
>traceability data set.  I know of only two open-source projects
>(FreeRTOS
>and OpenSafety) which offer traceability data at all--but in both cases
>the data is only available under a separate non-free license.


>
>A warranty is necessary but not sufficient.  If a project is demanding
>traceability, they expect more from their ll 


-- 
Je suis née pour partager, non la haine, mais l'amour.
         Sophocle, Antigone, 442 av. J.C.

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