Codethink is sponsoring Akademy 2018 and I am attending.

Back in July 2017 I wrote a blog post, published by Codethink, explaining why is a good business to support community driven FOSS events. This post is related to that one.

akademyLogo4Dot

I will be attending to Akademy 2018. It will take place in Vienna, Austria, from August 11th to 17th. I will be there representing Codethink, which is a proud sponsor of this 2018 edition.

I attend regularly to Akademy since, as most of you know, I have been an active contributor, a user of the software, a supporter of some of their activities and/or a KDE e.V. member for some time now. I learn a lot during this event, and not just about KDE related topics.

This edition has several specific points of interest to me:

  • I am involved in a project called BuildStream, a FOSS integration tool for declarative systems and applications. Currently its main user are the GNOME integration team and the Freedesktop SDK project. We would like to expand our user base among communities like KDE.
  • Freedesktop SDK are a platform and a SDK runtimes for flatpak apps and runtimes based on freedesktop modules. Several colleagues of mine are behind this project that is about to release a new version.
  • A year ago, during an Akademy BoF, some KDE contributors decided we wanted to put some effort towards enabling KDE software on automotive. This year the first modest results will be presented to the wider KDE community. I have been preaching about this move for some time now so it is exciting for me to see others involved and making progress.
  • I will attend to the KDE e.V. Annual General Assembly. KDE e.V. is the orga34f05-logo_kdenization that supports the KDE community which is an important activity.
  • I will update my working laptop from openSUSE Leap 42.3 to Leap 15, taking advantage of the presence at the event of a couple of former colleagues from the extinct openSUSE Team at SUSE, and Slimbook, the guys I bought my laptop from. Make sense, right?
  • Codethink is always looking for talent willing to move to Manchester, UK, or exceptionally, work remotely. Come talk to me if you might be interested.

It will be, as usual, a great event. See you all there.

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

 Introduction

When the Agile Manifesto became popular and based on them, agile methodologies like Scrum, XP or Kanban, upstream development was in its early stages as collaboration ecosystems of companies.
Only a few for profit organizations embraced developing upstream back then. Most of them were small and heavily influenced by FLOSS engineers vision. Free software communities were basically driven on personal basis or the very lucky ones, together with “sponsored developers”. In general, these ecosystem were not part of companies strategies.
Today, more and more companies are getting fully involved in community projects as stakeholders, not just consumers or simple contributors.
They frequently start as consumers, then, little by little they become “upstreamers”, that is, they share/publish their code with the goal to have it merged (upstream code). Not without effort, many of them become successful contributors.  After some time, some of them end up understanding that is “cheaper” to play by the project rules. In summary, they learn to become good citizens.
A subgroup of the above companies end up including these collaboration ecosystems as part of their own strategies, going from contributors to  key stakeholders. A necessary step to achieve this goal is to work upstream.
Walking this path present many challenges. One of the toughest ones is related with the differences in development methodologies used internally (mostly agile) and those used in the collaboration ecosystems.
There are two fundamental variables that, in my opinion, determine this challenge:
  1. Environment
  2. Culture

Challenges

1.- Environment

There are two dependent variables that were not taken into account (or just partially) when the agile methodologies were defined, that are relevant in upstream development:
  1. Community projects are global environments, that is, contributors are located in different “offices”, frequently in different time zones.
  2. Probably due to the original amateur condition of early contributors, together with the “distributed condition”, the development processes (so the tools) in most mature community projects, consider, manage and tolerate high levels  of latency.  “Real time” is restricted to IRC discussions and events/conferences.
These two factors has made open source what it is today. They have been “success factors”.
Agile methodologies do not embrace “distribution” environments. The widely accepted recommendation is that teams should share a physical space. It is way more than a recommendation. It is somehow a requirement.
The second case, “latency”, is considered by agile methodologies as a waste. It is not tolerated.

2.- Culture

Free Software was born as a reaction to a system that promoted corporation interests over developers, so users. The agile movement was a reaction to those methodologies that put process first, not people. Hence, it is obvious that both movements share a lot: people first
This is reflected by some when saying that FLOSS development is agile.
In my opinion, there is a big difference between what agile methodologies and what Open Source development propose in terms of principles.
Agile methodologies promotes a strong team culture. Open Source was born “based on champions”. FLOSS culture normally applies the meritocracy concept to individuals.  Open Source projects are organized around contributors, around specialists, not around teams, as we understand them in corporate environments.
This is no surprise since Agile was born in companies/corporations and Open Source was born as a viral movement, grown “by aggregation“.

