Stories
Slash Boxes
Comments

SoylentNews is people

Politics
posted by martyb on Tuesday March 10 2020, @11:51PM   Printer-friendly
from the quite-the-coc-up dept.

Open Source Initiative bans co-founder, Eric S Raymond:

Last week, Eric S Raymond (often known as ESR, author of The Cathedral and the Bazaar, and co-founder of the Open Source Intiative) was banned from the Open Source Intiative[sic] (the "OSI").

Specifically, Raymond was banned from the mailing lists used to organize and communicate with the OSI.

For an organization to ban their founder from communicating with the group (such as via a mailing list) is a noteworthy move.

At a time when we have seen other founders (of multiple Free and Open Source related initiatives) pushed out of the organizations they founded (such as with Richard Stallman being compelled to resign from the Free Software Foundation, or the attempts to remove Linus Torvalds from the Linux Kernel – both of which happened within the last year) it seems worth taking a deeper look at what, specifically, is happening with the Open Source Initiative.

I don't wish to tell any of you what you should think about this significant move. As such I will simply provide as much of the relevant information as I can, show the timeline of events, and reach out to all involved parties for their points of view and comments.

The author provides links to — and quotations from — entries on the mailing list supporting this. There is also a conversation the author had with ESR. The full responses he received to his queries are posted, as well.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by barbara hudson on Sunday March 15 2020, @04:49PM (1 child)

    by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Sunday March 15 2020, @04:49PM (#971610) Journal

    You're building flight-critical software and you notice that there's only ONE sensor and it doesn't raise alarms? What's your failure mode? What if the sensor ices up or is defective? Or a bird strike takes it out?

    Even cars have multiple headlights and taillights. Redundancy. Dual hydraulic braking circuits. Brakes on every wheel.

    Heck, even humans have guilt-in redundant sensors. Two eyes, two ears. Even the brain is divided into two hemispheres, and the failure of part of one can sometimes be compensated for by the other (especially if you're left-handed or ambidextrous).

    --
    SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by Grishnakh on Tuesday March 17 2020, @01:41AM

    by Grishnakh (2831) on Tuesday March 17 2020, @01:41AM (#972072)

    You're building flight-critical software and you notice that there's only ONE sensor and it doesn't raise alarms? What's your failure mode? What if the sensor ices up or is defective? Or a bird strike takes it out?

    You obviously haven't worked on flight-critical software. It doesn't work that way.

    First off, the original story was that the MCAS was not really flight-critical, and would only make very small adjustments within a small range, and that justified the single sensor.

    But more importantly, software like this is requirements-based. The requirements are written by systems engineers, and then translated into DOORS. This auto-generates a lot of the code, which is then filled in by software engineers to satisfy the requirements. It's totally a waterfall process. If the code doesn't satisfy the requirements, it fails; it doesn't matter if the requirements are wrong. The things you're asking ("what if...") are questions for the systems engineers, not the software engineers.

    Yes, you're right about redundancy of course, but again this isn't the job of a software engineer in aerospace, that's the job of the systems engineer. Those are the people who really failed, and they did so most likely because they were required to make the requirements this way by managers (under direction of executives) who wanted to avoid the 737MAX having a different type certification.