Apply agile methodologies to upstream development environments.... if you can.

 Introduction

When the Agile Manifesto became popular and based on them, agile methodologies like Scrum, XP or Kanban, upstream development was in its early stages as collaboration ecosystems of companies.

Only a few for profit organizations embraced developing upstream back then. Most of them were small and heavily influenced by FLOSS engineers vision. Free software communities were basically driven on personal basis or the very lucky ones, together with "sponsored developers". In general, these ecosystem were not part of companies strategies.

Today, more and more companies are getting fully involved in community projects as stakeholders, not just consumers or simple contributors.

They frequently start as consumers, then, little by little they become "upstreamers", that is, they share/publish their code with the goal to have it merged (upstream code). Not without effort, many of them become successful contributors.  After some time, some of them end up understanding that is "cheaper" to play by the project rules. In summary, they learn to become good citizens.

A subgroup of the above companies end up including these collaboration ecosystems as part of their own strategies, going from contributors to  key stakeholders. A necessary step to achieve this goal is to work upstream.

Walking this path present many challenges. One of the toughest ones is related with the differences in development methodologies used internally (mostly agile) and those used in the collaboration ecosystems.

There are two fundamental variables that, in my opinion, determine this challenge:

1. Environment
2. Culture

Challenges

1.- Environment

There are two dependent variables that were not taken into account (or just partially) when the agile methodologies were defined, that are relevant in upstream development:

1. Community projects are global environments, that is, contributors are located in different "offices", frequently in different time zones.
2. Probably due to the original amateur condition of early contributors, together with the "distributed condition", the development processes (so the tools) in most mature community projects, consider, manage and tolerate high levels  of latency.  "Real time" is restricted to IRC discussions and events/conferences.

These two factors has made open source what it is today. They have been "success factors".

Agile methodologies do not embrace "distribution" environments. The widely accepted recommendation is that teams should share a physical space. It is way more than a recommendation. It is somehow a requirement.

The second case, "latency", is considered by agile methodologies as a waste. It is not tolerated.

2.- Culture

Free Software was born as a reaction to a system that promoted corporation interests over developers, so users. The agile movement was a reaction to those methodologies that put process first, not people. Hence, it is obvious that both movements share a lot: people first. 

This is reflected by some when saying that FLOSS development is agile.

In my opinion, there is a big difference between what agile methodologies and what Open Source development propose in terms of principles.

Agile methodologies promotes a strong team culture. Open Source was born "based on champions". FLOSS culture normally applies the meritocracy concept to individuals.  Open Source projects are organized around contributors, around specialists, not around teams, as we understand them in corporate environments.

This is no surprise since Agile was born in companies/corporations and Open Source was born as a viral movement, grown "by aggregation".

The conflict

In my opinion, the more the industry embrace open source, and as result, open collaboration, the higher the conflict developers and managers will face due to the above challenges.  Companies are becoming more distributed environments and are working more and more upstream, instead of simply being consumers or occasional contributors.

In consequence, it would not surprise me if we hear more and more about  "corporate development methodologies" (a.k.a. agile) vs. "upstream development methodologies" (a.k.a. FLOSS).

Scrum, XP, Kanban -ish fans will need to face those challenges and find solutions in order to succeed in open collaboration environments. In the same way, based on the increasing influence that companies are gaining in these ecosystems, FLOSS methodologies in a few years will differ from what we knew 10 years ago.

This conflict will not be (is) about a R&D vs a product/service vision, it is not about creativity vs efficiency, it is not about micromanagement vs autonomy or teams of juniors vs specialists either. It is about methodologies applied to specific environments and its limitations. Maybe a simple update of the most successful agile methodologies will do the job.... or maybe we need to revisit some of the principles.

If you got here, maybe you want to take an extra step and answer these questions. I would appreciate it:

1. Do you perceive this conflict as I do?
2. Am I missing other key elements in the diagnosis?
3. How do you think we can adapt agile methodologies so they can be adapted to FLOSS environments?
4. I am interested in knowing how you adapt agile methodologies to overcome the above challenges. I plan to write about my experience these coming days.

