Interview candidates with an Open Source background

I often say that there are two actions that defines the line management role: one-on-ones and hiring people. This is specially true in growing organizations. If you nail these actions, you have a great chance to influence your colleagues and organization, the ultimate goal, in my view, for a line manager.

One of the common strategies to speed up the journey from being an Open Source contributor to become a Good Open Source citizen is to hire talent with a solid Open Source background. The process of hiring such talent is different from what most organizations and recruiters are used to. That is so true that we have now companies specialized in hiring these profiles.

One key part of the hiring process is the interview.

The article is another one of those I am writing the last couple of years about management topics, based on my experience working in Open Source as manager and consultant. More specifically, it is an attempt to describe some of the key points that hiring managers with little or no experience in hiring Open Source talent need to consider to increase their hit rate.

As usual, I would appreciate if you add in the comments section or to me directly your experience, criticisms or missing points. I would add them to this article as update.

Evaluate the candidate’s work in advance

If you only have room in your hard disk for one takeaway, it should be this point.

Most of your candidate’s work is public. Take the time to evaluate it or have somebody else doing it for you, before the interview. If the candidate have public talks, watch the videos or check the slides. If she has written articles, read them. If she has code available, study it, test it, install it.

Having the candidate’s work in the open is a double edge sword. It is an advantage for the hiring organization because it can reduce significantly the hiring process, since you can evaluate in detail many of the candidate’s skills in advance, so the interview process can be reduced to a single interview, for instance (I strongly recommend this, by the way).

At the same time, if the hiring manager do not take the time to evaluate the candidate’s work or even worse, if she acts during the interview as if that work is not public, trying to technically evaluate the candidate prior or during the interview, the failure is almost guaranteed.

I always mention how wrong it is to ask a music group with published records or videos of concerts on their website if they know how to sing, or even worse, ask them for an audition during the process to hire them for your birthday party. Watch their performances, skip the audition and go directly to other relevant aspects. Their work is public, did you check it?

By the way, the world is significantly larger than GitHub, thanks God. The candidate might have a strong Open Source background without having a great GitHub profile… or no profile at all.

Interview goal

The interview is not just an opportunity to evaluate if the candidate fits in your organization, it is a chance to attract the professional and her colleagues. The candidates work, processes used, tooling… is public. Your organization’s most likely not. Who has more to inform about?

As result of this reality, the interview should look more like hiring a senior manager/expert than it is about hiring an engineer.

In summary, the goal of the interview shifts. It should be balanced between what both, the organization and the candidate looks for. This shift represents a challenge for hiring managers with limited experience in hiring senior talent.

Candidate’s future upstream participation

During the interview, be clear about the amount of time the candidate will have to invest in upstream work, her current work.

Remember that there are plenty of developers who prefer to keep their work in the open as a personal activity. On the contrary, some others want to make a living out of their participation upstream. The best way to ensure a sustainable relation over time is to be transparent about the expectations related with the effort in internal work vs work done in the open in which projects.

If by working in your organization, the developer will have to reduce its current involvement in the open, specially in specific periods of time, say it clearly. If you cannot guarantee that the technologies the candidate works with in the open will be part of the company’s tools set, state it clearly. If your organization has plans to move towards Open Source and you bring the candidate to speed up that journey, make sure the candidate understands the timelines and expectations.

No matter how experienced you are as hiring manager, there is always room for a candidate to surprise you about her motivations to participate in the interview and potentially join your organization. This is most likely true with professionals coming from an environment you might not be very familiar with.

Tooling, languages, technologies…

One of the great advantages of being an Open Source professional is that, because you use open source tooling, you can take them with you throughout your career, which makes you very efficient. You do not depend on having any corporation paying them for you or having to change them regularly, limited by commercial criteria. In other words, Open Source professionals has made their career supported in specific tooling and associated practices they have mastered and very often helped to polish over time. Some of them love to try new ones and some love to focus their energy in other aspects, not in the tooling or associated processes themselves.

In some cases, this specific point is so important for the candidate that using those tools and associated practices represents a requirement to join your organization.

