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:
- What do we want from organizations?
- What can we offer them?
- 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.
toscalix 