Moving from a traditional product/release focused delivery model to a rolling model

The past few weeks the GDP delivery team together with some key contributors, has been working on a not very visible but still important change. The GDP project has put the basis to turn GDP release based delivery model to a "rolling" one. My colleagues will provide in a coming post the technical details behind this change. I want to provide a higher level view of what is happening and why.

Some background

GDP was born as a "demo" project. The main goal was to provide a platform to show the software components for automotive that the different GENIVI Expert Groups were developing. This was done through a delivery model focused on publishing a stable and easy to consume version of the project every few months, a major release.

Strictly speaking, GDP is a derivative. It is based on poky and uses Yocto tools to "create" the Linux based platform, adding the different components developed by the GENIVI Alliance together with upstream software. For the defined purpose, the release centric model works fine, especially if you concentrate your effort is very specific areas of the software stack with a small number of dependencies on the other areas, and a limited number of contributions and environments where the system should work.

During this 2016, the GDP has grown significantly. We have more software, more contributors, more components and more target boards to take care of. Although the above model has not been not challenged yet, it was just a matter of time.

As I explained in two previous posts [1][2], the GDP is moving from a being a Demo to a Development Platform. Changing the mission means changing the goals and the target group, which implies the need to adjust the deliverable to meet the new expectations.

So, right after the 14th AMM, the Delivery Team decided to change the delivery model to better meet the new mission, providing developers the newest possible software with the an increasing quality threshold. At the same time, in order to increase the number of contributors, the GDP needs to provide a new solid platform every once in a while. That should be done trough a solid release.

What is a rolling delivery model?

The key idea behind a modern delivery release model is to ensure that the transition from one stable release to the next one takes an affordable effort. I will put an example to picture the idea.

Problem statement

Imagine an organization that publishes one release per year. Let's assume that a particular release included 100 patches developed by employees and, during the lifetime of the release (1 year too), another 100 patches were added to the product as bug fixes and updates. At the end of the release lifetime, the product includes 200 patches that define the value the product provides to customers and users.

Either for technical or business reasons, a year later it is time to upgrade. Our organization has to create a new Linux based system with newer upstream code and they have to integrate the patches from the previous release plus the updates and bug fixes developed for the coming release.

After a simplification process done by engineers, the number of patches needed to be integrated in this newer base system is reduced to 150. The organization also wants to add to this new release another 100 patches that represent the new features they have been developing during the last year for this new version.

The delivery team now has to integrate 250 patches in the new base system, 150 of them coming from the previous release. One might think that the effort required to do this is 2.5 times the effort invested in the previous release. Maybe you think that the effort is not so high since some of the patches have been developed thinking about the new base system. There are many other considerations like this one that might affect the initial estimation. This example is obviously a simplification.

However any experienced release manager will tell you that moving patches integrated in an older system base onto a newer one (forward-porting) requires additional effort, beyond a linear relation with the number of patches. Forward-porting is the "road of hell". Iterate this example a few times and you will understand why there are so many organizations out there that have as many people focusing on delivery as they have in development. They migrated to Linux base system keeping the traditional delivery model they had while working with closed source software.

Possible solutions

One of the paths to improve the situation is upstreamming those changes that affect generic components. Some companies also upstream their new features early in their development process, generally looking for wider testing, or after they have been released to customers, to increase adoption and reduce future maintenance effort. This is definetly a must do.

From the delivery perspective, the most popular way to tackle the problem though is reducing the release cycle, so the number of patches to forward-port in each release is smaller. The development time and the maintenance cycles are also smaller. The same applies to the complexity of the forward-porting activities. "Jumping" from one release to the next one is easier to do. Add automation of repetitive tasks to this recipe and you feel you have a win.... for some time.

The journey through the "road to hell" becomes more comfortable, but our organization is still getting burned, even in the case that our customers and ourselves can digest releasing frequently. We all know how expensive and stressful a release might become.

The most suitable option to achieve sustainability while scaling up the amount of software an organization can manage without releasing more often than your market can digest is to change your delivery model.

Rolling delivery models are a serious attempt to solve this problem, putting integration as the central element instead of the software itself.

This model is not new. Gentoo has been doing it forever, but it was Arch Linux who implemented it in a way that immediately attracted the attention of thousands of developers. Still it was a model with no hope beyond hardcore Linux developers. openSUSE brought this model to a new level by implementing a process which output was stable enough for a much wider audience, and compatible with the release of a more stable and a commercial releases. Nowadays there are other interesting examples out there that commercial organizations can learn from.

What is a rolling model?

It is still hard to define but essentially it is a process in which ideally you have one continuous integration pipeline as the one an only entry point for the software you plan to ship. Releases then become snapshots of all or part of the software already integrated after going through a specific stabilization, deployment and release process.

So ideally, if you release a portfolio, you integrate only once, reducing significantly the costs of having different engineers working on different versions of the same software and forward-porting, among other benefits.