You will need to consider and potentially embrace this reality. If you cannot or do not want to use those technologies or tools, make the point during the interview but…

Are you open to reconsider such decisions if somebody prove there is something better? Is it something that can be reconsidered next year, when the current support contract for toll X expires? Do you have any specific department or project where you are willing to try new tools, processes, languages…? Are you open to assume that you might have made a mistake in such decision or that those decisions will not stand the test of time?

Many Open Source professionals, for instance, consider that, doing Open Source with Open Source tools is significantly better that using proprietary ones. It make sense. At scale, adapting the tooling to the needs of the environment and integrate them with other tooling to improve the development experience is essential. Have full control of such evolution is another interesting point… there are many other strategic and practical reasons.

Learn from the candidate about those arguments during the interview.

Very often hiring managers see the candidate’s position in this front as religious or philosophical. Instead I would take it as an opportunity to improve and innovate within their organizations. I suggest to embrace such experience the candidate can bring to your organization as starting point during the interview and take the conversation from there, instead of questioning her criteria and define this point as a no-go.

Recommendations and referrals

Open Source is about trust and networking based on the work the potential candidate does within one or several communities. In many cases, the candidate recommendations and referrals come from peers from those communities.

If you are a hiring manager, take those recommendations as seriously as any traditional referral from a senior manager or a relevant figure in any big corporation. They are frequently equally valuable.

In Open Source, you are judged by your work and your influence, not by your position in any hierarchy of any organization.

Get help for the interview

If you have little or no experience with Open Source, bring somebody that do have it to the interview, in addition to the technical expert, specially if you are interviewing engineers. It is not relevant if such person is not an expert in the candidate’s knowledge area of expertise.

I am not a technical person and, when I join such interviews, the hiring manager often learn new things about the candidate because we both share a similar work culture. This is specially true when the candidate ask questions to evaluate if the company is a good fit for her. In addition, it often plays in favor of the company to show to the candidate that there is Open Source knowledge internally and professionals that feel comfortable working there.

Assume the candidate knows about your organization already

Do not underestimate how much candidates with solid Open Source background know about your company before the interview, even if your organization is not an Open Source contributor.

These kind of professionals might learn about your organization not just by interacting directly with your engineers or evaluating your products, but also by interacting with your suppliers and partners in the open, in some cases on regular basis. They might know about the hardware you use, the versions of specific software you ship, tools you use, release strategies you have, updates policies, etc. They might point at clear deficiencies and strengths of your products and services as well.

I suggest to ask the candidates what do they know about your organization and why do they want to join, during the interview. It is also interesting to ask about their evaluation/perception of your organization as a whole and your products/services compared to others.

It is not only about getting information from the candidate but also about informed perceptions. Such conversation might help hiring managers to tune the description about what the organization does and avoid providing superfluous information during the interview. It also helps to understand if the candidate is one of those who want to work in industry leaders or help you to become one which is something I am always interested to learn about them.

Why do you need a CV?

Even today, I still come across former colleagues and great Open Source professionals who do not have a CV. I have helped several of them throughout the years to create one or update it.

For an Open Source professional, their work speak for themselves. It is a better presentation that any CV will ever be. It is the outdated culture, your organization tradition, the one that should change and adapt to this “not so new” way of “filtering candidates”. It is simply better for all parties involved.

Many great Open Source professionals have a mediocre CVs or no CV at all because they never needed it. For some is even a way to filter organizations they do not want to work with. If you need my CV to filter me as candidate or evaluate my work, I am not interested in working with you.

Instead of questioning the quality of their CV, take the opportunity to ask yourself why do you or your organization need a CV when the candidate’s work is publicly available. It might be a great introspective exercise. Maybe you end up only needing a bunch of links and his contact information instead of a formal CV.

Myth: Open Source developers are not good communicators

Open Source professionals, specially developers, are used to having a great exposure to other professionals worldwide. In general, they need to become good communicators to succeed within their communities. It is common sense.

Open Source developers as people incapable to communicate is a myth. Such perception often depends on what you understand by communicating and to whom, but specially to myopia from people not coming from a technical background.

