Software events in Málaga

In May, there has been two interesting conferences in Málaga that  I have attended to:

J On The Beach

Since I moved back to Málaga, I have been trying to attend to this conference and for one reason or another, I couldn’t, until this 2018 edition. J On The Beach is the most international software event that takes place in the south of Spain on regular basis and this year it was no exception. It is a very well organised event, with good speakers, up to date topics and participants from many different countries. The conference is in English.

My expectations were high and the event met them. I had the chance to listen for the very first time to M. Hashimoto, that provided the audience an overview of Terraform. It is always a pleasure to listen to those who create the code you use. In that regard, he is becoming very popular for tools like Vagrant or Terraform itself. I enjoyed the talk very much as I did with the talks from  H. Karau and J. Amstrong. By the way, M. Hashimoto will be speaking at OSSJ 2018 in a few days so I will have the chance to see him again, but this time in Tokyo.

J On The Beach is a 3 days long event where the first one is focused in workshops and training sessions while the other two are mostly talks. After the closure a party is organised with good music and plenty of drinks.

I recommend to my readers to pay attention to next year edition. Add this event to your list. Tickets are sold fast so subscribe and pay attention to the newsletter to find out when can you get one.

OpenSouthCode

OpenSouthCode is a general purpose FOSS event, very popular among students and local hackers. Last year I talked about the FOSS automotive platforms developed by AGL and GENIVI. This year I provided an overview of CIP, the work that we are currently doing and near future plans. Check the slides for more information.

OpenSouthCode in a two days event. The first one, on a Friday, is all about workshops, meetup and training activities while the second one, on a Saturday, is reserved for talks in Spanish.

If you live in the South of Spain or happen to be around when this event takes place, I totally recommend it.

Coming Events to Málaga

There are two additional software events in Málaga to pay attention to:

Gamepolis

There are more and more international software companies coming to Málaga and several of them are gaming companies,. There are also a few Spanish ones. If you are into games development or you are a avid gamer, this will be a great event for you.

PyConES 2018

Codethink sponsored PyConES 2017 and several of my colleagues attended together with me. One of them, Pedro Álvarez was part of the organization. It took place in Cáceres, Extremadura. This edition will take place in Málaga. I plan to attend again. This is a 400 people event packed of Python developers.

Further notes

I would like to see more international FOSS events coming to Málaga. It is a great place to organise a conference: it has a big airport with connections to all major hubs in Europe, direct flights to many European cities, fast train to both, Madrid and Barcelona, many accommodations from a wide range of prices and quality, a big congress palace and hotels to host events, good weather most of the year, the beach, Granada, Ronda, Antequera or Sevilla are close enough… and an increasing number of software companies opening offices in the area. It is nice to not having to travel to attend to a good conference once in a while.

Embrace Open Source culture: the 5 common transformations.

Article originally published at Linkedin on May 15th 2016.

This is a story of what I have lived or witnessed a few times so far. A story of an organization that used to consume, develop and ship proprietary software for many years. At some point in time, management took the decision of using Open Source. Like in most cases, the decision was forced by its customers, providers, competitors… and by numbers.

A painful but unavoidable transformation was required.

1.- Open Source consumer

Engineers had to learn a new system, adapt or re-write those features that used to made the organization unique, together with many other painful actions. It was expensive at the beginning but, due to the cost reduction in licenses and the change that Linux represented in the relation with providers, in a few years it was clearly worth it. And if it wasn’t, it didn’t matter since it was what the market demanded. There was no way back

Every software organization has gone through their unique journey, but the final sentence of the story has been the same for all of them: they became Open Source consumers.

2.- Open Source producer

This organization gained control over its production and, by consuming Open Source, it could focus many resources in differentiation, without changing the structure, development and delivery processes. At some point, it was shipping products that involved a significant percentage of generic software taken “from internet”.

It became an Open Source producer.

You can recognise such organizations because they frequently create a specific group, usually linked to R&D, in change of bringing all the innovation that is happening “in the Open Source community” into the organization.

Little by little this organisation realised that giving fast and satisfactory answers to their customer demands became more and more expensive. They got stuck in what rapidly became an old kernel or tool chain version…. Bringing innovation from “the community” required back-porting, solving complex integration issues, incompatibilities with what your provider brings, what your customer wants.