Where the corporate and the upstream worlds meet.... or collide.

From the corporate world I frequently hear how hard it is to predict and track what upstream developers do. On the other side, developers that work part or full time  upstream frequently underestimate the need for communicating what they do in a way that enable others (or themselves) to provide deadlines and effort estimations. Upstream and product "time lines" and cultures often differ too much to be compatible under the same environment.

Developers that come from the "product" side of the story often refer to agile methodologies like Scrum as a good approach to solve this collision. It is unclear though the applicability of this and similar methodologies to highly distributed environments, where latency is high. Although most accept today that FLOSS development is agile, I find hard to assume that we are close to find good answers when it comes to development methodologies and upstream.

There are several different scenarios I have worked on where I have to question everything I knew up until then about this particular topic. In a couple of occasions, with a bigger or smaller community, the people I directly worked with were upstream. This allowed us to define up to a great extend the methodology we worked with.

In Linaro now this is the case for a particular project. But in general, in my Group we work upstream (in the Linux Kernel), that is, we cannot define the methodology since it comes defined by the project itself. It is not the first time I face this situation although I never did at this scale.

When you are upstream, the methodology used by the core team, together with how the project work packages and workloads are organised heavily influences the success in getting contributions from third parties. Together with other key variables, how you manage latency determines how many people can follow you and potentially contribute. In summary, the faster you move the harder it becomes for contributors to collaborate with you.

Hence agile methodologies come with a high risk: isolation. And this is obvious by just analyzing the prerequisites associated with the methodology itself.

Obviously this does not mean that scrum and other methodologies are not great ones. I am just pointing challenges associated with apply them when working in a community that you drive. You need to balance the efficiency of your team with the contributions you might potentially loose from externals.

The challenge is even bigger when you are just a participant in a community. In some way, your team goes beyond your colleagues at work. Latency is frequently too high to even consider yourself and the people that works close to you "a team" in the classical sense of the word.

If your own team is distributed, even if they are in the same time zone, then we are talking about the real deal, the master challenge for managers and developers. 

Imagine now that your team is formed by 10 people distributed in 6 different time zones in 3 different continents. Then you take one of those cool books that tries to explain how to create great software using this or that methodology and, in order for you to finish it, the writer must be a really good one or you really need to be an avid reader :-) 

Still you need to make plans, to predict when a feature will be finished, when it will be merged, you still need to manage dependencies, expectations, budgets.... you still are tight to somebody else needs and requirements. You still need to fulfil expectations despite the fact your control over the environment is limited. You have team mates that depend on your work, that needs to know what you are doing and how.....  you are still part of a business no matter if you develop upstream or not.

How can you make compatible the upstream development processes used in the community you are contributing to with the way your company works? And how about your customers and partners, if you have direct relation with them? How can you take the good things that agile development propose and apply them to an environment with high latency, where one of your bigger challenges is to have an efficient team meeting, since people are distributed across the planet?

At Linaro, the engineering management team, together with our PMO, are taking a close look at this challenge, in order to iterate from our current system to a more efficient one, better adapted to our new reality, after our significant growth during the past 18 months. The idea is to find a place where corporate and community processes meet... without colliding. You cannot stop adapting, innovating, trying new things..... or you pay a high price.

One of the great things about Linaro is that we are a unique environment so we can innovate at various levels, not just at the technology one.

Open Sorce Forum at CebIT

For those of you attending to CebIT, let me tell you that I am giving a talk about what we do at Linaro on Monday March 16th at the Open Source Forum. It is the first time I talk about my current job in public so I am very excited about it. It will be also my first time in CebIT so double doses of excitement. And yes, I will talk a little bit about Linaro new initiative, 96boards.

Core Dump

The past months we have published a few articles about what we do at Core Development Group at Linaro. Our blog is called Core Dump. Check it out.

Two risks when working as employee in Free Software communities

I would like to point two risks that I have experienced myself and as manager throughout the last few years working in open environments (Free Software Communities) or projects involving interactions with them.