Evaluate the candidate’s written communication skills. Check the mails they send to dissent with others or describe their position, read the blog posts they write summarizing their latest work, check their presentations, their slides… Check how they interact with their users, code maintainers… You will soon realize they interact with profiles or groups of people on regular basis your engineers do not and overcoming greater limitations.

It is true in my experience though that, in general many Open Source developers do not do great interviews. But that is mostly because they do very few of them. They do not go to 10 interviews with four different companies to get a job. They do not need to. And what is more important, throughout their careers, interviews are not used to evaluate them as engineers. Again, their work speak for themselves.

When talking to managers unfamiliar with Open Source about this point I always ask them how many professionals they know that has done good interviews but are incapable to stand behind their opinions in a meeting with senior colleagues or customers. Or how many people in their teams excel at describing complex ideas in simple words, in a 10 min presentation for instance. How many of them did a great interview?

Public exposure to peers and users in Open Source projects are an outstanding learning environment for developing certain communication skills. Be careful with this myth.

English level

In Open Source, most of the communication among developers is in written form (letś include code here). Most developers have a better level of written English than spoken.

I always recommend to be careful when evaluating the candidate English skills only through the interview. To have a full perspective of the candidate skills, I always recommend to check her written communications and articles. If they have videos of their talks available, review them. You might perceive noticeable differences between their written and spoken English levels.

When doing an interview, it is very hard to be quick and provide sharp answers without thinking when you do not use English in regular conversations on daily basis. I have experience this myself.

My point here is that you might evaluate his English skills as poor based in the interview and, in many cases, they have solid written skills so they need little time to develop the required minimum skills to speak English fluently.

Agile fans tend to underestimate how important it is to have a good written level in English compared to the spoken/conversation level. In Open Source (develop software at scale), the trend is exactly the opposite, for good reasons.

Remote Work

Many professionals prefer to live by the beach in a cheaper place than to commute for an hour to go to the office in a big city. It should not come to a surprise that market is moving towards developing software in distributed environments.

The number of “remote first” and “remote friendly” companies is growing in number and size at a fast pace. Open Source is about highly distributed, asynchronous and high latency environments. Some of the larger software engineering projects has grown and mature in such environment.

The candidate has probably made a career out of mastering working on such environment.

Instead of questioning the efficiency of such environment during the interview (common practice among remote work detractors, like radical agilists), take the opportunity to learn about it. If you think that co-located, synchronous and low latency environments are more efficient, ask about how current tasks could be performed remotely, how ceremonies can be adapted, how testing can be performed remotely. Learn from the candidate about how to develop software at scale, how he has acquire such experience and levels of efficiency in such environment.

I have worked in organizations where even testing was done remotely, in a heavily distributed environment, for instance. Technology and creativity has made Open Source the best solution for developing software at scale. Even if your organization is small, the candidate skills might become an asset.

The network effect

Working in the open provides any professional the possibility of building a large network. The interview process might well be the first and only direct interaction that such professionals might have with your company. If the experience is not satisfactory, her network will know.

Would you recommend a person you trust or respect to apply to a company that did not provide you a good experience during the hiring process? And I am not talking about hiring them. I have had good experiences with companies that chose a different candidate during the process. We are grownups. We can take rejection.

By ignoring the above points (or others i skipped), you are not just simply making harder for your organization to hire Open Source talent. You are shouting with a speaker your deficiencies.

It is not a coincidence that some corporation have such a hard time hiring good Open Source professionals and some others are so successful. It is partly because of the networking effect.

Do it right a couple of times and more talent will come. On the contrary, fail badly and you will pay the prize for some time.

How to move the candidate out of her comfort zone

Part of any interview’ goal is to get out of the candidate things she did not plan to show or surface.

People used to work in the open, with high levels of exposure, develop a great sense of correctness and politeness when expressing opinions. That does not mean they are not passionate about what they do or that they do not have “radikal opinions”. They are and you want to know it.