So a rolling delivery model is a lot more than a continuous integration chain, although that is the key point.

Please have in mind that this is an oversimplification. This description doesn't go into detail on other key aspects like maintenance cycles, how upstreamming affects the process, strategies towards updating the released products, etc.

A transformation process that takes an organization from a release centric model to a rolling one is about doing less and doing it faster, so less people can handle more software with less pain, allowing more people to concentrate in creating value, developing new and better software instead of just shipping it.

Back to GENIVI

Moving from a release centric to a rolling model is hard work. Frequently it is easier to start all over again. Since the GDP is still a relatively small project, we can afford going through the transformation process step by step.

The first stage has been creating that single integration chain and treating GDP-ivi9, our latest release, and those that follow it, as a deliverable of what we call today Master. Ideally, no single patch will be added directly to the release branches. They should come from Master. That way, we reduce (ideally to zero) the effort of forward-porting of patches while putting in the hands of our contributors the latest software on a regular basis.

To do so, we are in the process of adapting our simple processes and CI system to the new model, GDP repository structure, the wiki contents, the task management structures, several key policies, our communication around the project...

The GDP will face a very interesting challenge since this model needs to be proven successful for a derivative. If we are able to move fast enough, it will come the time in which we will need to decide if GDP keeps being a derivative or it becomes upstream, that is, either GDP limits the delivery speed based on the Poky release cycle, or we work upstream with the Yocto project to increase our delivery speed.

That is a good problem to have, isn't it?

If (almost) everything goes right, after adding a few needed services in GENIVI's infrastructure and ensuring the updated software is in compliance with selected verification criteria, the same number of people will be able to manage and deliver more software. And once the new processes become more stable, automation will not just increase efficiency, it will boost the project by allowing GENIVI to achieve goals that only big organizations with large delivery teams can do. This is the kind of transformation that takes time to consolidate, but has a huge impact.

Based on my experience, I believe that if GENIVI is able to sustain this effort and keep a clear direction the next couple of years, the benefits of moving towards a rolling model will be noticeable even outside the industry.

This blog post was originally published in the GENIVI blog site on 2016/07/04. I have adapted the formatting to adapt it to Blogger. The content should be the same.

Say Hi! to the new GENIVI Development Platform

On Wednesday February 17th, the GENIVI Alliance released a QEMU image of the GENIVI Demo Platform ivi9 Beta version, together with everything needed (instructions, source code, recepies, etc.) to build GDP-ivi9 with Yocto. A few weeks later, on March 8th, the first release candidate was published.

Finally, last April 19th GDP-ivi9 was published targeting QEMU, Renesas Porter and RPi2. Check the release announcement and download the different images and source code from the GDP download page.

I joined the GDP project in November 2015, leading a small team of developers from Codethink with the idea of moving GDP from a demo platform towards a collaboration platform. In summary, going from +r-- to +rwx. 

What was GDP?

GENIVI Demo Platform was the compilation of middleware components developed by GENIVI integrated with Yocto or Baserock, based on poky, designed to showcase and test the work done by GENIVI's Expert Groups.

What is GENIVI Development Platform?

At GENIVI's 14th All Members Meeting (AMM) is was announced that GDP would change his name, from Demo Platform to Development Platform, reflecting the new spirit that has arisen during the delivery of the  GDP-ivi9 version.

The general idea will be to mature those GENIVI's modules that were developed as proof of concepts (PoC) and provide up to date software together with a SDK, to attract developers to participate as contributors, having GDP as their number one Open Source platform for automotive.

Find further information about GENIVI Development Platform at GENIVI's public wiki, in the GDP project pages. The name change, recently announced will be reflected in the wiki in the coming weeks. 

Coming actions

During the coming weeks, the GDP delivery team will focus on the following topics:

• Migration from the current infrastructure to Github.
• Confluence will remain as the project wiki and JIRA as the ticketing system. The same applies for the rest of GENIVI.
• Add to our current targets another board: Intel Minnowboard
• Define together with the GDP community the roadmap for the next GDP version.
• Create a first alpha of the new version including the latest GENIVI software.

Feel free to propose enhancements or new features to GDP. The only thing you have to do is create a subtask under the ticket GDP-154, describe it and explain the benefits and potential risks/challenges. We will discuss them through the mailing list. I am looking forward of seeing Plasma 5 as part of GDP.

GENIVI 14th AMM and other events to promote GDP.

After te release of the new version, GDP maintainers and myself have been concentrated in making sure GDP was ready for  GENIVI's 14th All Members Meeting (AMM), that took place in Paris from April 25th to 29th.

I participated as speaker in 3 sessions and my colleagues at Codethink delivered a couple of Hands on Sessions about GDE-ivi9. It has been a lot of work but a good finish line for this release cycle. We will publish the slides the coming days.