1.- In any community, there is so much to do...., so many interesting and innovative areas, so many disruptive ideas that can make a difference. There are so many projects that, with a little extra effort and some knowledge, could improve so much....everybody would notice the change, the difference, the impact.

When working as employee or as sponsored contributor you interact with so many people that needs help, that deserves to be helped, that you can learn from... that if you are not strong enough, after a while, without noticing, a significant part of your agenda is somehow determined by those who you help. But although you work on the same project that they do, share principles and environment, they not necessarily share your goals, your responsibilities, your duties, your motivations.

Spreading the energy through different areas, working under demand instead of having a clear control of your agenda, focusing on short term results instead of mid term ones, becoming a pillar for everybody else work in detriment of your own goals, of your own results, is a common syndrome I have suffered myself for a while, specially when working remotely from home, and I have experienced as manager of teams and projects.

What makes the action of any team (or professional) significant in any environment, and particularly in a open ecosystem like a Free Software community, is their ability to maintain during a long period of time a sustained effort focusing its energy in a single point. Only when the plan is achieved or after a proper analysis, jumping to another one is the right thing to do (in normal conditions, obviously).

The effect is even bigger when those points of focus are linked, serving a mid/long term purpose, aligned in a concrete direction. Then the impact is multiplied by the alignment of other people around you.

A key toward success is selecting targets with high impact, spreading its positive effect through the entire project. This multiplying effect requires a high amount of energy in early stages (activation energy).  The chances to create a significant and direct impact in several areas of any project at once are very low unless your team is big... and many not even then.

So the first risk is the loose of focus and its consequence is a reduced impact of the work done.

2.- Working in a Free Software community is one of the most rewarding experiences I have had in my life. I feel appreciated. My contributions counts. Many people is aware of them. I can work to make them more noticeable. The more popular my contributions become, the more people express me gratitude. The more relevant I become, the more people listen and interact with me...

This process is a spiral that you can learn how to climb in an effective way after some years. We end up learning how to play the game.

When you are a long term contributor and you are in charge of a key part of a project this is exactly what might happen. You arrive to the top of the pyramid, which is a comfortable zone. Too comfortable sometimes. If internal and external balanced forces are not applied, like competition, an adequate professional environment, external pressure/challenges... even the best professional can become too pleasant.

Reward can become a strong drug. It might elevate you in a bubble that, in the mid term, might have a direct and negative impact in the quality of the work you deliver. This is specially true for engineers/contributors that lead significant areas of a community project in which there are not enough contributors to create quality assurance procedures. Or are not applied to the leaders.

The second risk is the lose of "self demand" and its consequence is the reduction of quality of your work.

In my case, changing responsibilities and working environments every few years have helped me. I am not sure to what extend though. Others should judge it, I assume.

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:

Strengths

• 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.

Weaknesses

• 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 (IV)

After the previous three articles about very basic previous ideas to take in consideration before designing an engagement program for organizations, we need to think about what are going to be the concepts to base our program on.

To have a better chance to succeed, we have to build our program on our strengths and not on our weaknesses. In order to identify those strengths, I've made a simple SWOT diagram.

This entry will describe the major opportunities and threats I see that might affect to our plan of building new ecosystems with organizations.

Opportunities

• Free Software culture expansion.
• Desktop – web relation.
• Free Software business models success.
• KDE has millions of users.
• KDE cross platform strategy.
• Software everywhere.
• Increasing market pressure over Universities to include free software topics.
• Free Software seen as strategical for by many countries.

Free Software culture expansion: more and more organizations are interested in crowd sourcing techniques and in collaboration processes like the ones we use for software development. Movements like Open Data, Open Gov. Free Culture, copy-left, Free hardware, etc. are strongly related to the free software culture. Some of those movements are interesting for many organizations. A community project like KDE can expand his influence to other areas.

Desktop – web relation: interaction between the desktop and the web, along with the irruption of small devices, can allow us to expand our influence to the web world, where many organizations are extremely interested.

Free Software business models success: more and more organizations, specially companies, are developing free software business models where upstream collaboration is seen as a good value.