Ask the candidate for her opinions about tools, technologies, projects from your competitors or technologies that the project they participate on are struggling with. I believe these kind of questions are a fair way to move the candidate out of her comfort zone and get their “essence”.

Just be aware of the trends and debates the candidate and/or the community she participates on have had about such topics. Do not make the mistake to make statements that are a no-go for the candidate simply because you did not prepare the interview well enough.

Avoid the typical myths around Open Source. Instead, ask for how do they see their community project in five years and which are the challenges and deficiencies they need to overcome, for instance.

Summary

Radical exposure to peers, upstream and users, communicate with them in the open, working with public code, sharing knowledge with professionals from different industries and global organizations, etc. are candidates characteristics that cannot and shouldn’t be ignored during the hiring process, specially during the interview.

Instead of applying the same template that has worked fine in the past for your organization, hiring managers will need to evolve it or even change it in order to attract people with solid Open Source profile. This is yet another of those transformations and culture changes that any organization will need to go through to fully embrace Open Source.

To me is very simple, if you want to become a Good Open Source Citizen, you will need to hire people with a strong Open Source background to speed up the journey. Either you adapt your hiring processes, like the interviews, or you will most likely fail in such goal.

To adapt, hiring managers and experts need to develop new habits. That can only come if they question the current ones. This evolution will take place faster and with a smaller impact for their organizations if they get help.

Sadly, I think in Open Source we have paid little attention to this challenge.

Contributor License Agreement and Developer Certificate of Origin references

In the last few years I have come across the CLA topic several times. It is and will be a popular topic in automotive the coming years, like in any industry that moves from being an Open Source Producer towards becoming an Open Source Contributor.

In my experience, many organizations take the CLA as a given by looking at the google, microsoft or intels of the world and replicate their model. But more and more organizations are learning about alternatives, even if they do not adopt them.

What I find interesting about discussing the alternatives is that it brings to the discussion the contributor perspective and not just the company one. This enrichs the debate and, in some cases, leads to a more balanced framework between any organization behind a project and the contriibutor base, which benefits both.

Throughout these years I have read a lot about it but I have never written anything. It is one of those topics I do not feel comfortable enough to write about in public probably because I know lots of people more qualified than I am to do so. What I can do is to provide some articles and links that I like or that have been recommended to me in the past.

Articles

  • Why you probably shouldn’t add a CLA to your open source project“, written by Ben Alter back in 2018 is a must read. Ben is a United States-based lawyer who works for GitHub as their “evangelist” to government agencies.
    • CLAs are Not a Sham” by Kyle E. Mitchell, a lawyer, is a respond to the previous article.
  • “The trouble with Harmony: Part 1 and Part 2″ by Richard Fontana 2011, a Red Hat lawyer. He came back to the topic this year (2019) in his article “Why CLAs aren’t good for open source” summarising Red Hat’s position.
  • Why Your Project Doesn’t Need a Contributor Licensing Agreement” by by Bradley M. Kuhnon June 9, 2014. Bradley is a well known member of the Software Freedom Conservancy.
  • Contributor Agreements Considered Harmful” by Eric S. Raymond on July 8, 2019, represents a clear view from the individual contributors perspective on the CLA topic.
  • Community contributions and copyright assignment” By Jonathan Corbet, October 28, 2009. This article analyses from the contributor’s perspective the Canonical Ltd CLA which started a heated debate back then, leading to the Harmony project creation first and the initiative by the Mark Shuttleworth Foundation later on, two of the main attempts to standardise CLAs up to date.
  • Some thoughts on Copyright Assignment” by Michael Meeks, 2011, is still one of the most relevant articles on the topic, covering not just the theory but also putting examples of how harmful unbalanced relations with an entity that controls an Open Source project might be for contributors. Specially relevant has been over time the Recommendations section of this article.

DCO