So they have to upgrade.

This organization will be able now to take advantage of all the common features and compatibility that the new kernel, the new tool chain… brings. But, guess what, forward porting all the differentiation features this organization has developed, all the bug fixes, is so much work and so complicated that the challenge put the organization at risk.

3.- Open Source contributors

The organization feels now the downsides of becoming a blind Open Source consumer and producer. Execs feels like when a bubble explodes and they are inside of it. They has less control than they thought, which turns out to be expensive, and what is worse, they lack the expertise within the organization to gain it….

But, after struggling for some time, this organization survived, which means that it has learned some lessons:

  • Upstream those features that are not differentiation factors any more.
  • Increase the investment in that reduced groups of rock-stars that are up to date of what’s going on “in the different communities”.
  • Invest in those Open Source projects that develop the key software you consume.
  • Even better, start your own Open Source project to promote your technologies and be perceived as a leader…
  • Reduce the upgrade cycle, so the “upgrade pain” is lower. As a side effect, the organization has the opportunity to increase the cash flow when doing two smaller upgrades instead of a big one. At the very end, the real profit comes with the first update, not with the new version, right?

This organization ended up upstreaming features when they could, normally very late, because “they do not have time”, frequently assigning that task to young inexperienced developers or, even “better”, subcontracting it, which is “cheaper”.

You can recognise that this organization has gone through the described process when attending to conferences given by any of its executives. They cannot stop talking about how much they contribute to this and that community, about how awesome the community is, how important it is to be open and share…. they are referring all the time to communities/upstream as “us” and “them”. They think they got it, they really do.

Most of them believe they are in the crest of the wave after going through this third transformation process. They are innovative, they has been able to reduce their time to market, they are gaining reputation within a variety of communities… They are not just Open Source consumers and producers any more. They are also contributors. Some of them even heavy and “successful” contributors.

But if you look closer, they have not adopted “the Open Source way”.

This organization keeps their traditional processes intact. It is managed in the same way. Decision processes are taken like when it was a proprietary company, it has not improved transparency significantly, it does not share code and practices among departments…. there is a totally different reality in front and behind its firewall, between production and R&D, between management, engineering, customer support, etc..

This organization face friction because of this reality. It still cannot move fast enough. Upgrading is still too expensive since now they have to do it more often than years ago, upstreaming goes so slow, when it happens. They cannot control the communities they are investing on…

So going through a forth transformation becomes unavoidable. Some refer to this transformation as “upstream first”.

4.- Upstream first or becoming a good Open Source citizen

This fourth transformation basically means that upstreaming is part of your development process, not an aside task. It also means that communities are part of your delivery strategy, not an after market topic, that R&D is a two way road where you do not just consume innovation created by others but you share yours, not just “promote it”. You really need to get involved.

This organization will learn that by becoming more open, their engineers learn more and faster, so the organization itself. It is at this stage where the organization really understand where the real value is in the software they produce compared to what is commodity…or that is what its executives and managers most likely believe, once again. 🙂

But open source (no capital letters any more) is not about being open, but about being transparent, which means that is not just about seeing what is behind the glass, but also understand it.

I believe the fictional organization I am talking about will have to take one more step, the fifth one. It will be about “becoming upstream”.

5.- Becoming upstream or being an open source organization

This is about understanding that, if you consume, produce and contribute Open Source, the smart thing to do is becoming an open source company. I think it is naive to pretend taking full advantage of  Open Source while keeping your traditional corporate culture, which collides with the one of those who produces most of the software you consume and ship, who are your “upstream”. You are building your business on top of them. Since you cannot control them, become “them”.

The smart thing to do is to surf the wave, not fight against it, generating friction. Any manager knows that friction is expensive, reduces focus and drives away talent.  It is bad for the business.

The required culture change to succeed in this fifth transformation involves thinking less about us (company and customers) and them (community), and more about us (ecosystem). It can’t be any more about upstream and downstream but about technology and service. It has to be less about upgrading and more about updating, less about “manage” and more about “lead” at every level of the organization, not just referred to execs and managers.

It is a transformation in which engineers are empowered, where management is more focused on collecting information for execs instead of producing it, and after decisions are taken, their key focus is alignment. A transformation in which execs get closer to where the real value is, to people, because they are the “masters”. A transformation in which engineers not just follow, they get exposed, they take responsibility and assume the consequences… getting paid for it.