A few weeks earlier I presented the GDP project at the Embedded Linux Conference (ELC), that took place in San Diego from April 4th to 6th. It was my first time at this conference and I enjoyed it. I also participated at the Collaboration Summit, invited by AGL and the Linux Foundation. I will provide some more details about these events in a later post.

I plan to attend to QtCon to promote GDP among Qt/KDE developers and to the Automotive Linux Summit, that will take place in Japan, to spread the word about this open project for automotive. I have also confirmed my presence in June 2nd at the OpenExpo, in Madrid. It will be my first event in Spain in quite some time.

Summary

It has been a very busy 6 months but very productive. Leading a small but promising Open Source project, that might have a big influence within automotive in the future, working together with my colleagues at Codethink and GDP community members, has been very interesting. I am learning a lot about this industry...by doing.  

Virtue of Necessity. Canary, sublime your company.

The past July 16th I participated in the Tenerife LAN Party, in its section Tenerife Innova, invited by the Free Software Office of La Laguna University, included in the track titled (free translation from Spanish) Open Source from the Canary Islands, stories told in First Person.

This Free Software Office is well known in Spain for managing the biggest KDE deployment in Spain with 3k computers spread in several computer labs, laboratories and libraries, among other internal projects.

My talk (20 min) had as title something like: Virtue of Necessity. Canary, sublime your company. You can find the slides (in Spanish) in my site or in my Slideshare account.

What was the talk about?

The natural growth path for a software company is creating a site, grow until it reaches a point in which, a second production site is needed. Meanwhile, departments like sales and technical support might grow distributed. As the company grows, the number of production sites grow  with it. The organization structure vary with the nature of the company, sometime production teams are replicated across different sites, sometimes different business units are divided per site and others a particular site host teams that take care of different products-(micro)services.

In general, if the company follows an "agile" approach, it will try to reduce the inter-sites communication needs by placing the team members together in a particular site. Based on my experience and how FOSS has been developed, depending on the market you are playing, turning your company into a distributed environment might be a smart move. 

Let's start providing some context and definitions.

What do I mean by sublimation in this context?

Sublimation is a state change in which a substance transit from the solid state to the gas state without going through the liquid one.

What do I mean by a distributed environment?

In most agile literature, in fact in most software development management books, distributed environments are multi-site distribution. But in Open Source, we refer to a different environment. I have came out with the following (subjective) definition:

A distributed environment/organization:

• Has no site with a significant number of employees (developers). Most of them work remotely.
• Access most (if not all) corporate application though web, not through VPN, that is, are WAN environments, not LAN.
• Uses chat-IRC (or equivalent) and video conferences as the default synchronous communication channel.
• Employees spread across several time zones.
• Multicultural environment, having English as the default language.
• Organize regular face to face sprints (as we understand it in FOSS=hackathons), maybe even a corporate event where the whole company or business unit get together.

Open Source as distributed environment

Free/Open Source Software has a geographically distributed nature. As you know, most of the relevant communities, no matter which size are we talking about, are formed by developers located in many different countries, working from home or a company site. If we take a look at the most relevant ones, they are truly global. Every tool, every process, has been designed (intentionally or not) having in mind this distributed nature.

Now that Open Source is everywhere, more and more companies are embracing it, participating on its development, collaborating in global communities. from the process perspective, they are being influenced by the Open Source way, including its distributed nature.

Many of the companies that are embracing Open Source are understanding that adapting to this new environment makes collaboration easier. It reduces the friction between community and internal processes. There is a long way to go but I believe it is unstoppable for a variety of reasons (out of the scope of the talk). We are starting to see more and more organization that are fully distributed and start-ups that are born with such structure in mind.

Canary Islands, a fragmented market.

The Canary Islands is a group of 7 islands in the Atlantic sea, with two major ones (900k people each) and 5 smaller, for a total of 2.1 million people and 11 million tourists per year. Obviously tourism is the main industry, so there are 6 international airports, two national ones and 10 harbours, half of which regularly receive big ships/cruises.

Data connectivity has improved a lot the last 10 years but, due to the difficult geography, it is unequally distributed across the islands. Even within the main islands, Tenerife and Gran Canaria, there is a significant percentage of surface with zero internet coverage.

So it is a very fragmented market and, although with first class communication infrastructure, travel across the islands takes a significant amount of time, it is expensive and connectivity might be a challenge. In general, the transportation strategy has been designed to bring people from Europe not for internal mobility.

This means that, as a software company, consolidation/growth in such market is tough, very tough, even if you focus on tourism.

Software companies there expand following the "natural" approach, which is by creating a software production centre in one of the main islands, providing support from there to the other islands. Until you consolidate your position, software companies cannot afford to have developers/technical support in the second main island. If service/support is required in one of the small islands, you simply travel there. The limitations that software companies has to face due to the market conditions, rarely allow you to create a second software development centre in the Canary Islands.

