Some previous ideas about building new ecosystems around free software projects (II)

Some definitions

The first step I’ve been doing lately in order to try to write some ideas about a network  of organizations around KDE is to read a little about basic definitions. We need to have definitions in mind in order to use them properly.

Network (social)
Please check the definition from Wikipedia. It is important to understand that:
  • A network implies interdependency between nodes.
  • Wikipedia is explicit about knowledge and prestige as two types of interdependency between nodes.


Please check the definition from Wikipedia . We need to keep in mind that:
  • A community share common values
  • Those values along with the interactions between community members generates a shared identity.
  • Community comes from latin, meaning “in common”. Communis is a complex word: com + munis. Com is “cooperator” and munis means “helpful”, “who fulfills his duty”. These ideas are present in our mind when we think about KDE, right?
Most of the readers remember this definition from school. There are a few points about it that will be important for this and the following articles:
  • An ecosystem involves living beings along with physical factors that affects them.
  • The concept do not depends on dimension.
  • Ecosystem implies that its members depend on each other.
  • A healthy ecosystem is sustainable, an unhealthy one it is not.
  • An ecosystem is said to be healthy when is balanced.
  • The balanced concept is strongly related with the reproduction of the species within the ecosystem.
These three concepts are going to be very popular in this series of post about building an ecosystem of organizations around free software projects, like KDE.
Understanding what we already have
To build a network of organizations around KDE we do not begin from scratch. Around KDE there are a few organizations that somehow “belong to KDE”, I mean, most of us feel they are strongly related to our community. 
What kind of relation do we have with them? What do they have uncommon? Why it is so easy and natural for them to be part of KDE and so hard for others, even for many of those that use and help us to develop our software?
An ecosystem is formed by different type of “species” that are related to each other in different ways. If we do not understand the relation we have with these “KDE organizations” and how they were built, we will have a bigger chance of failing in our goal.
Please feel free to answer to these questions via comments on this post, e-mail, etc. 
I think there are three key points to mention:
  • Many of these organizations are founded by people that were previously KDE community members. This element is common to other communities. I know a few cases in GNOME and Debian, at least.
  • A significant percentage of their workforces are KDE community members, some of them are “primary nodes” and its business largely depends on technologies developed or used by KDE. Collaboration comes naturally.
  • They have a culture as organization influenced or aligned with KDE principles which reduces frictions in case of conflict.
My conclusion is that these “KDE companies”:
  1. Understand our culture.
  2. Participate in our evolution as community. 
There are many organizations related to KDE, obviously, but just a few have both characteristics, which define, in my opinion, the strong relation with KDE. Some only have one of them and are not visualized internally like “part of KDE”, at least not in the sense of “belonging to our ecosystem”.
The first factor is about knowledge, about experiences, about philosophy and ethics. It is about those fundamentals that every free software project share, but also about those that define every one of them, making them slightly different. Definitely, it is about people and relations.
The second factor is about procedures, about resources, about technology, about impact, branding, exposure…… 
In order to build a healthy ecosystem, formed by organizations, around KDE (any free software project), the project design needed, the derived action plan, every activity or service involved, must have as a basic goal to improve those two key factors as if they were linked, since they have proven to be necessary to generate long term relations. Otherwise, the ecosystem might not be sustainable, and the enormous effort involved in creating it will be somehow wasted. 
Maybe there are other approaches, but I haven’t been able to understand them or there is no clear evidence of success yet.

3 thoughts on “Some previous ideas about building new ecosystems around free software projects (II)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.