KDE has millions of users: KDE have millions of users so we are a good target for organizations that wants to reach them.

KDE cross platform strategy: KDE is a multiplatform and multidevice project. There is a shiny future ahead of us if we keep pushing in the current direction.

Software everywhere: software is becoming strategical in many industries. Free Software is becoming popular is most of them. KDE has more and more open markets every year.

Increasing market pressure over Universities to include free software topics: since free software is getting popular in IT industry, the pressure over Universities and other Education organizations is much bigger than in the past. This mean that the cost for KDE to find potential contributors will decrease.

Free Software seen as strategical for by many countries: more and more countries are defining national IT strategies around free software due to political, social and economic reasons. This will open us new markets.

Threats

• Classic Free Software threats like software patents, closed formats, etc.
• Key players without a clear and stable strategy.
• Increasing our relations scope.
• Management.
• Resource dimensioning.

Classic Free Software threats like software patents, closed formats, etc: KDE and any action we take toward building new ecosystems with different types of organizations are permanently threatened by them.

Key players without a clear and stable strategy: because of different reasons, many stakeholders that traditionally or lately have been supporting KDE, change their strategy often. Although KDE has proven in the past to be good at isolating the impact produced by them, tensions might increase in the future.

Increasing our relations scope: KDE has been very successful at attracting technical contributors and other non-profits related with free software. It is not clear that we can extend that success to other type of organizations.

Management: KDE will face some management challenges in the near future due, among other factors, to the growth rate it is experimenting. Increasing the ecosystem to other type of organizations will stress even more the actual management resources.

Resource dimensioning: overload takes any organization through many non desired consequences like quality decrease, internal tensions, expenses, management inefficiencies, etc. Like in any community project, properly resource dimensioning and control is specially difficult, since our community is formed mostly by volunteers.

Isolation from the free software-business relation: KDE, like other free software communities haven't been in the past very interested in the business side of free software. We are more technical focused. The increasing economic success of free software will force us to put energy into this area to avoid isolation.

Yes, there are probably many more, but I hope most of them are somehow included in these ones. Otherwise, feel free to add more through comments to this blog 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.

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.

Communiy

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?

Ecosystem

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.

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

There are a few free software projects out there that have been very successful through the years in attracting developers and building awesome development environments. KDE is one of them. Every new version of our KDE 4.x series is the result of a complex proccess made by hundreds of people working remotely as a well structured group of coordinated teams. We haven't stop growing during our 15 years of existance and the impact and scope of our work is now wider than ever. Several other free software projects are experimenting similar behaviors.

The result of our huge work has a great technical and commercial value. It is also a good testing/learning field for the people involved. Their professional careers add value by becoming part of projects like KDE. Big corporations are aware of this and it is common to see them hiring people in community events or trying to influence free software projects in many ways. 

Relations between mature free software projects and big companies have been always complex. Along with the growth of free software in market, conflicts are increasing since corporations are adding more pressure into community projects. Many of them are commercializing products/services based on technologies supported or developed by these communities and we do not always have the same goals. The recent conflicts between GNOME/Canonical, KDE/Nokia, Kernel/Google, MeeGo/Nokia-Intel, LibreOffice/Oracle, MySQL/Oracle are just some examples. More are yet to come.

On the other hand, these multinational companies had put resources and money on our projects allowing us to become what we are now. By using and building their strategies around our/their work, they have helped us to reach millions of users. We do have a huge impact because of them too.

Smaller companies: new players

During the last few 3-4 years we are experimenting how some smaller companies are becoming part of our ecosystem. Some of these companies fit very well because they were founded by community members, but some others simply understand the benefits of building their products and services staying close to the decision forums, adding resources to the development proccess, so they ensure they know the technology. This small but innovative companies usually have a strong free software culture. Their size do not allow them to have their own strategy around the technology so becoming part of our ecosystem is a major goal for them, not a temporary effect of his own strategy.

The irruption of these smaller companies is also good news for corporations. It is easier for them to build a commercial and development channel laying in companies that participates in the development of the technology they use. Since software is getting more and more important, every helpful hand is welcome.