There are very few Spanish cities with daily direct planes from/to Canary Islands throughout the year. Madrid and Barcelona are the biggest markets but also the most expensive cities. The flight takes 2:30 hours to Madrid and 3 hours to Barcelona, which is a lot for European standards. So opening a second development centre in the mainland keeping the headquarters in the Canary Islands is a real challenge.

In other words, if you want to scale your business, you need to assume bigger risks than companies based in the continent, despite being a cheaper place and having plenty of professional due to the existence of two Universities.

... but,

In my talk I tried to show that all those limitations can be turned into advantages if organizations, early in their consolidation process, or even from the very beginning, adopt a distributed approach. These constrains offer a first class laboratory to experiment with some of the key variables that need to be managed when scaling up your company, while leaving aside some of the most complicated ones, related to great extend with the internationalization of the organization.

I made a call to sublimate your company, going from an "on-site" to a fully distributed state, ignoring the multi-site state. Even better, create your software company as a distributed environment since the very beginning.

Why sublimating your company in the Canary Islands?

I summarized the advantages of sublimating your company if you are based in the Canary Islands, Spain, in the following statements:

• Distributed environments adapt better to the Canary Islands environment.
• It will prepare you earlier for the internationalization phase, keeping a smaller size.
• Distributed environments adapt well to certain business models and support needs, that are becoming popular nowadays.
• If your company want or is already heavily involved in Open Source communities, adapting your internal processes to those collaborative environment you participate on is easier.
• Talent attraction is less difficult.
• Some of your fixed costs turn into production costs, that is, you gain flexibility.

Which variables will be affected by subliming your company?

These are the most relevant variables to consider:

• Cost per employee: reduction of fixed costs per employee. Increase of travel costs.
• Organization chart: from vertical to horizontal
• Human Resources policies: training, coaching, people management. From f2f to online.
• Data privacy and security: adapt to a WAN environment.
• Tools: adapted to distributed with higher latency environments
• Schedule / availability: culture shift, from presence to availability
• Development and support methodologies: from f2f conversations to remote synchronous/asynchronous channels. From agile to FOSS? Is FOSS agile?. From 8-10 hours or rotation to a higher daily production/availability window.
• Costumers relation/engagement: from tradition account management to "community" engagement management. Engineers interface customers.
• Transportation and connectivity: employees need to be connected and travelling demands will increase. Accountability/reimbursement processes will be more complex.
• Business model: your business model might need to adapt to your new distributed nature.
• Potential market: the presence of employees in new areas and the fact that your processes are adapted to distributed environments might change your target market and/or nature/size of potential customers.
• Competitors: the influence of your new distributed nature might alter your positioning against competitors.

There are more but these ones are the ones that should be considered carefully before subliming your company in the Canary Islands. As you grow, internationalization will knock at your door very soon. There are other variables to consider in that case. They are not the scope of this talk:

• Time zones
• Multiculturalism
• Language barrier
• Retributions and incentives. Cost of living.
• Fiscal and employment legislation differences
• Travel and accommodation costs and reimbursements
• Accountability and taxes
• Many more...

Summary

The Canary Islands is a tougher market than the mainland of Spain. Adopting early in the software company life cycle a distributed nature allow you to adapt better and faster to this environment, preparing you better for later stages too, specially the internationalization phase. Sublimation provides you a competitive advantage, specially if you develop Open Source and participate in open collaborative environments.

There are a number of variables that should be carefully considered though. Managing them correctly is a requirement to succeed.

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.

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.

Building innovation nodes through Free Software Communities (VI): organization

Please consider reading previous post of the Building innovation nodes through Free Software Communities  series:

• Introduction.
• Root article (you can access the rest of the posts from this one).

This project must have a legal entity that support the activity it will generate. That legal entity must be as flexible as possible. In Spain, for example, it would probably be an Association formed initially by legalized Local Free Software Communities (LFSC). When new ones get a minimum state of maturity, they will be invited to join the association as members.

Each Association would name a representative for this project. The Association's Assembly then will be formed by representatives of every legal LFSC involved. They would elect a Board, that initially, it would be formed by a President, a Vice-president, a Treasurer and a Secretary.

This Association will represent the project from a legal, economic and "political" point of view. Its basic role is to coordinate efforts and to make the project sustainable, keeping the independence of every member.

The Assembly would organize itself in groups taking care of different tasks. Several groups should be created:

1. Activities coordination group: All the activities, schedule and organization details will be coordinated y this group. The schedule is should be presented to the Board for approval and every year, a report should be made to the General Assembly.
2. Sustainability group: this group will take care of the sustainability of the project, specially the economic side.
3. I recommend to organize another two groups. One specialized in promo actions and another one that help the Board in dealing with administrative tasks, taxes, etc.