It is impossible nowadays to talk about CLAs without talking about DCO (Developer Certificate of Origin). Here are some articles that I find interesting:

  1. Ben’s Cotton article “CLA vs DCO What’s the difference“, from 2018 is a good article to read because it does not favour one over the other one.
  2. I like the article “CLAs and using DCO clearly” from Hen written back in 2018 because it summarises well the costs associated to CLAs and how they (do not apply) apply to the DCO.
  3. It is worth reading the summary of James talk at Linux Foundation Collaboration Summit 2014, “The most powerful contributor agreement” done by Jonathan Corbet.
  4. Julien Ponge wrote “Developer Certificate of Origin versus Contributor License Agreements” back in 2016.

For companies that “do not buy into the anti-CLA” case, R. Fontana propose another two options:

  1. Eclipse Contributor Agreement
  2. The Software Freedom Conservancy’s Selenium CLA, which are not proper CLAs but DCOs in his view.

FLA

It is always interesting to learn about the Fiduciary License Agreement FLA, developed by the FSFE:

  1. Fiduciary Programme
  2. FLA FAQ
  3. FLA-2.0 announcement.

Inbound = outbound

A serious conversation about CLA requires to understand the concept of inbound=outbound:

GitHub explains inbound=outbound as:

  • outbound licensing”, refers to granting a licence to another party to use, copy, distribute…. (depending on the license) your intellectual property.
  • inbound licensing” means obtaining a licence from another party, to use, copy, distribute…. (depending on the license) its IP for your own consumption (distribution, etc. again depending on the license).

GitHub explains inbound=outbound as:

Whenever you make a contribution to a repository containing notice of a license, you license your contribution under the same terms, and you agree that you have the right to license your contribution under those terms.[…]

In the CLA discussion context, the general idea behind inbound=outbound is that the project should make evident to every contributor the contribution conditions, including those related with licenses rights and restriction. The contributor will then contributes her code with the same license, giving little room for later claims, either by the project, the contributor or third parties, based on those conditions being unclear or not easily reachable.

The project license and its description should be prominent and located at least where it is common practice in Open Source to find them. The same applies to all the assumptions and conditions affecting the contributors and the project in this area.

Common practice, many will claim, but sadly some projects are better than others on this.

Who is doing what?

In CLA discussions, it helps to know what others are doing. Here you have some links I have collected over the years and I still find relevant. I have to recognise that in a couple of cases cases I do not remember exactly why they called my attention at the time.

Company driven projects:

Consortium driven projects:

Community driven projects

Organizations with different agreements for individuals and entities:

Organizations with CLA:

Additional links

And finally, I have several links that I think are worth reading for different reasons:

  1. Project Harmony is worth investigating as an interesting attempt to standardize CLAs:

2. GitHub uses an Individual and an entity CLA. It is interesting their CLA-assistant.

3. James Bottomley’s ideas about the Corporate Contribution Pledge published back in 2016 as complement to the DCO are worth reading.

Additional suggestions from readers

I hope my effort triggers the contributor in you so you provide additional links or challenge the ones above. I will substitute this text for those links you provide, obviously giving you credit by default. It would be a great way to help others in the future. Thank you very much in advance.

Akademy 2019 is over.

Akademy 2019 took place in Milan, IT, at the University of Milano Bicocca from 7th to 13th of September. I arrived on Friday 6th and left Milan on Tuesday 10th.

Akademy 2019 group photo

This year Akademy was a little bit different for me. I joined MBition recently to push Open Source and, giving the kind of activity and technologies we use, KDE is an community we can learn a lot from. We have many things in common.

MBition decided to sponsor the event at the Supporter level and my colleague Julia König came with me for a couple of days to learn more about these kind of events and this community in particular.

We attended to the welcome event, the sponsors dinner and the first days of talks together. During the second day of talks, I introduced the company to the attendees during the sponsors talk.

It was also great to see my former employer, Codethink Ltd, as sponsor once again.

Several of the talks were very interesting although in general I did not attended to many. I spent quite some time outside talking to old friends, some new young contributors and other sponsors.

In terms of talks, the highlight of the event was Lars Knoll, CTO of the The Qt company. The interview published a few days before his talk is worth reading. He presented the most relevant plans about the coming Qt 6.

One of the things that have improved in KDE is our communication with the outer world. And Akademy reports are just an example. Check out the report about the first couple of days (talks).

