=Paper=
{{Paper
|id=None
|storemode=property
|title=Clopenness of Systems: The Interwoven Nature of Ecosystems
|pdfUrl=https://ceur-ws.org/Vol-746/IWSECO2011-5-MolderLierJansen.pdf
|volume=Vol-746
|dblpUrl=https://dblp.org/rec/conf/icsob/MolderLJ11
}}
==Clopenness of Systems: The Interwoven Nature of Ecosystems==
https://ceur-ws.org/Vol-746/IWSECO2011-5-MolderLierJansen.pdf
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
Clopenness of Systems: The Interwoven Nature of
Ecosystems
Joost te Molder, Ben van Lier, Slinger Jansen
Utrecht University, The Netherlands, joosttemolder@gmail.com, s.jansen@cs.uu.nl
Centric, Gouda, The Netherlands, ben.van.lier@centric.eu
Abstract. Openness of a software product or software producing and end-user
organization is perceived as a binary concept: organizations are perceived to be
closed, with its negative connotations, such as being dictatorial, undemocratic,
and opaque, whereas an open organization is positively considered to be
transparent and favorable to deal with. The binary view of openness, however,
is harmful for the software industry, since wrong decisions are made on these
qualifications, calling for a better definition of the concepts of openness and
closeness. In this paper a definition is given of the concepts, which led to the
concept clopenness; a model is provided that assesses the clopenness of a
software producing or end-user organization and its software products, and a
case study is performed to show the use of the model and concepts. The results
of the paper are that the use of the clopenness model provides insight into the
openness of an organization, in turn enabling better founded business decisions.
Keywords: openness, closeness, organizational clopenness, software
clopenness, clopenness assessment
1. Introduction
Openness is perceived as a binary concept; „open‟ or „closed‟. Open and closed
are two states that are used by software vendors to label their software and
corresponding organization. In addition, organizational and software openness and
closeness have become popular buzzwords that attract the interest of various
organizations and their customers. Typically, organizations make rhetoric use of the
adjective open, use it as a marketing pitch to describe their organization, and attribute
positive effects to this openness. One question that needs to be asked, however, is
whether they are „truly‟ open or closed? Open and closed are opposites, but we argue
that these are more than simple opposites. To date there has been little agreement on
what open exactly is, and what is meant by closed [12]. Consequently, how is
openness or closeness perceived [11]? The debate between open and closed is
challenging, vague and broad, covering different perspectives and viewpoints [4],
[21], [23], [29], [8]. All actors, e.g. organizations, developers, end-users, competitors
and other third parties, have their own opinions, beliefs and intentions in their
particular realities, that tend to have philosophical intentioned descriptions and
52
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
meanings. These interpretations have shifted over time, hence we recognize a new
perspective on the open vs. closed discussion. The paper is divided in five parts. The
first section deals with the research approach, design, and related methods. The
second section gives a brief overview of the origins and status quo of the concepts
open and closed, attempts to show shortcomings and ideas of these concepts and
outlines the theoretical concepts of the research. The third section describes how the
concepts are combined and structured into a model, the subsection elaborates on
evaluation of the model. The next section shows the use of the model and concepts in
case studies. The paper ends with the conclusion, discussion and directives for further
research.
2. Research Approach
Different methods were used in this study; the general method structuring this
research can be characterized as design science research [24]. With a literature study
the status quo of the phenomena open and closed (systems) in different scientific
fields were studied. Based on the literature study we discuss the status quo and aim at
revealing shortcomings and ideas in the field to construct a new perspective or
artifact. Complementary, viewpoints are created on the found shortcomings and ideas,
resulting in the development of a new perspective on the subject matter. A multiple
case study design, as described by Yin [33], was chosen to allow more analytic
benefits for this research than a single-case design, because of the complexity of the
phenomena. A preliminary pilot case study and a few meetings preceded the
agreement over the case study protocol. By means of four case studies existing of
semi-structured interviews with experienced information technology managers, we
evaluated the phenomena in a real-life context, i.e. in systems in the transport and
logistics ecosystem. The results were drawn by using an interpretive study approach
[20] on the collected data, and the use of various analytic techniques such as
replication logic, explanation building and cross-case synthesis [33].
3. Open and Closed Systems
Open and closed systems originate from the 1950s in physical sciences, or to be
more specific; from thermodynamics. In thermodynamics, an open system is a system
that exchanges heat and work with their environment [27], this is in contrast with a
closed or isolated system, which exchanges neither heat nor work with their
environment. In life sciences and biology, living systems are defined as open systems,
“maintaining themselves in exchange of materials with environment, and in
continuous building up and breaking down of their components” [27]. The term open
system was further developed in systems theory. Bertalanffy observes that “we call a
system closed if no materials enter or leave it. It is open if there is inflow and outflow,
and therefore change of the component materials” [26]. In general systems theory,
Boulding [5] emphasized that organizations are open systems, or self-maintaining
structures. We note that technology played no role yet in Boulding‟s general systems
53
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
theory. An open system is an organization that is capable of self-maintenance by
throughput of environmental influences [5]. On the other hand, a closed system is one
that assumes that the organization is only affected by internal influences.
Environmental influences can be participants or individual firms and/or products that
mutually depend on each other. An open system as opposed by Boulding is essentially
closed in itself; this is expressed by the theorem „openness based on closeness‟ [2].
For example, a human can be closed in the sense that thoughts are protected by a
skull, but we are still open in the sense that we can communicate these thoughts with
each other. Derivatives of open and closed systems are also found in economics [32],
politics [17] and management science [7]. For example, the regime of Obama is
characterized as open, while we recognize the contrary in the regime of Mubarak or
Kim Jong-Il. These systems are based on the fundamental principles of Boulding or
von Bertalanffy, which are previously described.
3.1 Theoretical Concepts
So far, open and closed systems have been viewed as opposites. We argue that they
are more than simple opposites. Maxwell [16] suggests that something is not simply
open or closed; it ranges from open to closed and encompasses varying degrees of
openness. There is a continuum in between open and closed. A continuum has two
endpoints or extremes, open and closed. Something can be placed anywhere in
between those two points, but can never be the endpoint itself. Completely open or
closed systems do not exist. Therefore, we consider the open versus closed discussion
as a false dichotomy. A false dichotomy appears in a situation where only two options
are discussed, in this case open and closed, when in fact there are more options.
Crucial decisions with great impact are taken, with a naïve and myopic view of the
concepts. The naïve and myopic view is also emphasized by West [28], when he tries
to make sense of open standards. Standards are often characterized as either open or
proprietary, two options, while there are black, white, and many shades of gray. To
determine how open or closed something is, we suggest attaching a degree of
openness or closeness to organizations or software. We do not want the impression
that we lean toward open by using openness, or tend toward closed by using
closeness. Therefore, we will use the term „clopenness‟, that refers to both openness
and closeness, which respectively are build upon open and closed. It also addresses
the theorem of openness based on closeness and thereby „solves‟ the false dichotomy.
Complementary, we can say that the discussion should never be about open versus
closed, but about the degree of clopenness. In mathematics, a clopen set is a subset of
a topological space; both open and closed, the topological space is finite dimensional,
a point on this space is determined by postulates of some kind [10]. Although the
function in mathematics is different than the context of this article, we can
semantically deduce that the topological space refers to a continuum. The degree on
the continuum can be placed anywhere in between open and closed.
Clopenness suggests that systems are always both open and closed, in which the
system as a whole determines how the parts behave; the connections between the
parts enable systems to „communicate‟ with their environment [25]. The whole exists
of parts such as software, a device, network and the environment. Parts can be
54
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
systems themselves but are also composed of other parts. Clopenness can refer to
„clopenness in parts‟ i.e. how the parts behave, and „clopenness of parts‟ i.e. the
connections between parts that compose the whole.
Open systems are popularized by the open-source community, but this can be
misleading. The characterization source in „open-source‟ says it all; it is only about
the source code in this case, not about other organizational processes or software
parts. Open standards, open formats and open source are often considered equivalent
or mutually implicated [6]. In addition, software products characterized as closed
source can have open components and vice versa. We can ask ourselves the
following: is the Android OS open because the source code is available and allows
modification? Is Microsoft Windows closed because the source code is not available?
Source code is just a part of the whole, all that can be said about this is that the degree
of source code clopenness differs between these two operating systems. We describe
opening up of a specific part or resource of the organization, e.g. a certain process or
intellectual property, or a part of the software, e.g. APIs or source code. This results
in clopenness of a resource itself within software clopenness or organizational
clopenness. We refer to these resources or parts as organizational and software
clopenness options. A certain distinction is recognized, there are two types of
clopenness: of/in an organization and of/in software. The organization is the whole
that developed or uses (end-users) the software product. This can be a business unit, a
group of people who work together, groups who work together, the whole
organization, a consortium, or any other form of organizations, as long as the whole is
focused on the development or the use of a specific software product. The
organization also includes the organizational core components of governance,
research and development, software product management, marketing and sales, and
consulting and support services [22]. The software product is defined as “a packaged
configuration of software components or a software-based service, with auxiliary
materials, which is released for and traded in a specific market” [31].
The degree of clopenness, and so a point on the continuum, is determined by how
an option approaches the clopenness key attributes. These can be found in Table 1.
Table 1. Descriptions of clopenness key attributes
Key attribute Description
Availability The degree to which an option is available internal as well as external when
it is required for use or reference [16][11][7].
Accessibility Is accessible, can be consulted by as many interested people as possible,
regardless their status towards the company or the field of endeavor they
are in. Can be limited based on registration, subscription, religion, sexes,
political persuasion or intellectual goal [16][30][11][7].
Transparency Is transparent, in terms of no filtered or prohibited content regarding the
accessibility mode. Clearly defined, understandable, comprehensible and
unambiguous documentation guided by established well known common
rules, policies and processes. If applicable, according to standards approved
by recognized standard-setting organizations [30][7][15]. Including insights
in stakeholders‟ experiences and decision making processes based on a
plausible frequency of information disclosure. May be limited based on
encryption or other protection.
55
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
Reciprocity Is able to be modified or updated in a reciprocal manner, i.e. enabled for
interaction with the environment [16][7] based on policies about how to
handle with the different stakeholders or other third parties. Not limited by
technical or functional shortcomings, such as the lack of tools and features
to communicate and share experiences.
Licensing Is being restricted in the sense of requirements and restrictions [11][21][7]
on the modification, extension, and integration of it [18]. Only applicable to
software clopenness.
Based on the previous paragraphs the following definition of clopenness is created:
‘Clopenness can be divided in organizational and software clopenness, consisting of
options characterized by a certain degree of clopenness, which is determined by the
degree to which an option approaches the clopenness key attributes.’ In which it
should always be attached to a context and situation, such as clopenness of an
independent software vendor in the software development ecosystem or the
clopenness of a transport organization in the transport and logistics ecosystem. In the
next paragraph we will elaborate on how to apply this definition in order to assess
clopenness.
4. Clopenness Assessment
Based on the previous paragraphs, the Clopenness Assessment Model (CAM) is
created. It includes the clopenness types, options and key attributes to determine a
degree of clopenness; these concepts together form the base of the CAM. The model
is depicted in Fig. 1. In principle, clopenness of any context or situation in any kind of
ecosystem with respect to software and organizations can be argued and described
using this model and its techniques.
Fig. 1. Clopenness Assessment Model
56
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
In this section, we will describe how to use the model properly in order to
determine the degree of clopenness. (step 1) First of all, any clopenness degree is
context-dependent and situational and belongs to a software- or organizational-
option. For example, the context can be a „software developer ecosystem‟ in which
the situation is the clopenness of the ISV‟s software development process to the
customer. (step 2) The software development process is a software option and is seen
as a part of the ISV, which in turn is a system in the software developer ecosystem.
The customer or end-user is part of this ecosystem. The most crucial in this system of
systems are the connections between the parts that enable systems to „communicate‟
with their environment i.e. customers. Another context can be a „transport and
logistics ecosystem‟ in which the situation can be the clopenness of a transportation
organization‟s monitoring process to the customer. We will elaborate on this context
in the next section. (step 3) The most essential parts of the model are the clopenness
key attributes, the descriptions of which are found in the last section. The
descriptions should not be used mechanically, they can be openly used and interpreted
in narratives. A narrative is a story in a constructive format, which describes a series
of events. In this case, we create a „story‟ about an option to be assessed referring to
the clopenness key attributes and using the descriptions as guidelines or criteria for
this story. (step 4) Finally, a degree of clopenness can be determined. However, the
focus should not be on the exact number; the narratives are most essential, these give
a rich background and context of the case. To give an exact degree of clopenness, one
must value the derived criteria from the clopenness key attributes. From the
narratives, we can interpret and assign a value to these criteria. Based on how these
criteria are described in the narratives and thus how they are assessed these can be
assigned a value of 0 or 1, where the 1 states a high degree of clopenness and 0 a low
degree of clopenness. All values can be counted and divided by the total of the
derived applicable criteria, resulting in a degree, i.e. percentage, of clopenness which
can be placed alongside the continuum. For example, a clopenness score of 60%
would mean it tends to be more closed than open. As noted before, it is about the rich
background and context in the narratives which tells about the connections between
the systems or parts, not about an exact score.
In the next section the CAM is used to shape and formulate clopenness in the
transport and logistics ecosystem. We will elaborate on how clopenness influences the
relations between systems in the transport and logistics ecosystem.
4.1 CAM Evaluation
The CAM is evaluated through four case studies, existing of semi-structured
interviews with four experienced information technology managers, and is managed
using the case study protocol and a set of criteria. The criteria consisted of issues such
as the comprehensiveness and understandability of the model, the message it conveys,
the descriptions and interpretations of the key attributes, abstraction level and the
representation of the model. The Clopenness Assessment Model is overall positively
evaluated and well received, therefore evaluated successfully. The CAM conveys the
message of clopenness with respect to software and organizations.
57
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
5. The Interwoven Nature of Clopenness in Ecosystems
The term business ecosystem was first coined by Moore [19] as an analogy on
ecological ecosystems. The term business or commercial ecosystems was further
developed by Iansiti and Levien [13], and it is seen as a network of organizations, i.e.
businesses, suppliers and customers, which are most critical or closely intertwined
with your organization. Jansen et al. [14] shifted this definition towards software
ecosystems, which is defined as “a set of businesses functioning as a unit and
interacting with a shared market for software and services, together with the
relationships among them”. Hence, that a software ecosystem is part of a business
ecosystem, these blend together, and what they have in common is the term
ecosystem.
5.1 Ecosystems Case Study Context
The study is mainly focused on the business ecosystem in the transport and
logistics sector and the actors involved in it in the Netherlands. In the case study the
search is primarily aimed at criteria that determine the clopenness of software used in
the ecosystem and whose software is able to communicate inside and outside the
organization. The results from the study are used to shape and formulate clopenness
in the transport and logistics ecosystem, both software- and businesswise. Note, the
relation between organizational- and software- clopenness and the business model is
not discussed in this paper. First we will outline the situation and context of the case
studies, following with an example on how clopenness is interwoven within the
transport and logistics ecosystems.
The transport and logistics sector is a highly dynamic sector where the profit
margins are under pressure. In this ecosystem, a shift from closed to more open
systems is noticed; the environment, i.e. customers, demanding organizations to be
more open about various processes. Transport organizations do not know how to
control clopenness, they are „victims‟ of the supply chain. However, they are willing
to participate in this shift; giving or providing clopenness, but also expecting
customers to be more open to improve their own processes. We need to enclose the
remark that one of the four case studies was performed in the industry‟s association
Transport and Logistics Netherlands (TLN) to provide an additional rich background
for the other case studies. The carefully selected organizations for the case studies are
in a range from small to medium to large transport organizations, whose services are
mainly freight by road through Europe. The carried goods vary from a low to high
value, e.g. paper, raw materials, shoes or electronics. The revenues come mainly from
the distribution of these goods. The organizations have a transport management
system (TMS), which supports order-intake, planning, dispatching, monitoring and
transaction. Upon this system a fleet management system (FMS) supports real-time
monitoring of the fleet and communicates with the TMS. In one of three
organizations, the TMS and FMS are from the same supplier. Communication
between systems and environment is established with use of electronic data
58
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
interchange (EDI) and other data interchange techniques or standards, e-mail, a web
portal, or via traditional channels such as the telephone.
Software is developed in a software ecosystem within a business ecosystem, as
without business there is no software and no software without business or innovation.
Clopenness is intertwined in the connections between the different actors in the
ecosystem and influences the activities and transactions generated at these
connections. The transport and fleet management software is developed for the
Microsoft Windows ecosystem or platform. Bosch [3] identifies such an ecosystem as
an operating system centric software ecosystem, in which “third party developers
build applications that offer value for customers”. Microsoft is owner of the platform
and is therefore seen as the keystone of this ecosystem that retains a keystone
strategy. The key interest of the keystone is improving or regulating the health of the
ecosystem, and where the intertwined organizations, i.e. ecosystem participants,
benefit from this ecosystem and are dependent on this specific ecosystem [13]. One of
these participants is the independent software vendor (ISV), which is characterized as
a niche player. A niche player usually produces a function that customers require, its
existence is based upon the fact that keystones cannot produce all possible
functionalities [3]. The ISV handles a disciple or follower strategy, because the
developed software is committed to only one ecosystem [9]. The ISV produces
transport and fleet management software, which supports the activities and
transactions of a certain organization; in this case a transport organization.
Complementary, Bosch [3] noted that the ecosystem consists of “the set of software
solutions that enable, support and automate the activities and transactions by the
actors in the associated social or business ecosystem and the organizations that
provide these solutions”. Clopenness is an essential interwoven concept in this
software ecosystem and is involved in for example the relationship between the ISV
and customer; they are each other‟s dependants. However, this specific situation will
not be discussed in this paper. As said, business and software ecosystems are a blend,
the software development ecosystem is intertwined with the transport and logistics
business ecosystem. End-users or customers license the solutions brought forth by the
ISV. After all, the customers are the actors using the functionalities of the software
solutions that are built on the Microsoft platform. The transport organization can
benefit from how they control clopenness with the help of software. Building on the
definition of a software ecosystem by Bosch [3] we can shape the end-user or
transport ecosystem as follows: the set of actors or systems, i.e. businesses, suppliers
and customers, of which the interrelated activities and transactions in this transport
and logistics commercial ecosystem are enabled, supported, and automated by a set of
software solutions and other social connections between the actors such as exchange
of information and knowledge; a system of systems [1]. Within this definition,
clopenness plays an essential role. We view the concept of clopenness both software-
and businesswise of a system, a transportation organization, situated in the transport
and logistics ecosystem. The interwoven nature of clopenness in this ecosystem, in
specific in the latter (present) situation and context, is expressed in the following
section, using the CAM, described by means of the narrative method.
59
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
5.2 Case Study: Transport and Logistics Ecosystem
The following example situation, the monitoring process of a transport organization,
was present in each of the cases. Cross-case synthesis and replication logic were
applied to compose the example.
1. Availability. The monitoring process is an activity performed by the transport
company and services the company and customer with monitoring information about
the transport itself. The process provides a continuous stream of real-time information
about the fleet and its transported goods.
2. Accessibility. The process can be accessed by a customer through a web-portal
by means of a certain password or code, pushed or pulled through EDI or telephone.
Making the process and its information available externally has become obligatory;
customers will be dissatisfied when the transport company decides to make this
information undisclosed. Please note the goods are property of the customer, they
have the right to know what is happening with their property. The process can only be
accessed timely through a web portal, for the period of shipment and aftercare. Not
any interested person can access the monitoring process, because it is confidential
information intended for customers only. Meaning that the status towards the
company is taken into account, no competitor or other third party can access the
process, regardless of the field of endeavor they are in or any other reasons. Making
this process accessible for others than customers would create an unnecessarily
dangerous situation; confidential information will be exposed, in the worst case
leading to a high cargo theft risk because any interested person could track and trace
the trucks. The effects of increased accessibility are clear; lost revenues and
irreparable relationships with customers. Making the process not even accessible for
customers will dissatisfy them at least, they tend to look for other companies
providing the informational needs they desire from a company.
3. Transparency. Usually, information is omitted regarding the accessibility
mode. In this case, content is filtered based on the customer who accesses the
provided information from the monitoring process. The customer can only see his
shipment information, i.e. no other shipments nor the goods of other parties inside the
same truck or the load capacity in use. If the latter information is not omitted by the
accessibility mode, then customers may notice that the truck isn‟t even full while the
company said so; resulting in low trust. Also, valuables from other customers are
exposed, which should obviously not be the case. Another effect caused by exposing
more information is that the customer may come to know that a truck drives the same
route with two shipments, of which only one is his own, and because of this insight
the customer might propose the transportation company to split the distribution costs.
When that happens, the transportation company has no advantage anymore, because
they can‟t book the miles twice and invoice two customers with this. Therefore,
transparency should be carefully managed. Another example of this occurs in
dedicated drives, where the truck drives a fixed route for a customer a few days per
week. The transport company hides information such as the truckload and real-time
truck tracking, e.g. tracking on a visual map. They know there can be other customers
on the same fixed route, for which they can carry some goods. That could save the
company costs and generates additional revenues; the company can raise twice the
price. The transport company does this in such way that the customer does not notice,
60
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
by omitting information. After accessing the right information, shipment information
itself can be limited by certain factors. The information is not encrypted because it is
already protected by means of the accessibility mode. It can be beneficial for the
company to expose additional shipment information which meets the informational
needs of the customer, by providing a few of the essential value propositions:
estimated time of arrival, information on delivery, information on department, and
proof of delivery. Additional information could be status codes such as loading,
driving and unloading, but also reason codes; e.g. if you did not deliver then why did
you not deliver, if the goods are damaged then why are they damaged, if the goods are
late then why are they late, e.g. road closed, traffic jams, etc. The information is clear,
comprehensible and unambiguous for the customer and, using the reason codes, also
provides insights in the decision making process. Also, this information is not send in
raw data, but is clearly documented and represented. A customer has the right to
receive this information, after all the goods are his property. If information is made
less clear or fails to give proper insights in the decisions, the customer will most
probably drop its shipper. Experiences from other parties, negative or positive, are not
presented. This is the companies‟ knowledge, “you will not give a customer exact
details on this”. Negative publicity is not convenient when profit margins are under
pressure. Furthermore, the frequency of information disclosure to customers is well
suited to the informational needs of the customers; they can be informed at all times,
on all purposes, and through various channels.
4. Reciprocity. Transparency is one side of the story, the other side of the story is
that synergistic advantages can be achieved by involving the customer in the process.
Communications between the customer and company are enabled through various
channels, such as EDI, telephone or a web portal. However, this is no guarantee that
anything is actually being done reciprocally. Customers only want information, they
mostly do not provide information as input for the transport companies processes.
However, this information is gained via-via through the truck drivers, so they have
sufficient information in order to modify or update the shipment information. The
feedback for the customer is given at a satisfactory frequency and includes status and
reason codes. However, customers could give more feedback, for example about the
availability of unloading docks, enabling truck drivers to rearrange their schedule and
deliver another shipment in the same city first when the unloading docks are full. The
feedback frequency is limited by willingness of the customers, there are few
agreements on this issue.
5. Licensing. In this monitoring process of the type organizational clopenness,
licensing is not applicable. It is therefore not taken into account as it cannot cause
effects in this case.
In this section we have shown how the CAM is applied and works in the present
situation; the transport and logistics ecosystems. All narratives and decisions in it are
taken within the defined concept of clopenness. From the case studies we have
derived conclusions about clopenness in general and the interwoven nature of it in
ecosystems which are described in the next section.
61
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
6. Discussion & Conclusion
Discussion. The model is not the „holy grail‟, and it is noted that some external
factors may come into play such as trust, frankness and honesty. It is not clear how
these factors may affect the different elements in the model, such as the clopenness
key attributes. Several interviewees noted that trust management is likely to be closely
related to clopenness of systems and their benevolence. Regarding the CAM usage,
the guidelines should not be used mechanically, so it could be practical to create
guidelines for specific assessment situations or ecosystems.
Conclusion. Completely open or closed systems, software, or organizations do not
exist; openness is considered a false dichotomy. The holistic view of systems should
be addressed; i.e. the functional relation between the parts and the whole, discussing
about clopenness as a property of these relations. Trying to create awareness of
clopenness, understandable for everybody, seems easy. However, the underlying ideas
are complex. This paper highlights the complexity of the phenomenon clopenness,
elucidating this phenomenon by the construction of the Clopenness Assessment
Model (CAM). The latter model is evaluated positively throughout the case studies.
Essential in this were the assumptions or beliefs of the interviewees about the model
and its message. It is agreed that the CAM largely conveys or represents the genuine
message of clopenness with respect to organizations and software. Thereby, the model
stimulates and provokes discussion about the „open vs. closed dichotomy‟.
Furthermore, the interwoven nature of clopenness in the transport and logistics
ecosystem has also been investigated. Keypoint is that it is about understanding the
situation and the decisions made within the defined phenomenon clopenness. One
cannot just open up or close everything in their system, since generally the
environment cannot accept that. The CAM, and in particular the generated stories,
help to understand this. Relationships with the environment, e.g. transport
organization - customer, can only be efficient or useful when they are reciprocal. The
customer opens up the complementary process insights and participates in the
process. A high degree of clopenness in the right parts of these systems would be
helpful to be responsive and pro-active. Also, this ecosystem will face a rise of inter-
company-networks in the near future, which should be able to communicate based on
a high clopenness degree of the communicational processes in order to profit from
synergistic advantages. Clopenness should never be the goal, but be used as an
appliance.
Future research. In general, the principles of the general systems theory can
provide us with a conceptual framework for future studies on various systems, such as
information systems and complementary ecosystems, in which the main point is that
the connections between the parts make the whole greater than the sum of its parts.
Currently, the link between clopenness and business models is being investigated,
evaluating the effects of clopenness changes on the business model of an
organization.
62
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
References
1. Ackoff, R. L.: Towards a System of Systems Concepts. Management Science,
17, 11 (1971) 661-671
2. Blom, T., & Haas, B.: De Ondraaglijke Lichtheid Van Systemen; Over De
Grondslagen Van Het Luhmanniaanse Denken. Tijdschrift voor Sociologie, 17
(1996) 187-204
3. Bosch, J.: From Software Product Lines to Software Ecosystems. 13th
International Software Product Line Conference, (2009) 1-10
4. Boudreau, K.: how Open should an Open System be? Essays on Mobile
Computing. (2006)
5. Boulding, K.: General Systems Theory-the Skeleton of Science. Management
Science, 2 (1956) 197-208
6. Cerri, D., & Fuggetta, A.: Open Standards, Open Formats, and Open Source.
Journal of Systems and Software, 80 (2007) 1930-1937
7. Chesbrough, H. W.: Open innovation: The new imperative for creating and
profiting from technology. Harvard Business School Press, New York (2003)
8. Eisenmann, T., Parker, G., Van Alstyne, M.: Opening platforms: How, When
and Why?. In: Gawer, A. (ed.) Platforms, Markets and Innovation. Edward
Elgar, Northhampton, MA, US (2009)
9. Hagel III, J., Seely Brown, J., Davidson, L.: Shaping Strategy in a World of
Constant Disprution. Harvard Business Review, (2008) 1-10
10. Hocking, J. G., & Young, G. S.: Topological Spaces and Functions. In:
Anonymous Topology, pp. 5. Dover Publications, New York (1988)
11. Hodgkinson-Williams, C., & Gray, E.: Degrees of Openness: The Emergence
of Open Educational Resources at the University of Cape Town. Emerge
conference, (2008)
12. Hylén, J.: Open Educational Resources: Opportunities and Challenges. OECD‟s
Centre for Educational Research and Innovation, (2006)
13. Iansiti, M., & Levien, R.: Strategy as Ecology. Harvard Business Review,
(2004) 1-11
14. Jansen, S., Finkelstein, A., Brinkkemper, S.: A Sense of Community: A
Research Agenda for Software Ecosystems. 31st International Conference on
Software Engineering, New and Emerging Research Track, (2009)
15. Laursen, K., & Salter, A.: Searching High and Low: What Types of Firms use
Universities as a Source of Innovation. Research Policy, 33 (2004) 1201-1215
16. Maxwell, E.: Open Standards, Open Source, Open Innovation: Harnessing the
Benefits of Openness. Innovations, (2006) 119-176
17. McNair, B.: Glasnost, perestroika and the soviet media. Routledge, New York
(1991)
63
Eds: Jansen, Bosch, Ahmed, and Campell Proceedings of the Workshop on Software Ecosystems 2011
18. Mohsen, A., & Jansen, S.: Evaluating Architectural Openness in Mobile
Software Platforms. Proceedings of the Fourth European Conference on
Software Architecture: Companion Volume., (2010) 85-92
19. Moore, J. F.: Predators and Prey: A New Ecology of Competition. Harvard
Business Review, (1993) 75-86
20. Orlikowski, W., & Baroudi, J.: Studying Information Technology in
Organizations: Research Approaches and Assumptions. Information Systems
Research, 2, 1 (1991) 1-28
21. Pontin, J.: On Openness. Technology review, 112 (2009) 14
22. Riehle, D.: The Commercial Open Source Business Model. AMCIS 2009
Proceedings, (2009) 18-30
23. Rosen, L.: Defining Open Standards. 2010 (2004) 9
24. Takeda, H., Veerkamp, P., Tomiyama, T. et al.: Modeling Design Processes. AI
Magazine Winter, (1990) 37-48
25. van Lier, B., & Hardjono, T. W.: Luhmann Meets the Matrix. Exchanging and
Sharing Information in Network-Centric Environments. The 14th World Multi-
Conference on Systemics, Cybernetics and Informatics, 3 (2010) 300-305
26. von Bertalanffy, L.: An Outline of General System Theory. The British Journal
for the Philosophy of Science, 1 (1950) 134-165
27. von Bertalanffy, L.: The Theory of Open Systems in Physics and Biology.
Science, 111 (1950) 23-29
28. West, J.: The Economic Realities of Open Standards: Black, White and Many
Shades of Gray. In: Greenstein, S. and Stango, V. (eds.) Standards and Public
Policy, pp. 87-122. Cambridge University Press, Cambridge (2007)
29. West, J.: How Open is Open enough? Melding Proprietary and Open Source
Platform Strategies. Research policy, 32 (2003) 1259-1285
30. West, J., & O'Mahony, S.: The Role of Participation Architecture in Growing
Sponsored Open Source Communities. Industry & Innovation, 15, 2 (2008) 145-
168
31. Xu, L., & Brinkkemper, S.: Concepts of Product Software: Paving the Road for
Urgently Needed Research. First International Workshop on Philosophical
Foundations of Information Systems Engineering, (2005)
32. Yannikaya, H.: Trade Openness and Economic Growth: A Cross-Country
Empirical Investigation. Journal of Development Economics, 72 (2003) 57-89
33. Yin, R.: Case study research: Design and methods, Vol. 5. Sage Publishing,
London, New Delhi (2003)
64