Sponsors and local entities should be invited to join these working groups so they become part of the project building relations with Local Free Software Communities.

Building innovation nodes through Free Software Communities (V): services

Since this is the fifth post of the Building Innovation Nodes Through Free Software Communities, I strongly recommend you to read the previous four (I, II, III and IV)

This post will explain my ideas about what are the basic services that the initiative should provide so Local Free Software Communities (LFSC) and local player might organize activities that allow the project to be successful.

As enumerated in the second post of the series, the basic services that should be provided by the project to its members can be divided in six major areas:

1. Administrative.
2. Legal.
3. Financial and accounting.
4. Marketing and communication.
5. Business development.
6. Facilities maintenance and management.

The rest of the activities needed will be developed by participants, that is LFSC members, the catalyst organization or local players.

1.- Administrative

The administrative service can be divided in the following way:

1. Administrative services related with the project itself.
2. Administrative services targeting Local Free Software Communities.
3. All of the above.

1.1.- Administrative services related with the project itself

• Board support: as you can read in the Organization section, the project will be managed by a Board, elected from the Assembly. This Board will need administrative support.
• Contact/agenda management for project representatives.
• Accommodation management for activities organized within the project.

1.2.- Administrative services targeting Local Free Software Communities.
 

LFSC legalization: help LFSC that want to become part of the project in the near future with the basic administrative work in order for them to become a legal entity.

1.3.- Administrative services for both, the project and every LFSC participant

• Regular post management: notifications, legal papers and material shipment, this is, regular post service is one of those difficult area to manage when you are a distributed organization where board members chance quiet often.
• Membership management: the management of current and new members is a tedious task that every organization must put resources on. Having an administrative service can help them to become more efficient, specially to those where a each member has to make a yearly quota.

2.- Legal

The basic legal services needed are:

• Advice about basic legal aspects related with statutes and everyday decisions and operations for any LFSC and the project itself.
• Basic legal advice about licensing.
• Legalization of LFSC.
• Institutional agreements.
• Legal advice related with funding.

3.- Financial and accounting

This service should be given to the project itself and for every project member:

• Accounting support.
• Budget and economic reports. Costs control.
• Advice in financial decision and taxes.

4.- Marketing and communication

• LFSC and Project activities promotion in mainstream and social media.
• Project press releases and announcements.
• Local marketing actions support.

5.- Business development

Since the project will need to look for funds in order to grow, business development activities become a key part. The project will provide a service in this area that support participants the following areas:

• Relation with local agents/players.
• Sponsorship management support.

In another article I will talk about the resources needed to lauch the project and make it sustainable.

6.- Facilities maintenance and management
 

The facilities assigned to the project will be when the activities take place. The project will provide the following services:

• Facilities management.
• Security.
• Material manage, storage and control.
• Activities support.
• Connectivity.

and others needed to organize and support the activities defined by participants.

Building innovation nodes through Free Software Communities (IV): localization/facilities

Please keep in mind that this is the fourth of a series of post. Please read previous ones ( I, II and III) before the following.

The venue is very important in order to be successful. I suggest to launch the project in a city with the following characteristics:

• Big not not too much, so activities created have a global impact in the city. 
• With at least one big University with Computers Science and Engineering/Science Faculties. This will ensure potential contributors.
• Well communicated with bigger cities so activities organized can attract visitors from those cities.
• With an international airport so it is easy for the Global Free Software Communities (GFSC) to celebrate promotional and technical activities with foreign speakers and attendees.

The facilities are a key element in order to have success. Some of the most relevant characteristics that the venue must have are: 

• Close to the city center, well communicated with the airport or train station (if there is international airport) and close to the University if possible.
• Close to hotels, hostels or other accommodations. It is important to have cheap accommodation around the facilities.
• Some kind of garden or natural area where to talk comfortably outdoors.
• Cafeterias, bars and restaurants must be close to the facilities.
• Facilities must have, at least:
• A room for conferences up to 75 - 100 people.
• High quality Internet connection. Wifi in the area and outside.
• AC Plugs.
• A meeting room.
• A computer lab or a room prepared for plugging laptops.
• A networking area with some tables.
• Stock

To be successful, the place must have a comfortable atmosphere. It must be a quiet but informal. It must promote interaction but also intimacy. 

Go back to the description post.

Building innovation nodes through Free Software Communities (III): participants

This is the third post of this serie. Please read the first two (I and II) before reading this one.

A.- Participants

As mentioned in the previous post, the participants in a project like the one we are describing can be organized in three different groups:

1.- Source

There are the organizations which represent the innovation source, that is, Local Free Software Communities (LFSC from now on).

Mature Global Free Software Communities (GFSC) are organizing more and more local groups, specially in non-English speaking countries since people in general like to related to each other in their native language. But in most cases those local groups are not configured as legal entities. When they are, most of the times there is no legal relation with the matrix, at least, so they can operate as legal representatives of the GFSC in its country.