An environment in which accessing to key information does not depend on your position within the organization chart, which means that power does not depend so much  on what others ignore, but decisions are taken based on shared knowledge. A culture in which transparency is the norm not the exception.

In summary, a transformation that leads to a stage in which the organization steers its ecosystem instead of driving it. So it leads it in a sustainable way.

A quimera?

I understand it might sound like a quimera, but:
  1. No more than it would have sounded 15 years ago any of the stories that so many CEOs or Open Source Program managers from leading corporations are telling nowadays in popular FOSS events about “their transformation”.
  2. I do not think the debate is if this fifth transformation will be needed, but about when and how to go through it.
  3. My +10 years of experience in Open Source and +17 as manager tells me that, waiting to face any of the first four transformation processes until you have no choice is an unnecessary risk. I suspect the same will apply to the fifth one.
So my message is,
  1. Consume, produce and contribute to open source being a good citizen.
  2. Embrace Open Source culture… better sooner than later.

 

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.

Sponsored vs supported

Probably the most relevant non technical action that a community executes is events. Most mature communities organize one or several big events in different part of the world with different goals, but one of them is common in every single case: engagement needs face to face relations. We are humans….after all.

In order to organize these events, sooner or later you need a legal organization that provides financial support to these actions. You might not know that, in words of the founders, this was the main reason behind the foundation of KDE e.V. .

And when you want to bring contributors together, most organizations end up having as goal to financially support some of them since they cannot afford it:
  • The trip is expensive since they come from the other side of the world.
  • They come from countries where the cost of the trip or accommodation represent the salary of a year.
  • They are students, so they have little income.
  • They have family and they cannot afford the expenses derived from being a week far from home.
There are many more use cases.
So one way or the other, most organization that support FLOSS communities dedicate resources for supporting contributors to attend to its main event(s). But if we look closer, there are small differences among different organizations.

Some differences among organizations.

Since resources are limited, organizations try to make sure they support those who have made significant contributions to the project throughout the year. Being supported/sponsored though, have frequently attached an expectation of being heavily involved in the event itself. Giving a talk or helping the organizers are the more obvious expected actions.

The difference comes when making these variables a plus or a requirement for being sponsored.

The process for being sponsored is also different. The tools used to manage the request/reimbursement process and the “amount of support” too. I will not get into those.
There is a “motivational” difference that do not have much impact but that I have always found interesting. Some organizations support their contributors “as a reward” and some do it “as a duty“.

The first case means that some kind of “thank you” is expected/required, linked to that support, as usual when you receive a prize. This act of gratitude might come in different forms but usually tend to publicly reflect that support. The basic idea behind it is to justify the investment in order to increase the level of sponsorship the organization gets from donors. It is a very popular approach in other industries/areas and there are a good number of FLOSS organizations that follow this model.

The other approach, the “support as duty“, is based on the principle that if you have made a significant contribution, that is, you are part of the community, and since the organization is there to support the community , it is its duty to support you. So the support comes with no recognition as requirement.  No “public thank you” is expected.

Some refer to this as the difference between being sponsored versus being supported.
My view on this last topic

In different countries/cultures, the sense and consequences of “thank you” are different. Also, the reasons that can “invite” you to ask for support might not be fun to talk, or being being questioned about. You might not feel comfortable by being identify as “sponsored“. It also might generate some undesired debate about who is being sponsored or why among people that do not have all the information.

Over the years I have changed my mind. Lately I identify myself more with the second approach, which do not mean I am against the first one. It has a point too.

In any case, what matters is that FLOSS organizations has supporting contributors to attend to the community event as one of their main goals.

A request

If you are not very familiar with how Free Software is developed, all this might sound strange. Investing money in paying trips and accommodation to go to an event to have fun with no or very little deliverables in return?

When thinking about donating to a community project or sponsoring it, ask for this particular topic to the Board of the organization behind it or the coordinators of the travel support program. You will be surprised by how important is this topic for them. They will provide reasons that, I am sure, will satisfy you.

For me, and many others, is one of the main reasons why these organizations deserve to be sponsored. Face to face meetings are essential to build a healthy community or ecosystem and many people have no way to attend if third parties do not sponsor/support them.