On Saturday several talks reported about the accomplishments and challenges of the goals the community have been focusing on the last couple of years. The new goals were presented on Sunday, the second days of Akademy.

On Monday 10th, part of the day was invested in the KDE eV General Assembly. Some BoFs also took place that day. You can watch the report published on The Dot.

As mentioned, I came back to Málaga on Tuesday morning but you can read the reports about the Hands on Sessions and discussions tat took place on Tuesday, Wednesday and Thursday.

Last but not least, do not miss the interview with Leonardo Favario, Project Leader at the Italian Digital Transformation Team. It is a good one.

Thank you to the organizers and sponsors as well as the rest of the people who made Akademy a great event, in record time. It would be a great sign for MBition to be able to come back next year.

KDE is looking for a place and a team to host the event next year. If you are interested in gaining some traction locally to your Open Source efforts and are willing to meet a whole bunch of crazy, smart and friendly developers, think about applying to organizase Akademy 2020 (download the brochure).

I would like to finish this article sending my condolences to the family and friends of Guillermo Amaral, now that it has been made public that he passed away, victim of a cancer he fought hard.

Guillermo Amaral. Pic from one of his videos.

Guillermo was a great person. He had magnetism and an unique sense of humor. I cannot say but good things about him. He did great stuff.

Life is not fair.

Going to Akademy together with MBition

I will be at Akademy 2019 in Milano, IT for a few days. I am not going alone, Julia JK König. from MBition, will be there with me during the first two days.

MBition is still in the learning phase as organization when it comes to Open Source, but the enthusiasm among my colleagues, including the leadership team, with the posibility of becoming contributors in the near future makes me confident about our Open Source journey.

One of my initial goals is to help the organization to learn about how Open Source communities operate, what are their motivations, what do they do, their governance, etc. As I have written before, I would divide the Open Source communitiesin three big groups:

  • Community driven Open Source projects.
  • Consortium driven projects.
  • Company driven projects.

In order to learn about community driven projects, I think KDE is a great place to start and not just because I am involved in the project. There are several additional reasons. The most obvious ones are:

  • MBition is a C++ and Qt house, just like KDE.
  • KDE has a significant experience in areas were MBition is currently working on.
  • MBition (and Daimler in general) collaborate with Universities in intership programs. KDE is one of the most successfull Open Source projects when it comes to mentoring programs.
  • MBition HQ is located in Berlin, GE, and KDE eV is registered there.
  • I am not the only current or former KDE contributor at MBition. Motivation is king.

MBition decided not just to attend to Akademy but also to become a Supporter, by the way.

See you there.

Agile On The Beach: my first time

During 2017 and 2018 I got several interesting references at eagileonthebeachvents like Scale Summit and pipelineconf about an interesting event in the south-west of England about lean, agile and continuous delivery that got my attention. I decided that I could not miss it in 2019.

2019 edition of Agile On The Beach was the 9th one. The event has gain a good reputation among agilists for being a good mix of great content and relaxed atmosphere in a beautiful environment. This is not surprising for somebody coming from the Open Source space but is not a so common combination within the lean/agile/CD world.

I bought the tickets and reserved the accommodation on time (months before the event). As you know, I started in MBition in June. My employer was kind enough to make it easy for me to attend. So on July 10th I headed to Falmouth, Cornwall, UK to participate in Agile On The Beach during the following two days, coming back to Málaga on Saturday July 13th.

I liked the event. I felt like home. Like if I was at Akademy, for instance. There were some outstanding talks, a great atmosphere, talented and experienced attendees, reputed speakers, good organization and nice social activities.  Yes, the trip to get there was long but I had no delays in any of the several planes and trains I had to take (who said British trains are awful?) which allowed me to invest a few hours working on each way.

The videos has not been published yet. I will add as comments those I recommend you to check.

Update: please find the videos here.

Next year the event celebrates the 10th edition. They promised to do something special. If you are in the UK or are willing to invest several hours traveling to a good Lean/Agile/CD event, Agile On The Beach is a great one. But stay tuned, the number of tickets is limited and they are gone several months before the event starts.