KDE ON Program: Dealing with private and public

When I began with Free Software I already was CEO of a little company back in the Canary Islands. To me it was a complete shock getting in contact with LTSP first and KDE later. In both cases I had business projects related with their technologies so, at the very beginning, that relation with them was a matter of pure business.

I remember thinking.... If they behave like crazy nuns, fine, I won't. I felt like the The Walking Dead lead actor. Not many months later, I realized I was one of the zombies. Still, both project made easy for me to get involved. No regrets, no blames, no pointing fingers.... just friendly hackers.

This common experience can be softened. Times have changed but business culture not so much. KDE ON Program must reduce this culture gap. One the main issues to do so is clearly defining how to deal with confidentiality, a key point for organizations.

When designing a Program like KDE ON, that deals with organizations, specially with companies, one of the possible conflicts we need to take in consideration is the different views/models/culture we have around confidentiality, about what is public and what should be kept private.

FLOSS communities, like KDE, that evolve in the Open, tend to reduce as much as possible the amount of private information, forums, decisions. Companies usually promote the opposite.

We have a tough challenge ahead of: to bring organizations into the open in a compatible way with their current business culture.

Someone might think that it is just a matter of building trust. But we know that is not enough. We have seen in the past how strong relations between companies and communities fell apart in seconds. We need to establish some procedures ensuring that common spaces can be built where private and open meets comfortably.

KDE-ON Program, our effort to create an ecosystem of organizations around KDE, must define those meeting points without changing our ground rules, which it won't be easy if we want to become attractive to organizations, so they join us. We should not underestimate their fears to the Open, specially when dealing with managers, born in the classic MBA business culture.

We have around KDE (other community projects too, obviously) many companies that, at different levels, understands and/or have experience dealing internally (and with us) with many of those fears, misconceptions, reactions, etc. Along with other experienced KDE members, I feel we can do a great job teaching organizations how powerful and profitable embracing the opening could be.

Don't you remember the first person that showed you how cool Free Software was? We always tend to have a special relation with our first mentor, that special teacher that opened our eyes, that first love that allowed us to discover a new world, right? That is the kind of hit we are able to create in many CxO that, hopefully, will get involved with us through KDE ON Program.

So KDE ON Program should be for participants a learning process that end up allowing them to build long term relations with Free Software community projects in open forums, in a FLOSS life style, accepting some Free Culture principles. At the same time, it should help us to understand them better, so along the road we can become a more business friendly.

Let's see if we do it right in KDE ON, or at least, we create learning spaces understanding we are in a, somehow, R&D environment. So we all judge our mistakes with scientific, or at least not pure business, eyes.

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.



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.