The conflict

In my opinion, the more the industry embrace open source, and as result, open collaboration, the higher the conflict developers and managers will face due to the above challenges.  Companies are becoming more distributed environments and are working more and more upstream, instead of simply being consumers or occasional contributors.
In consequence, it would not surprise me if we hear more and more about  “corporate development methodologies” (a.k.a. agile) vs. “upstream development methodologies” (a.k.a. FLOSS).
Scrum, XP, Kanban -ish fans will need to face those challenges and find solutions in order to succeed in open collaboration environments. In the same way, based on the increasing influence that companies are gaining in these ecosystems, FLOSS methodologies in a few years will differ from what we knew 10 years ago.

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

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

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

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

From the corporate world I frequently hear how hard it is to predict and track what upstream developers do. On the other side, developers that work part or full time  upstream frequently underestimate the need for communicating what they do in a way that enable others (or themselves) to provide deadlines and effort estimations. Upstream and product “time lines” and cultures often differ too much to be compatible under the same environment.
Developers that come from the “product” side of the story often refer to agile methodologies like Scrum as a good approach to solve this collision. It is unclear though the applicability of this and similar methodologies to highly distributed environments, where latency is high. Although most accept today that FLOSS development is agile, I find hard to assume that we are close to find good answers when it comes to development methodologies and upstream.
There are several different scenarios I have worked on where I have to question everything I knew up until then about this particular topic. In a couple of occasions, with a bigger or smaller community, the people I directly worked with were upstream. This allowed us to define up to a great extend the methodology we worked with.
In Linaro now this is the case for a particular project. But in general, in my Group we work upstream (in the Linux Kernel), that is, we cannot define the methodology since it comes defined by the project itself. It is not the first time I face this situation although I never did at this scale.
When you are upstream, the methodology used by the core team, together with how the project work packages and workloads are organised heavily influences the success in getting contributions from third parties. Together with other key variables, how you manage latency determines how many people can follow you and potentially contribute. In summary, the faster you move the harder it becomes for contributors to collaborate with you.
Hence agile methodologies come with a high risk: isolation. And this is obvious by just analyzing the prerequisites associated with the methodology itself.
Obviously this does not mean that scrum and other methodologies are not great ones. I am just pointing challenges associated with apply them when working in a community that you drive. You need to balance the efficiency of your team with the contributions you might potentially loose from externals.
The challenge is even bigger when you are just a participant in a community. In some way, your team goes beyond your colleagues at work. Latency is frequently too high to even consider yourself and the people that works close to you “a team” in the classical sense of the word.
If your own team is distributed, even if they are in the same time zone, then we are talking about the real deal, the master challenge for managers and developers. 
Imagine now that your team is formed by 10 people distributed in 6 different time zones in 3 different continents. Then you take one of those cool books that tries to explain how to create great software using this or that methodology and, in order for you to finish it, the writer must be a really good one or you really need to be an avid reader 🙂 
Still you need to make plans, to predict when a feature will be finished, when it will be merged, you still need to manage dependencies, expectations, budgets…. you still are tight to somebody else needs and requirements. You still need to fulfil expectations despite the fact your control over the environment is limited. You have team mates that depend on your work, that needs to know what you are doing and how…..  you are still part of a business no matter if you develop upstream or not.
How can you make compatible the upstream development processes used in the community you are contributing to with the way your company works? And how about your customers and partners, if you have direct relation with them? How can you take the good things that agile development propose and apply them to an environment with high latency, where one of your bigger challenges is to have an efficient team meeting, since people are distributed across the planet?
At Linaro, the engineering management team, together with our PMO, are taking a close look at this challenge, in order to iterate from our current system to a more efficient one, better adapted to our new reality, after our significant growth during the past 18 months. The idea is to find a place where corporate and community processes meet… without colliding. You cannot stop adapting, innovating, trying new things….. or you pay a high price.
One of the great things about Linaro is that we are a unique environment so we can innovate at various levels, not just at the technology one.

Open Sorce Forum at CebIT

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

Core Dump

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

Two risks when working as employee in Free Software communities

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

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

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

