Skip to main content
EuroPythonCode of ConductLive đŸ“č

Best practices to open source a product and creating a community around it

Room:
Wicklow Hall 1
Start (Dublin time):
Start (your time):
Duration:
30 minutes

Abstract

In certain areas of the industry open source has become mainstream, whether it be a small part of a product, a “community edition of a product”, or creating a whole business around an open source product. One could assume the only thing required to do so is to make the source code of the project publicly accessible, possibly by putting it on a platform such as GitLab or GitHub, and one couldn’t be more wrong.

In this talk we explore those aspects such as the licence and the governance of the project and the impact they can have. Then we talk about common mistakes teams make which create an environment where outsiders don’t necessarily feel welcomed to the project. First impressions matter and it’s important that new contributors and users stay once they encounter the project.

TalkCommunity & Diversity

Description

There are many aspects of open sourcing a product which are often overlooked yet greatly impact the community and activities around the project. One of the first things people think about is the licence [1], which is very important, but what people don’t often think about is the governance of it, which impacts the speed, decision making processes, and the kind of engagement one can get from contributors to the project who don’t work in the company.

Not every project is open sourced for the same purpose. On one side of the “openness” spectrum some projects are out there to give a bit of visibility to what a team is doing or to showcase a research or another product, and on the other spectrum the creators of a project put it out there to create a user and contributing community so that eventually the community would be active enough for the original creators to become a minority in the contributing and governance team. Depending on what the goals are, one needs to create or use a governance model which matches those goals and needs. One can look at the following categories from this perspective [2]:

  • "Do-ocracy"
  • Founder-leader
  • Self-appointing council or board
  • Electoral
  • Corporate-backed
  • Foundation-backed

Then we talk about some practices which can fend people off when they try to join a community, giving concrete detailed examples on how it can look like while interacting with contributors and users online, such as [3]:

  • Lack of onboarding
  • Nothing in writing
  • Leadership is a mystery
  • No path to success
  • Poor communication
  • Lack of transparency
  • Not seeing ourselves in others

[1] Licences and Standards, https://opensource.org/licenses [2] Understanding open source governance models, https://www.redhat.com/en/blog/understanding-open-source-governance-models [3] Brain Proffitt, Seven Deadly Sins of Open Source Communities


The speaker

Adrin Jalali

I'm a computer scientist / bioinformatician who has turned to be a core developer of scikit-learn and fairlearn, and work as a Machine Learning Engineer at Hugging Face. I'm also an organizer of PyData Berlin.

These days I mostly focus on aspects of machine learning and tools which help with creating more ethical and fair decision making systems. This trend has influenced me to work on fairlearn, and to work on aspects of scikit-learn which would help tools such as fairlearn to work more fluently with the package; and at Hugging Face, my focus is to enable the community of these libraries to be able to share their models more easily and be more open about their work.



← Back to schedule