Why the world needs more standardization: Results of the systems.camp session on openness in SE

From this year's Systems Barcamp in Berlin I already reported last week. At the event, I moderated a session on the topic of "Openness in SE", the results of which I would like to present here.

Why openness?

I have come into contact with it in many places: I have actively participated in open ReqIF standard and contributed to its dissemination, among other things via the software I co-developed, the Eclipse Requirements Modeling Framework (RMF). I have done community building by supporting the very active rheinjug which serves the open exchange of knowledge. And I also share my knowledge through my various publications and lectures.

I have heard many stories about what happens when we are not open. Two major themes are Vendor lock-in and Isolated solutionsYou have to rely on the results of a single company for a solution. The obvious example is software on which you become dependent. However, this can be put into perspective if the formats of the software are open, i.e. the artifacts can be processed by other tools. If these are also proprietary, then you really are dependent.

Areas of application for openness

Together with the participants, we drew up a list of areas in which openness is used. This was important because we wanted to make it clear that it was not just about open source, but all aspects of openness. But we didn't find that many areas:

Openness in SE primarily occurs in four areas: Open source, standards, knowledge and architectures.

Open Source: This is what most people think of when they think of openness in systems engineering. It should be noted here that open is not the same as free. There is certainly commercial software that is available for a fee and comes with the source code.

Open standards: Standards can start at many points, from format (e.g. programming languages), procedure and much more. There are also gradations here, and some organizations do not make their standards available free of charge.

Open knowledge: This can take many forms, such as conferences, publications, etc. Here, attention should be paid to the licenses, such as the Creative Commons licenses.

Open architectures: Here in particular AUTOSAR (although AUTOSAR is not completely open either). Architectures enable collaboration and scalability at a different level of abstraction.

Added value of openness

The areas of application were now clear. Now came the most interesting question for me: Where is the greatest added value of openness seen? We first drew up a list of added values together. Each participant was then allowed to award two points.

With five votes Transparency by far the most votes. This also makes sense, as transparency is the basis for many of the other added values, such as security or long-term maintenance.

I know enough stories where dependence on one provider has caused problems. Independence - in the form of software and standards - can provide important protection here.

The topic Knowledge gain is rather marginal in the area of software, but significant in the other areas (standards, knowledge, architectures). In particular, knowledge is often reflected in standards and architectures, which can accelerate technical progress.

Long-term maintenance is one of the central themes of PolarSysand for this reason the Eclipse Foundation has developed its own LTS initiative. This group was aware of the issue, but not with the same urgency as PolarSys. The same applies to Securitywhich is often cited in public as a reason for open source.

Product focus was listed here as the opposite of revenue and profit focus. There was a bit of the idealism that is often found in the open source community. I don't find this added value all that convincing, because long-term success can (in my opinion) only be achieved if the customer has clear added value.

Other areas

The following collected topics only received one point:

Safety: We have combined this area with liability and risk. It was clear from the discussion that safety can also be managed well with non-open means.

Tool integration: The term hackability, i.e. the ability to create your own, was also mentioned here. This topic is very software-heavy. However, closed software can also make this possible, for example via scripting languages.

Control, distribution, marketing and innovation received no points at all.

And costs?

It may come as a surprise that low costs were not explicitly mentioned. However, the topic was addressed. There were no illusions that license costs are only part of the investment when it comes to software - total cost of ownership (TCO) was the key word here. This is not to say that costs cannot be reduced through open source - that is certainly possible. But that was not the expectation - at least not in this group.

Concrete ideas

My aim in the session was to identify specific drivers for openness. Of course, there is a selfish interest in identifying business areas based on this.

The participants expressed many wishes and frustrations. But in the end, almost all of the drivers mentioned can be reduced to one specific idea:

The most important driver for openness: standardization

Standardization means having a standard that is widely used and therefore accepted. This is the actual purpose of a standard, but unfortunately standardization itself is not a matter of course.

A number of measures have been identified to increase the degree of standardization:

There are drastic differences in the quality of standards, an experience I can share. The ReqIF standard, for example, is not only well written and structured, the underlying data model is even supplied with it.

One exciting suggestion was to combine standards with an open source reference implementation, which we did with the ReqIF standard using Eclipse RMF.

The desire was also expressed to use systematic social networking to ensure that the stakeholders of a standard would also learn about it.

Next steps

Although we now have a catalog of measures, it is still unclear how we will proceed. For me, this is confirmation that we have done a lot of things right at ReqIF and I will continue to drive these activities forward.

If you have any suggestions on how we can utilize these results, please leave a comment below to share them with us. to continue the discussion here in the forum.