So it is easy to end up thinking about how good it would be to increase the number of smaller companies involved in our free software projects.

Grow locally

In parallel to this, KDE, and other community projects, are increasing their efforts of reaching potential contributions and users in their own language, taking in consideration the local culture. Some community projects are getting so big that some actions in the management/organization side must be taken to keep being efficient and flexible.

Like others, KDE is going through a process of organizing local communities around legal entities related with the matrix. The experience is telling us that some advantages and positive effects are taking place as a result of reducing the barriers for people to get involved in the project. There are many, but language and culture are huge ones. Another one that is not frequently mentioned is that people wants to relate to each other face to face, at least once in a while. National events, like Akademy-es, represent a definitive step for a developer to end up contributing actively to the global project.

Like in economy, the communities are built around poles that get connected to each other. If some developers are in the same geographical area, personal relations allow a pole to grow faster and stronger. We have a very good example of this process in Spain with Barcelona or in France with Toulouse. Also this helps to explain why we haven't been able yet to become in the US as successful as in other parts of the world.

It is easy to think how would it would be to speed up this process since the results look promising.

Non-profits as key partners

Every mature free software project have relation with some stakeholders that, eve though are not communities of developers, they are key players: non-profit organizations. These relations are not structured and too often have lay on personal efforts. Free software communities are very technology centric and most of those non-profit don't, so relations are not based on personal interest most of the time, but in the defense of free software (general idea).

But both, those non-profits and free software projects, are aware of how important is to stay close to each other, specially with so many viruses out there waiting to infect us.

But beside those non-profits that are very related directly on indirectly with free software,there are many more that we can contacted to build a very valuable relation. International cooperation or science centered organizations are among them.

So once again, it is easy to end up thinking how good it would be to increase the number and intensity of our relations with non-profit organizations.

Colleges: strategic partners

Most of the new contributors free software project attract are students from colleges. They have the time and energy to learn. Projects like KDE are perfect for them to develop new skills, useful in their professional careers. Only in very few companies a student can become part of such a complex environment, using such innovative tools, surrounded by high skilled people.....for free (not even paying, probably).

Teachers play a key role for us. Experience tell us that, where there is a teacher involve in our project, many new contributors arrive. Colleges are usually involve with local companies and somehow influence in the decisions they take related to technology. In order to create poles, they are the perfect host.

Every free software project have relations with colleges, but most of those relations are also based on personal relations between community members and some teachers. Maybe the same person plays both roles.

So, yes, again, it is easy to end up thinking how good it would be to increase our relation with colleges around the world.

Building a new ecosystem 

In order to ensure our independence in the future, keep growing and increasing our impact, we will need to find out ways to establish structured relations with these 3 type of organizations:

• smaller companies (SME from now on)
• non-profits
• colleges (including similar institutions).

Some of the principles and procedures we are using now successfully in our relations with developers from our own projects and other communities might not work perfectly with these organizations. They talk different languages and we will need to find ways to create a new field with different rules, so they they join our game, a game based in our classical strong principles.

If we agree that engaging developers is easier if you have a strong local structure, it make sense to think that maybe the same aproach can work with organizations.

This new ecosystem, within our community, will be the result of going through a new process that will have, at least, three different phases:

1. Creating a structured and coordinated program (the rules).
2. Building up a network with those organizations (the field).
3. Evolving into an ecosystem (the game).

We have to be aware of the difference between an ecosystem and a community. It seems to me it will be a basic element to consider. 

All the above is quiet obvious and, like in KDE, almost every free software project has been taking steps toward this direction. The recent MeeGo/Tizen affaire has made the need to push forward these kind of actions even more obvious.

How do we design that structured and coordinated program? How do we make it compatible with our goals? It will be possible with our limited resources? What do we want from these organizations? What can we offer to them? How do we make such a program sustainable? How do we handle our differences? Is such a new ecosystem going to affect us? How? Are we prepared?

I'll write about some ideas I have in the following days related with the above questions.