Due to law differences, in each country that relation implies different rights and duties, so there no single and simple way of building that relation. But is an achievable problem in most cases. In KDE we created a precedent with the agreement with KDE Spain (link). we are using this initiative as experiment in order to replicate it with more LFSC.

This project should have, as one of its major goals, to help local groups:

• To become legal entities, so they can grow and mature, by being able to relate to other organizations, not just its matrix.
• To develop activities that allow them to increase the number of local contributors and the software use by local players.

2.- Catalyst

The Catalyst is the organization that will put the initial effort to attract local communities to the project. Ideally, it'll will have the initial resources and the localization needed to launch the project. Its major initial goals will be:

• To coordinate the initial steps and prepare everything for the LFSCs to take command of the project when the Assembly is formed.
• To promote interactions and networking among LFSCs and between those and local agents.
• To do marketing with impact beyond Free Software media.

3.- Local agents

The initially act as receptors of the knowledge transfer generate in Free Software Communities. In a second step, little by little, will generate its own experience and knowledge to LFSC to end up providing them developers, experiences and (hopefully) code. Beside interacting with LFSC, Catalyst will promote interactions among them, so they can learn from each other's experience.

B.- An example: Spain

Local Free Software Communities

Mi idea is giving this project a try in a certain country. Let's say Spain. It would kick off in a certain big city and could be replicated to smaller ones. The initial LFSC candidates are:

• Debian-es
• KDE España
• GNOME Hispano
• OpenStreetMap España
• Joomla Spanish
• Drupal Hispano
• gvSIG

All of them are legal entities in Spain, regularly organize community events and have ten or more members. They are the perfect starters.

Some other local groups must be also involved in the early steps. They are LFSC groups that are not legal yet, but organize events and are active groups. The project should focus on helping them to become members of the project. By the end of the first year, the goal must be to add another 5-6 local groups to the project with the same rights and duties than founders. Distribution LoCo teams (Fedora, Ubuntu, OpenSuse, Gentoo, Guadalinex, Linex, CentOS, etc.), computer language related groups (Java Hispano, Rails-es, etc.), product oriented communities (Zentyal, LibreOffice-es, Plone-es, LibrePlan, etc.) and other ones like OSGEO-es, FSFe, Mozilla-es, etc. are perfect candidates for these second group.

Catalyst
 

In my mind, the perfect catalyst is a non-profit with many local contacts and visibility or a Public Administration (City Council or Municipality). Last November, I presented this idea to one City Council from a big Spanish City. Other options are being under study.

Local players/agents

The best players to involved at early stages of the project are those that have demonstrated in the past some relation and support to Free Software. The plan is to reduce the culture gap initially. My first candidates would be:

• Regional/national Association/Federation of Free Software SME.
• Local college (through its Free Software Office).
• R&D Institutes with Free Software related experience.

Building innovation nodes through Free Software Communities (II)

Please read the previous post about this topic to have a better idea of what I'm trying to explain here.

When thinking about how to create a local node in a certain area where all the knowledge from GFSC can be used to improve local economy and social rights I came to the conclusion that we need to define a model based on the following six general ideas:

1. Principles: some basic principles shared by all participants must be defined.
2. Participants: electing who is going to participate in the initiative and which role will have each one of them is another simple but relevant idea to determine.
3. Localization/facilities: the initiative needs a specific place, adapted to the kind of activities needed to achieved the goals.
4. Services and resources: participants will need to define services and look for the resources needed to launch and sustain the project.
5. Organization: governance model and structure are also key point to define. They must be adapted to promote an innovation environment.
6. Actions: activities that will be the core of the project.

1.- Principles

The actions that need to be taken must follow some principles shared by every GFSC, adding some important ones for local agents involved. These two groups of principles can be summarized in the following:

• Freedom, which includes economic and administrative freedom.
• Self management.
• Openness
• Integration.
• Free licenses.

2.-Participants

In order to be successful, I think the project must count on three major participants:

• Source: local Free Software Communities.
• Catalyst: organization that will promote interaction among players involved.
• Receptors: local organizations and individuals.

3.-Localization/facilities

Localization must be carefully chosen. I think that the perfect place must be located in a mid-size city, well communicated with bigger cities and an international airport. The facilities chosen must allow to celebrate talks, meetings and workshop, with a networking area. Accommodation and restaurants/cafeterias must be easily reachable.

To be successful, the place must have a comfortable atmosphere, quiet but informal, with areas that promote interaction and others intimacy. 

4.-Services and resources

In order to define a project to achieve our goals, some services will be needed. The basic ones are:

The project will need support in the following areas:

• Administrative
• Legal
• Financial and accounting.
• Marketing and communication.
• Business development.
• Facilities maintenance and management.

The resources needed to launch a project like this one, must come from:

