Building innovation nodes through Free Software Communities (VII): activities

This is the seventh post of the Building innovation nodes through Free Software Communities series. In order to fully understand this one, please consider reading the previous ones. p, li { white-space: pre-wra

There are several kind of activities that can be very productive and aligned with the goals of the project. We can group them in several ways. Maybe the most general one is:

  • Promotion activities.
  • Training sessions.
  • Discussion/reflexion.
  • Networking activities.
  • Demonstrations.
  • Administrative/coordination meetings.
Some of the activities will be organized directly by communities. At the beginning of the project they would be the majority. But the project must be open to organize activities proposed by local agents and non members that are aligned with the project goals. Cross-community actions should be also promoted.
Opening a call for activities is a very good thing to do. There has to be also flexibility to allow activities that do not need a lot of effort to organize so they can be proposed with not much time in advance.
Some of the most common activities could be:
  • Promotion events (talks, lightning talks, keynotes, etc).
  • Demo events.
  • Workshops and training sessions.
  • Cross-community events.
  • Announcements and press conferences.
  • Sprints and hackfests.
  • Communities Assemblies and board meetings.
  • International events.
  • Internal meetings:
    • General Assembly and Board meetings.
    • Other internal meetings.
  • Interviews.
  • Video and audio conferences. Streamming.
As explained in the Organization section, there should be a comitte that takes care of coordinating the activities so they make sure that there is a variety of them in terms of goals, participants and achievements. This Activities Coordination Group will make also sure that the activities schedule satisfy both, current project members and local agents.
It is desired that every member celebrates in the project facilities at least one activity every year. A good goal could be to celebrate every member annual event each three or four years, so they make sure a relevant one takes place at least once a year. 
It is a good practice not just to generate local critic mass but also to ensure that the project is attractive enough in terms of sponsorship.

What is the KDE Program?

Executives find valuable to become part of a common network that allow them to open their organizations to new markets, more opportunities in current markets, new products, services and talent. KDE can offer them such a worldwide network formed by many organizations.
In order to do it, KDE build a structured Program based on the following global principles:
  • Networking as a major value to build self-sustaining cooperative system.
  • Meritocracy and compromise.
  • Mentoring.
  • Single contact point for every organization.
  • Think global, act locally.
  • Scalability, depending on the organization dimension and expectations.
  • Building the field first, creating the rules, and then, let the players play.

The KDE Program(*) is the result of our determination to create a global network formed of organizations committed to KDE related principles, technologies, products and services. It also is:

  • A structured project to add value to KDE, while increasing market opportunities for every member through coordinated networking  activities.
  • A way for KDE to connect with end users through new organizations.
  • A new approach for supporting KDE in a way every member gets, not just the result of our work, our software, but also the knowledge that allows us to create it, so they can learn and add it to their production process.
  • A channel to introduce KDE into new markets through a worldwide network of organizations that actively contribute to it.
  • An opportunity to recognize and reward those organizations that have historically supported KDE.
  • A new approach to take free software communities beyond their current influence area.
    (*) Remember that I am still looking a good name for the Program

KDE Program: Mission and Goals

The last weeks I’ve been putting some effort in thinking about how KDE (and any free software community) can build a network of organizations taking in consideration the weaknesses and strengths KDE (or any other FLOSS project) have.

I wrote a few posts about previous ideas I thought it should be taken in consideration before putting effort in defining a formal design for a Program that leads us to the discussion and execution of an action plan.

Now the idea is to define the Mission and Goals of such a program. In order to understand why of the following ideas, I recommend reading previous posts about this topic in my blog:

Some preious ideas about building new ecosystems around free software projects (I, II, III, IV and V)

Since we develop and publish KDE for free (as free beer), organizations usually do not understand well where our value is and how can they take advantage of it in a way our ecosystem is nourished, which is essential to keep the wheel spinning. Most organizations, especially corporations, associate value with money. This classical, product oriented, point of view must change in order for us to be recognized as we think we deserve. We can improve the way we communicate our value associating networking (as a service) to our software.

So the KDE Program Mission is:

  1. Helping organizations to know us, what we do and how we do it, so they appreciate the value of KDE and support our action.
  2. Giving them something valuable associated with our software, affordable for KDE, that allow them to increase the chance to grow.
Both ideas can be summarized:

The mission of such a project is to create a global, sustainable and structured network of organizations that shares KDE principles and interests.

KDE Program Goals

Major Goal
The major goal of the KDE Program (KDEP) is to establish the conditions and develop the actions needed to create a network of organizations committed to KDE principles and goals. This network will evolve in an ecosystem by increasing the relations among them and with the KDE community.

This network/ecosystem will be defined to grow, not just in number but in value, satisfying its members shared goals.

Other goals

Other goals of the KDEP are:
  • Present KDE as an attractive opportunity for organizations to become part of a global network that will benefit all of us.
  • Increase the number of organizations involved with KDE.
  • Improve KDE’s relationships with other organizations.
  • Create new business opportunities for those organizations involved in this Program.
  • Support local teams. Relations grow better in common environments.
  • Open job opportunities for KDE developers.
  • Increase the number of new developers so we make sure the new ecosystem can grow.
  • Spread KDE principles and vision to other organizations.
  • Feed KDE with third party experiences, knowledge, technologies, etc.
One of the things that is taking me some time is to look for a proper name for such a program. Any help is welcome.

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

    Related to our topic, the most relevant internal factors /strengths and weaknesses) I can think of are the following:


    • Passion.
    • Collaboration. Sense of community/identity.
    • Worldwide project.
    • Prominent FLOSS project. Well known brand.
    • Leading technology. Innovative.
    • Well defined product (software).
    • Broad base of skills.
    • Efficient development process.
    • Economically sustainable.
    • Internal communication.

    Passion: KDE, like other community projects, is formed by people passionated about what they do and aboutfreedom.

    Collaboration. Sense of community/identity: this culture make them extremely efficient and determined when decisions are taken, reaching goals that might seem impossible.

    Worldwide project: KDE is a worldwide project, with active members all over the world, that speaks in many different languages and come from many different cultures.

    Prominent FLOSS project. Well known brand: KDE is one of the current leading free software projects in the world and its brand has a high value, not just because of the product delivered, but because of the clear identity behind it.

    Leading technology. Innovative: KDE develop some of the most interesting technologies in the software industry for desktops.

    Well defined product (software): KDE Platform, KDE Workspaces and KDE Applications form a whole product that give answer to millions of user needs all over the world.

    Broad base of skills: KDE is formed by people with many different skills, experience and motivations. It is a rich community.

    Efficient development process: to develop and deliver the product throughout 15 years, KDE have a
    complex, efficient and innovative development process. Coordination.

    Economically sustainable: KDE is todays an economically sustainable project. Budget control and management is efficient.

    Internal communication: KDE has solid communication channels and procedures with high participation.


    • Weak marketing culture. Lack of experience.
    • Lack of resources for non technical activities.
    • Complex ecosystem.
    • Complex decision making process.
    • Diffuse points of contact.
    • Self criticism.

    Weak marketing culture. Lack of experience: marketing haven’t been a priority in the past. We can do much better in this area.

    Lack of resources for non technical activities: some non technical areas need more manpower.

    Complex ecosystem: KDE is a big project with a complex structure. It is not easy to understand it when you come from traditional organizations.

    Complex decision making process: because of its nature, some kind of decisions are hard to make in KDE. This is common to most community driven projects.

    Diffuse points of contact: approaching KDE can be hard to do since we lack of globally defined roles. Some knowledge of how KDE work is needed to make the approaching process efficient, specially for non technical issues.

    Self criticism: KDE has a strong sense of self-criticism, which is really good for internal processes, but harmful if it is made public continually focusing on weaknesses.

    Once again, if you think some other elements must be added, feel free to make comments to this post.

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

    In order to fully understand this post, you will need to read the previous two of this series Some previous ideas about building new ecosystems around free software projects (I and II).

    As every community, KDE has members with key positions within some organizations. Some of these can be considered already part of our network of companies. A little group of them can even be considered part of KDE ecosystem. But they are just a few. There are hundreds of organizations out the re that agree with our principles, that use our technologies, that deploy it, support users, teach the tools we use or develop……Many of them would be willing to collaborate with us, or even build a strong relation. 
    Free Software communities have a lot to teach to organizations. We are great examples of how a complex product can be developed openly. Just a few organizations out there can compare their products and impact with ours. So why it is so hard for us to involve more organizations in our free software projects?
    To answer this question, I will go back to some questions made at the end of the first post of the series:

    1. What do we want from organizations?
    2. What can we offer them?
    3. What do they want from us?

    1.- What do we want from organizations?
    I haven’t done a wide research among KDE members, but it is not hard to point the most popular answers, depending on the type of organization we are talking about (remember that we are focusing in three different types):
    • Education related organizations:
      • KDE promotion among teachers and students.
      • Collaboration with KDE and local companies in KDE’s development.
      • Collaboration with KDE through P&D projects.
      • Including community driven development process and KDE tools in their programs.
    • Corporations/SME:
      • Funding KDE.
      • Adding resources to the project.
      • Hiring KDE members and promoting they have time to contribute to KDE
      • Sponsoring our events.
      • Support our marketing actions.
      • Coordination in technical and strategy decisions related with KDE.
      • Participate in the testing/QA/support phases of the KDE software life cycle.
      • Share contents related with KDE.
    • Non profits:
      • Advise/consultancy
      • Improve our relations with Govs., other non-profits, representatives from no IT sector, media, etc.
      • Funding KDE.
      • Adding resources to the project.
      • Sponsoring our events.
      • Support our marketing actions.
    Please feel free to add a comment if you thinks there’s something missing.
    2.- What can we offer them?
    • Our software (product)
    • Services:
      • Consultancy in many different areas related with software development, tools, design, etc.
      • Networking with organizations and people around the world.
      • Exposure.
      • Branding.
      • Content creating related with our software.
      • Technical support.
      • Training.
    There are some services could be also some services that, even though we can offer them, the resources needed in case of success do not scale, for example. I mean that some services can only be offered with guarantee under certain circumstances.
    3.- What do they want from us?
    The most common not pure technical request usually are:

    • Many organizations related with KDE frequently come to us looking for technical support. 
    • We have had in the past requests to associate our branding with different kind of organizations. Partnership programs are becoming popular among free software projects lunched by a company or a commercial consortium. 
    • Sometimes we recieve request from companies that encourage us to change our schedule, giving priority or claiming for certain new or past features.
    • Since KDE is what they see/use, sometimes they assign to us bugs that are in fact somebody else’s responsibility. Distros share with us this problem.
    • Contents are a common request from organizations. Howto’s, User Guides, etc.
    • Translation is also a common request. Even though we make a huge job in every release, it is impossible to launch our software and our contents in every single language.
    • Consistency is another request. Since in KDE you can run all kind of applications, not just KDE ones, it is impossible to manage every problem related to this.
    Like in the definition process of every strategic plan (that is exactly what we are doing), these answers must be prioritize for every type of organization. The above are not in order.
    In a simple world, matching what we can offer with what organizations want (for every type ) give you a good idea of where to point our strategy. But there is another important question that we have to answer before making any conclusion.
    What do we want to offer?
    Every Free Software community have its own culture based on strong principles, as explained in the second post of this serie. So there are certain services that we CAN offer but, for different reasons, we DON’T WANT to. Some other services are very hard to scale.

    Many of the people/organizations that approaches us really don’t understand who/what we are. Note: we have to do a lot more in this area… So for them some things seem obvious and they are not. In this discussion related with services, that statement is also true.

    I assume that KDE would want to offer, in addition to our product, services that share these characteristics:

    • Aligned with our culture.
    • Adds value to our product and the receiver, but also to our community.
    • Scalable.
    • Require more manpower on areas we are stronger. This mean that what we should offer must lay on our strengths, not our weaknesses.
    • Not required high availability, wich means that should not lay on specific people. KDE contributors are not full time employees in most cases. 
    The following step is defining the ideas and concepts that will support the Program that can take us to building a Network of organizations that could evolve in the future into a healthy ecosystem.
    All the above are my points fo view, even though sometimes I use we.