[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[oniro-wg] Proposal: trustable software as core concept of Oniro's value proposition
|
Hello,
I mentioned a couple of weeks ago that I would send here a rationale for the
proposal I did last week to include Trustable (software) as one of the five
core concepts that characterise Oniro, following the proposal made by Davide
R. in this regard.
## Background
Some years ago, I could witness and even participate back then in an effort
that colleagues of mine, together with other experts, did to define a
nomenclature as initial step to establish a common language that could be
applied to resolve complex problems through system thinking related with
safety in software.
The motivation came from, among other reasons, the limited results that the
SWBOK in general, and the ISO26262 in particular, proposed, compared to the
real needs consumers/society have in this regard as well as the friction that
applying such safety/security standards creates with modern principles and
practices required in the production and maintenance of software solutions.
The results of this definition effort can be applied way beyond classical
safety critical software related environments. In our case, it is applicable
to our initial target industry (IoT and Edge).
## What is trustable software
This definition effort was condensed in the "Towards trustable software"
idea. Simplifying and summarising...
Trustable software is designed, developed, delivered, released and maintained
using trustable processes.
A trustable process can be defined as “auditable in such a way that, at
any point in the process, one can assess the degree to which it can be
trusted”[1]
The core principles of trustable are[2]:
"• We know where the code comes from
• Does the code do what it is supposed to do and does it not do what it is
not supposed to do?
• We know how the code was built and tested prior to deployment
• We can reproduce it exactly from source code
• We can update the code and be confident it will not break or regress"
In order to asses those principles, audit evidences on the processes are
required:
"• Evolution of problem/scope (requirements, standards and verification
criteria)
• Evolution of solution/architecture
• Selection/production of software (including tests)
• Evolution of tests, test results and satisfaction of validation criteria
• Traceability back through all previous phases
• Maintenance changes/upgrades are being applied to the whole pipeline, not
just code"
This definition was created back in 2017 and I am sure that it can be
revisited with the evolved knowledge in the field we have today but still
feels current enough to me.
The following characterization[3] of Trustable Software better resonates to
software developers:
"* Provenance (We know where it comes from)
* Construction (We know how to build it and we can reproduce it)
* Maintenance (We can update it and be confident that it will not break or
regress)
* Function (It does what it is supposed to do and it does not do what it is
not supposed to do)
* Protection (We have some confidence that it won't harm our communities and
our children)
## Oniro: towards trustable software
It should be unacceptable to any OS, but especially to new ones, to ignore or
even be lazy on any of the above concepts. Sadly, we are in a point in the
history of this engineering discipline when, instead of the norm, the
applicability of these evidence driven concepts and their auditability are the
exception instead of the norm.
Oniro has to be part of the solution towards trustable software.
From what I have seen so far, our engineering team is aware of this challenge
and are already promoting practices and applying measures to produce more
trustable software. We all understand it as a journey.
I would like to see Oniro though reinforcing the values implied as well as the
practices derived of the Trustable Software definition beyond our engineering
team effort, making "towards trustable software" part of Oniro's DNA.
I truly believe that, if we do make trustable software part of our DNA, just
like Open Source is, it will become a relevant differentiation factor for us
and an innovation factor as well. Many see this as a brake to innovation. Not
me.
## Proposal: trustable software as one of the five core concepts that
characterise Oniro
Based on the above, I suggest to include Trustable Software as one of the five
core concepts, in replacement of compliance, which is nothing but a subset of
this trustable concept when we understand compliance as "continuous
compliance".
Such inclusion would send a clear message that this project considers "the
how" we create our outputs relevant enough to turn it into a feature.
I want to work in a community with such "value". Who doesn't? In any case, at
some point, hopefully sooner than later, there will be no other option.
Let's lead.
[1] Trustable software, executive summary: https://www.trustablesoftware.com/
_files/ugd/154eeb_d1ab206e79d54d54b8f0c343146f904f.pdf?index=true
[2] Trustable software white paper: https://www.trustablesoftware.com/_files/
ugd/154eeb_ed44980b9ce64105adfa2314b2f6dc31.pdf?index=true
[3] https://gitlab.com/trustable/documents
Other links:
* Trustable goals: https://gitlab.com/trustable/documents/-/blob/master/
goals.md
* Article where the concept is applied: https://www.codethink.co.uk/articles/
2020/trusting-software-in-a-pandemic/
Best Regards
--
Agustin Benito Bethencourt
Oniro Program Manager | Eclipse Foundation
Eclipse Foundation: The Community for Open Innovation and Collaboration