Spreading the energy through different areas, working under demand instead of having a clear control of your agenda, focusing on short term results instead of mid term ones, becoming a pillar for everybody else work in detriment of your own goals, of your own results, is a common syndrome I have suffered myself for a while, specially when working remotely from home, and I have experienced as manager of teams and projects.What makes the action of any team (or professional) significant in any environment, and particularly in a open ecosystem like a Free Software community, is their ability to maintain during a long period of time a sustained effort focusing its energy in a single point. Only when the plan is achieved or after a proper analysis, jumping to another one is the right thing to do (in normal conditions, obviously).

The effect is even bigger when those points of focus are linked, serving a mid/long term purpose, aligned in a concrete direction. Then the impact is multiplied by the alignment of other people around you.A key toward success is selecting targets with high impact, spreading its positive effect through the entire project. This multiplying effect requires a high amount of energy in early stages (activation energy).  The chances to create a significant and direct impact in several areas of any project at once are very low unless your team is big… and many not even then.

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

2.- Working in a Free Software community is one of the most rewarding experiences I have had in my life. I feel appreciated. My contributions counts. Many people is aware of them. I can work to make them more noticeable. The more popular my contributions become, the more people express me gratitude. The more relevant I become, the more people listen and interact with me…This process is a spiral that you can learn how to climb in an effective way after some years. We end up learning how to play the game.When you are a long term contributor and you are in charge of a key part of a project this is exactly what might happen. You arrive to the top of the pyramid, which is a comfortable zone. Too comfortable sometimes.

If internal and external balanced forces are not applied, like competition, an adequate professional environment, external pressure/challenges… even the best professional can become too pleasant.Reward can become a strong drug. It might elevate you in a bubble that, in the mid term, might have a direct and negative impact in the quality of the work you deliver. This is specially true for engineers/contributors that lead significant areas of a community project in which there are not enough contributors to create quality assurance procedures. Or are not applied to the leaders.

The second risk is the lose of “self demand” and its consequence is the reduction of quality of your work.In my case, changing responsibilities and working environments every few years have helped me. I am not sure to what extend though. Others should judge it, I assume.

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

Related to our topic, the most relevant internal factors /strengths and weaknesses) I can think of are the following:

Strengths

  • Passion.
  • Collaboration. Sense of community/identity.
  • Worldwide project.
  • Prominent FLOSS project. Well known brand.
  • Leading technology. Innovative.
  • Well defined product (software).
  • Broad base of skills.
  • Efficient development process.
  • Economically sustainable.
  • Internal communication.


Passion: KDE, like other community projects, is formed by people passionated about what they do and aboutfreedom.

Collaboration. Sense of community/identity: this culture make them extremely efficient and determined when decisions are taken, reaching goals that might seem impossible.

Worldwide project: KDE is a worldwide project, with active members all over the world, that speaks in many different languages and come from many different cultures.

Prominent FLOSS project. Well known brand: KDE is one of the current leading free software projects in the world and its brand has a high value, not just because of the product delivered, but because of the clear identity behind it.

Leading technology. Innovative: KDE develop some of the most interesting technologies in the software industry for desktops.

Well defined product (software): KDE Platform, KDE Workspaces and KDE Applications form a whole product that give answer to millions of user needs all over the world.

Broad base of skills: KDE is formed by people with many different skills, experience and motivations. It is a rich community.

Efficient development process: to develop and deliver the product throughout 15 years, KDE have a
complex, efficient and innovative development process. Coordination.

Economically sustainable: KDE is todays an economically sustainable project. Budget control and management is efficient.

Internal communication: KDE has solid communication channels and procedures with high participation.


Weaknesses

  • Weak marketing culture. Lack of experience.
  • Lack of resources for non technical activities.
  • Complex ecosystem.
  • Complex decision making process.
  • Diffuse points of contact.
  • Self criticism.


Weak marketing culture. Lack of experience: marketing haven’t been a priority in the past. We can do much better in this area.

Lack of resources for non technical activities: some non technical areas need more manpower.

Complex ecosystem: KDE is a big project with a complex structure. It is not easy to understand it when you come from traditional organizations.

Complex decision making process: because of its nature, some kind of decisions are hard to make in KDE. This is common to most community driven projects.

Diffuse points of contact: approaching KDE can be hard to do since we lack of globally defined roles. Some knowledge of how KDE work is needed to make the approaching process efficient, specially for non technical issues.

Self criticism: KDE has a strong sense of self-criticism, which is really good for internal processes, but harmful if it is made public continually focusing on weaknesses.

Once again, if you think some other elements must be added, feel free to make comments to this post.