• Sponsorship.
• Local public administrations and innovation agents.
• Local companies.
• Participants.
• Activities organized by participants.

5.- Organization

Innovation and complex organization structures are incompatible. The structure to manage the project must be simple and compatible with the culture from the communities involved. I think the perfect organization and structure comes from a mix of three different kind of well known organizations:

• Labs. There are many of them around the globe. In Spain we have two well known, one in Madrid and other one in Barcelona.
• Self-managed cultural centers. They are multidisciplinary legal entities, self-organized, usually linked to a certain building or infrastructure where many different kind of activities are promoted and organized.
• Business incubators.

The global idea is reducing administrative and legal work to the minimum, promoting meritocracy and electing the people that manage the project, creating forums where local agents directly interact with those organizers from the communities that participate in the initiative.

6.- Activities

The communities involved in the project will determine the type of activities to be organized. Obviously, in order to generate a local pole, an intense agenda a a key point. It should be full of community events, but also other kind of activities that promote interactions with local agents, like training sessions, workshops, etc.

Communities usually organize itinerant events. A project like his do not mean that local communities has to change this mechanism of "spreading the message". It is just a matter of creating several minor activities per year at this place.

In following posts I will explain a little how do I believe the above six point should be done/organized to be able to create a local pole of innovation through Free Software Communities.

Building innovation nodes through Free Software Communities

Global Free Software Communities (GFSC from now on) are a proof that Silicon Valley model is an industrial innovation and business model from past century. GFSC are building, not just great products, but creating new engineering procedures and tools, new ways of governance models, supporting and promoting new legal improvements in some areas, creating its own identity, its own culture and becoming politically active promoting freedom in the digital world.

Communities attract many young talents and professional by allowing them to grow personally, technically and professionally while developing software anyone can use. GFSC represent a mirror to some new movements and a relevant help to others.

Traditionally key stakeholders has seen GFSC as a R&D ecosystem and a hiring environments. Lately, we are facing a significant change. Smaller companies are getting more and more involved with a new purpose, to share the development of a technology or product to base their business upon. This is specially true in vertical (product oriented) communities, like Drupal or Joomla, for example.

We are also seeing some companies succeeding in building communities around their products, creating a new type of communities driven, but not owned, by them.

All this innovation is taking place through internet, starring geographically distributed teams who usually know each other if they collaborate in the same community but do not if they are members of different ones.

I believe that we have a good opportunity in the following years of creating impact in many places with what we do if we are able to create nodes where all that we do in communities can be translate it to local agents/actors so they can adapt our procedures, use our software, create their own, build a local business sector around the software, help other sectors grow, etc. and, at the same time, attract more contributors to our communities, give us very useful feedback and give us resources to increase our activity.

Different communities have done different actions in order to accomplish these goals. We have experiences from all over the world where Libre Software has been used/deployed/develop with a concrete purpose and certain measurable results. Big companies and Public Administrations has also develop many experiences. 

But overall, it seems to me that we haven't yet get the solution to spread our "innovation and culture" in a structured manner, so every community can repeat some basic processes to grow locally and get feedback from these initiatives. For several reasons, many people out there are using our software, but GFSC and the local agents are not properly connected so any of them are taking all the possible advantage. It is hard for us get benefit out of it to let our communities grow. Most of the time it is just a one way street...

GFSC want new contributors that allow us to build new code (and related activities) along with new power users to test and notify bugs and possible improvements. We use internet as the main communication channel and organize events all over the world to accomplish that goal. It takes an affordable amount of resources to execute those action and support the needed infrastructure that allow us to grow every year. But that growth is linear and have little impact in a localized area most of the time. I guess the strategy must be different if we want to create well established local nodes to generate a big impact. And spread them.

How can we move that distributed innovation done by GFSC to a certain geographic area? How an innovation node that helps local economy giving engineers, companies, etc. new chances can be created ? How can we do it in a way that GFSC get feedback? How do we replicated and spread them? Is it possible to do it by ourselves, with our own culture?

I'll write a couple of posts during the following days with some ideas I have related with this topic. These ideas are the fundamentals of a proposal sent to a City Council from Spain to try to create a local node of innovation related through Free Software Communities.

If you know an example of local groups of people that have done sustainable actions in a certain area resulting in increasing the number of contributors in a specific GFSC along with improving the local economy, promoting the creation of local companies, deploying new tools, bringing users to Free Software, etc. please add a link or write s brieft summary. I would like to know about it.

There are several more recent posts about this topic. Please chack them if you are interested: 

• Building innovation nodes through Free Software Communities (II) 

• Building innovation nodes through Free Software Communities (III): participants

Libre Software Communities and Universities: talk at La Laguna University

On September 19th I planned to give a talk in La Laguna College, Tenerife, Canary Islands. The idea was to promote involvement in Free Software Community projects, like KDE, among students and teachers.

Due to a problem on my trip to Tenerife from La Palma (my mom's car decided to stay in La Palma instead of taking the ship to Tenerife with me) I had to cancel the talk the day before.

Since I visiting my family for Christmas in the Canary Islands, I will be able to give the talk next Monday, December 19th, at 18:00 hours (local time), at the ETSIIT of La Laguna College. Once again, the Libre Software Office of La Laguna College organices it.

You can check the slides of this talk, which I also did in Malaga's college a few weeks ago.

Libre Software Communities and Universities

View more presentations from Agustin Benito Bethencourt

Link to the official announcement done by the ULL Free Software Office.

Remember that this college have about one thousand KDE desktops deployed in their computer labs for students. Their maintenance is done by the Free Software Office (ULL's OSL).

OpePyME (OpenSME) is the most relevant Free Software applications catalog for companies published in Spanish. It is also a OSL project. Their technicians receive the requests, test the applications, categorize and publish them in the catalaog. They also have a Linkedin group (OpenPyME) with almost 800 members to answer questions.

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.

Social networks... a new challenge and a new risk for software libre projects

More and more people is now using KDE 4, and specially non technical people. Since KDE4 is improving fast but do not have yet all the features and apps that KDE 3.5 did, it is easy to think that old KDE users will have many requests or questions the following monthes. Since the usability of KDE4 is new in many ways, there will be many users also asking for help.

I have a feeling that lately more and more people is complaining/making questions in identi.ca/twitter about features or non key points that they miss, don't like or, simply don't work as they expected.

The commitment of every KDE developer to answer as many questions or comments as they can is out of doubt, but this question-answer approach do not scale, since these tools do not work as chats, forums or mailing lists (the major tools we have used in the past for support purposes). They do not have a single entrance from where to route them to the right information or person. They need a new language, different procedures, different interfaces, different tools (social desktops ;) )....

I'm not sure the policies we had in the past for supporting users are going to be as efficient as they were. Probably a different strategy to handle all these requests and complains is needed for these social tools. From my point of view is becomming something to be worry about since the impact of so many people making requests or complaining about different issues are becomming significant and it can turn into relevant.

Software libre projects have a nice chance to change the way they interact with users. Social networks force people to become concise. We can use that. But they are also great tools for expressing feelings worldwide... and that is a huge risk if they get frustrated with our software.

How do we route requests and complains through social network tools? How do we track and proccess what they want, what they need? How do we make ourselves visible so they know where/who to ask? How are we going to coordinate efforts through these tools? How do we adapt other tools we use (wiki, bug tracker, mailing lists, chat) to this new scenario? How do we include social network tools into our support and maintenance strategy? Or their impact will be so big that those classic strategies won't work anymore?

Maybe we have to assume some risks and, once more, innovate....maybe this is nothing to worry about...

Who did make me believe?

There are different ways to end up in the software libre community. I used debian at college but I really perferred windows at that time. Once I was working, I got in touch with free software again. I began to use it and promote it. It took me two more years to really understand, then truly believe, in what I was doing. A simple action convinced me that it is not just a matter of software, bussiness, community or innovation, but a matter of justice. It was reading a book.

My own red pill (remember Matrix) was Lawrence Lessig's book "Free Culture" (Cultura Libre in spanish). It is a must, It's easy to read and easy to understand but deals with really deep concepts and feelings.

Lawrence Lessig is giving a talk in Vitoria, Spain, next month. I've wanted to write this post to thank him for changing my little world.

Lawrence, you lost the battle, but we will win the war. ;)

I'm alive after all

I've moved to Málaga two monthes ago for a year and I'm quiet happy about it. I came here to manage the first step of a project that will migrate 31 municipalities from a region called La Axarquía, which is close to Málaga.

After planning and scheduling the tasks, we are inventornig the computers and services these minucipalities have. I'm also surveying how public workers use the propietary apps they have installed so we can define the software libre tools we will install and the teaching project we will have to define in association with the migration process. We are also building up the team that will be working with us and explaining to politicians from these municipalities what we are trying to do. Nice job, isn't it?

We will present the first results in October probably. During june we will be working on a public wiki, so everybody can check and collaborate on what we are doing. The information will be mostly in spanish but we will translate what is relevant to english.

What a day for standard formats and free software...

Today 3 news has came along related with standars and free software that I hope it gives light to people in general and local politics here on the Canary Islands, Sapin, about what's going on:

1.- German Foreign minister, Frank-Walter Steinmeier, supports ODF.

2.- Open Document format (ODF) yesterday became an official standard for
South African government communications.

3.- Becta, the government's education technology agency, has today made a complaint to the Office of Fair Trading (OFT) for alleged anti-competitive practices by Microsoft in the schools software marketplace and in relation to Microsoft's approach to document interoperability.

...I want more days like today. By the way, thanks KDE for letting me become part of such an amazing project.