#bbuzz: When Code Is Not Enough: A Guide to Building an Open-Source Community
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 48 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/68796 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Berlin Buzzwords 202033 / 48
14
19
26
43
47
00:00
CodeBuildingElectronic program guideOpen sourceOpen sourceProjective planeSoftware frameworkData structureMultiplication signBitFocus (optics)CodeOrder (biology)CollaborationismBuildingLogical constantDataflowGoodness of fitOpen setRight angleComputer animationXMLUML
01:55
Projective planeSoftware bugOpen sourceSoftwarePatch (Unix)Universe (mathematics)Software developerMultiplication signDistribution (mathematics)Portable communications deviceFreewareContext awarenessVideo gameBinary codeBitStandard deviationSource codeForm (programming)WordTerm (mathematics)Stallman, RichardRouter (computing)Computer hardwareSoftware engineeringInformation technology consultingOpen setPhysical systemObservational studyComputer architectureProgramming languageOrder (biology)InternetworkingComputer programmingCodeComputerSlide ruleNeuroinformatikWeb browserMainframe computerDatabaseCuboidClosed set
08:08
Slide ruleMedical imagingBuildingOpen sourceTerm (mathematics)
08:54
Pay televisionConnected spaceSource codeSoftware developerProjective planeOpen sourceFeedbackDampingVirtual machineCASE <Informatik>Right angleSoftware maintenanceSoftware testingProduct (business)MereologyService (economics)Computer clusterException handling
12:11
Projective planeCodeSoftware maintenanceType theoryUniverse (mathematics)Source codeSoftware developerEndliche ModelltheorieMedical imagingSlide ruleDifferent (Kate Ryan album)Group actionProgramming languageMachine codeBlogDatabaseSelf-organizationWeb 2.0Dependent and independent variablesFeedbackSoftware frameworkCore dumpProcess (computing)Computing platformPoint (geometry)Connectivity (graph theory)Single-precision floating-point formatDatabase normalizationCodomainOpen sourceSoftwareTask (computing)HypermediaRevision controlLine (geometry)Multiplication signThermal conductivityEmailCASE <Informatik>Electronic mailing listNumberDecision theoryDot productUsabilityComputer animation
19:33
CodeVapor barrierProjective planeWriting1 (number)Right angleEndliche ModelltheorieMultiplication signAddress spaceSoftware frameworkHypermediaMereologyTorvalds, LinusPoint (geometry)MathematicsCircleProcess (computing)Type theoryPublic domainSoftwareCodeGame controllerTelecommunicationSource codeThermal conductivitySelf-organizationSoftware developerElectronic mailing listWeb pageLogical constantBlogPhysical systemSpeech synthesisRotationDecision theoryShared memoryEmailLimit (category theory)Kernel (computing)FreewareRepository (publishing)Server (computing)Event horizon
26:56
PressureProjective planeControl flowPoint (geometry)CodeSoftware maintenancePlanningProcess (computing)Open sourceReal numberDatabase normalizationParameter (computer programming)Dressing (medical)
29:19
Projective planeShared memoryTask (computing)Electronic mailing listOpen sourceBuildingEmailFunctional (mathematics)WritingCodePoint (geometry)Multiplication signOrder (biology)Streaming mediaProcess (computing)Normal (geometry)TelecommunicationRight angleLink (knot theory)Commitment schemeSystem call
35:09
Evolutionarily stable strategyUtility softwareProjective planeInternetworkingCASE <Informatik>Metric systemMereologyCodeMathematicsYouTubeEvoluteOpen sourceBackupFile archiverVideoconferencingOrientation (vector space)Scripting languageInternet forum
38:50
XMLUML
Transcript: English(auto-generated)
00:08
So hello everyone and welcome. My name is Max and thanks for tuning into the session. And yeah, thank you for the nice introduction. Let me start off by saying this is a bit of a
00:22
different talk. Most talks here at Buswords focus on building or using open source technologies, but I want to take a step back today and look beyond the code. So what makes an open source project open source? Well, strictly speaking, it's the freely available
00:44
code, but there's more to open source than its code. And in order for a project to be successful, a successful open source project, it needs to develop a community because the community is like the backbone of the project. It establishes the framework for the collaboration
01:03
for innovation, for growth, and ultimately also sustainability. So for example, in a healthy and diverse community, the constant flow of ideas is likely to produce a better outcome than a project that is proprietary or one which has
01:21
a disorganized community, but not all communities are the same. So let's take a look today. What makes a good community? Let's take a look at some of the structure of a community, how to build it. And also let's spend a little bit of time to see what are the common pitfalls
01:46
and some examples of successfully built communities. All right. But first of all, let's talk about open source. What is open source anyway? It is pretty much taken for
02:05
granted these days to have, you know, a bunch of open source code available free to use. But in early times of soft development, starting in, let's say the fifties, that was about the time when people started writing really code there, it used to be normal to distribute the
02:24
code alongside with the binary. Because oftentimes there was no standard computer architecture at the time. So people had to adjust the source code in order for the program to run, the software to run on their computer or a mainframe or whatever it was called at the time.
02:44
And most people who develop software, of course, were like researchers at universities or at companies. And software was actually bundled with hardware a lot of times. So software would also be supported by a one-time payment for the hardware. Again, that changed later because,
03:03
as we see today, because in the sixties, software became increasingly more complex. We had like a lot of programming language operating systems and people really started using software and they started to charge money. And in 74, software became copyrightable in the
03:21
United States, but actually that didn't have a big impact because many companies already had stopped to distribute source code to increase their revenue. In 1983, Richard Stallman created the GNU project because he was frustrated with non-portable proprietary computer systems.
03:40
So he wanted something portable. And yeah, he created this free software foundation in 1985. So it is funny that the free software foundation actually didn't like the term open source. They wanted a different term. They still use the term free software instead because they say open source is a development methodology. Free software is a social movement.
04:06
Well, I mean, it's debatable and there's definitely some source of truth in it, but the internet and increasing use of software definitely led to a lot of commercial use and
04:22
basically open source won as a concept. But yeah, as more and more companies adopted it, there were also great communities founded. And in 1998, there was the open source initiative
04:41
was founded and we had the first very popular open source project besides Linux, the Netscape browser. And in 99, also the Apache software foundation was founded. So there's clearly evidence of success in open source and a lot of successful communities and other foundations
05:02
being founded like the Linux and Python software foundation. Before we dive into communities in more detail, let me talk a few words about myself. Again, I'm Max, I'm a software engineer and consultant for open source technologies. And I started using open source after around
05:22
20 years ago, I think. I built my own network router with Linux in early 2000. I became like a Firefox and Thunderbird user quite early. And I've used Linux also on my desktop for more than 10 years. If I were at the conference today, you would see I'm using
05:48
Linux and open source, of course, every day. So it was actually a little bit later in my studies that I understood a little better what open source was because I was really interested
06:01
in distributed systems at that time. And I was working at the research institute and we had a really fun database, a distributed database, and it was also open source. And so first time I was really working more intensively and on an open source project instead of just using open source and reporting bugs. But I found that there was no community.
06:28
I mean, in a sense, there was a community because a bunch of people at the institute were working on the software, but we never really received any patches from the outside. We had actually some people who tried it out. We're not working at university and they were
06:44
using the issue tracker, but we mostly actually ignored the issues because they were kind of getting in our way of getting our work done. And I think this is definitely a problem that people have also in big projects, but I also started wondering how does open source work?
07:05
How can you actually build a community? So after graduating, I had the opportunity to join a company called Data Artisans, which a company here in Berlin, it's now called Viverica. But anyways, this company built a community for an open source project called
07:22
Apache Flink. And it actually started with close to zero users, at least outside of the academic context. And yeah, I just found out at the time that I really loved distributed systems, coding, problem solving, but I also cared about open source. And yeah, the reason is simple for
07:42
that because the community is really the heart of any open source project. And without the heart, there's no life in an open source project. So I'm a bit biased towards Apache, which you probably will notice, but I'll also take a look at other forms of
08:04
ownership of open source project. So now this was actually the slide that I wanted to show, but it's just an image. So it's not really any text on my slides. So I'm going to skip this. A disclaimer before we start, there is no easy recipe for open source communities.
08:28
This probably shouldn't come as a big surprise. Building a community is something that doesn't happen overnight and it takes a continuous effort to nourish your community. Now we will look at some of the key aspects for that. So bear with me, but you need to invest long-term
08:48
in a community to see the benefits and to see it grow. So let's look at why do you actually want to build a community? So before we look at the how, let's start with the why.
09:05
So a very good reason for studying community is to attract attention to yourself, to your company. And that's a rather selfish reason, right? But believe it or not, it's one of the reasons people work in open source and that's completely fine.
09:23
Some people try to get as many stars as possible on GitHub. Some companies, of course, use this to attract attention to the company or a product or a service that they built using the open source product, or they're looking to promote the ecosystem or they want to sell
09:44
subscriptions. But of course it's not a no-brainer, but it's a good reason to start an open source project and build a community. Another reason building a community is useful for companies is recruiting because companies
10:01
who are good with open source, they usually are favored by developers and they can acquire engineers more easily. Now a really important aspect of course is innovation and ideas. If you have a strong community, you basically have like a super machine for exchanging ideas
10:21
and driving innovation. And the feedback loop you get in an open source project is typically much faster than in closed communities. So you can make races more often and just move faster. Also, if you work in a community, you might be able to save costs
10:44
because you share maintenance, testing, and innovation, and you just have to do your small part ideally, right? But still, if there's no community, you will have to build it and it's going to be work. Another reason for building a new community is forking because you realize
11:04
you're unsatisfied with an existing community and you want to fork it. Now that's usually not a good idea, but there are some exceptions. Like if you look at the Jenkins community, which was forked from Hudson, that worked all right and there was a good reason for doing that.
11:24
And the last reason I have for why you should build a community is open source is fun, right? Exchanging ideas, making new connections, just sharing resources. It's a modern mindset that we share things because not sharing is kind of the past, in my opinion.
11:49
So instead of just building a community from scratch, maybe there's already a community that would fit your needs. And in this case, you could join an existing one and focus on what is
12:01
important there for you. So with that out of the way, let's take a look at what makes a community. So basically you have like four topics, let's say. Number one is code. Number two is people.
12:24
And number three is processes. And lastly, what do I have last? It's ownership, which is probably the most important point. So let's start with code. Why is code important for a community?
12:45
Well, if you want to build a community, you have to build it around a meaningful piece of software. It's a software community, right? So if you don't provide value to people, basically nobody's going to care about your project. If there's already existing solution,
13:03
you're doing the same thing that already exists. There's usually little incentive for people to join your community. Also code itself attracts a certain kind of community. Think about, let's say, about the complexity, about ease of use, about what programming language
13:24
you use. All that has an influence on the type of community. Compare, for example, a list project and a JavaScript project. It's very different kind of people who work on that. And databases and web frameworks, again, a huge difference. So you should ask yourself, how good do you know
13:48
the people or the type of people that could contribute? And of course, is there a demand for a community around your code? So we had code. Now let's look at people. And I put this
14:09
molecule picture there, or is it a universe picture? Because a community consists of layers, which are, of course, moving all the time. But
14:26
if most people, when you think about people in a source community, they say, well, they are users, they are developers, and they're contributors. And that's a very simple model. Again,
14:41
like users would use their software, developers develop it, and contributors are kind of doing both, but they're not really developers. Yeah. I mean, in reality, it's much more complex, of course, because the software developers, if you think about it, they're rarely employed by the project. I think they are definitely a project,
15:03
but that's the case. But it's also a question if that's good. Usually developers work in companies, and there you have, of course, the open source funding problem. And people who work on the open source project in the community, they have different goals.
15:24
And you should acknowledge that. So don't expect that everyone can spend the same amount of time in the community, but still give them a chance to contribute. If you have a component that's really important, don't rely on a single person, single maintainer, build in some redundancy. Otherwise, if there's maintainer burnout,
15:45
which does happen frequently, you have a problem basically in your community. And recognize that your community can span outside the code domain. This is a very old
16:00
model that we are all coders in the community. Nowadays, there are so many tasks which are important in the open source community that don't require coding. And then also think about the people behind developers or people actively contributing. Who are the decision makers? Every
16:24
project has these people that back the project. And if you can find a way to reach out to these people and acknowledge that they're there, it can be very helpful for your community. Also think about writers, bloggers, evangelists, and generally people enthusiastic about your code
16:52
or your community. If you make it easy for those people to reach out, you probably have the better stories and you can share more about what your project is doing.
17:06
So ideally you want to have all kinds of roles present. You want to have coders, you want to have architects, you want to have organizers, supporters, people who ask questions and people who answer questions. So you need those diverse roles. So the question is, how do I get those
17:26
people and how do I get such a rich community? Well, every community needs a group of people who can take responsibility for the project. And I call that the critical mass, which is probably best described as this inner dots in this image here on the slide.
17:49
And the critical mass is a diverse group of people with different backgrounds, different interests, and also varying experience. And these people basically, they make sure that
18:05
the project runs. And in the beginning, that could mean just starting off the project. So donating the code, licensing it appropriately, creating bylaws, creating a code of conduct and contribution guidelines. But also in the day-to-day business, they're really important
18:24
because they can drive discussions on the mailing list. They can answer questions on the main list or on other platforms. Basically, they ensure that the project stays relevant with regards to technology, which is really important for a project.
18:46
Then of course, getting rid of technical depth is an important point and ensuring that the project infrastructure works. There are also other tasks like mediating conflicts, recognizing contributions to the projects that are really important.
19:04
For example, in some of the projects I worked, we always try to encourage new contributors to contribute more. And we gave them feedback. We also celebrated, let's say, 1,000 PRs or anniversaries of the project.
19:25
But you also need a core group of people who go beyond just the day-to-day work. You need also people to organize meetups and conferences, writing articles and books, and also promote
19:41
the project on social media and being excited about it. So how do you find the critical mass? Well, I have a good quote here by Jan Lenhard, who is the couch DB PMC or chair. Sorry,
20:01
he's also a PMC member, but he's the chair. And he says on his blog, I try to be involved with every threat on the main list, showing exemplary behavior, being nice to people, taking the issues seriously, trying to be helpful overall. After a while, people stuck around, not only to ask questions, but to help with answering as well. And to my
20:21
complete delight, they mimicked my style. So I think the critical mass is like the role model of the community. It all starts with maybe just a few people, but it grows over time as you show these exemplary behavior and you motivate other people to be active in your
20:41
community. So the third point is processes. Processes are super important in a project because if it's not clear to somebody who joins what the processes are, then
21:03
it takes a lot of time to learn about that. And it also creates a huge barrier between the people who are already part of the community and the people who are trying to join. So basically you need to document all of this and you could start with workflows. How do you contribute to
21:29
the project? What are the parts of your project that need support? How are changes reviewed? How do we document if we make changes? How do we test them and how do we release software?
21:45
That all needs to be written down and be very clear. Then also communication needs to be clear. What tools do we use? Where is, what is the source of truth? Is it Slack or is it main? Or do we use mailing lists? Do we have a code of conduct for everyone to be on the same page?
22:07
And then also how do we earn merit? So in all of communities, you get basically more permissions to work on code based on merit. And the problem with this is that the
22:22
merit needs to be recognized by someone who is already in the inner circle. And yeah, connected to that is the decision-making. How do we decide based on consents, majority, and who has the final say? And then of course there are legal processes that also need to be
22:43
watched out for and compliance. Yeah, all these should be formalized and written down as much as possible. Speaking about compliance, let's take a look at
23:02
the last ingredient of a community, which is ownership. Now ownership is often associated with the license of the code. So we have licenses like a public domain. We have permissive licenses like the Apache license, BSD license, MIT license, but we also have copyleth license, GPL
23:29
and others. And we have proprietary license. Licenses are kind of important for the community as well because they set the legal framework and they influence the type of community which
23:42
can grow around the piece of software that is licensed. So for example, if the Apache license doesn't require you to contribute back, which may seem like a disadvantage for your community, but it's also a great way to grow the adoption of your project. And that eventually could
24:02
help your community. But ownership also applies not only to code, but also to infrastructure, repositories, main list, chat servers, and the name of the project actually, which is often trademarked. And ultimately ownership is the most important thing for decision-making
24:31
governance because if somebody owns the project, then he or she can just take it away. And that can be a problem. In most projects, we have kind of two different models. One is
24:50
the model of the benevolent dictator, which was coined by Guido van Rossum and also lived in the Linux project by Linus Torvalds. And it has some advantages because you have really
25:05
tight control over the project and you basically can control it if you own it. But it's also a bottleneck and Linus solved this problem by, for example, writing Git, which got the current development to scale again with him as the benevolent dictator.
25:26
But that's not really feasible for a lot of projects. So instead, we have foundations. We have the Apache Software Foundation, we have the Python Foundation, Linux Foundation, Eclipse, and of course the Free Software Foundation. So in my eyes, the Apache and the Free Software
25:42
Foundation are probably the most independent and open ones because they accept, while they do accept donations from the outside, the only way to influence the project is by gaining merit in them. So merit again means that you get through your contributions, through doing something
26:03
meaningful, you get a committership or some rights in the project. The Linux and Python Software Foundation actually also have the merit-based model, but you can also donate money and you automatically get a saying in the project's decision, which is, again,
26:26
a different way to define the ownership and that has an influence on the community. So in the end, it doesn't matter, but you have to decide what is best for your, what governance model is best for your community. So yeah, there you have it. I mean,
26:45
a good community is one which solves all the problem or at least addresses them in some way.
27:01
So let's look at some of the points that could be tricky in the process of building a community. So first of all, you should take open source seriously. If you just dump your code somewhere
27:20
and you think the community is going to build itself, it's not going to work. It's been proven. So you need to think about that in advance and approach this in a structured way. Then you should communicate openly and be patient.
27:42
Lack of funding and monetization can be a real problem because, yeah, you should make sure that your project can be financed somehow and people can make a living with it. This is often very tricky and I don't have a definite answer for that, but at least think about that. And another thing that can happen is that your users
28:08
are unsatisfied and that things break and you should have a plan how to address this concern. And I already mentioned that earlier. If you have people, too few people working on stuff,
28:25
maintainer burnout is very real. So reach out in advance or try to find somebody else and introduce him or her so you can have some redundancy built in. And in every project, they're going to be arguments and discussions. That's pretty normal,
28:44
but make sure that you speak civilized and moderate these discussions. In the end, projects can die and reputation can suffer, actually, if you put your name somewhere or
29:01
associated with the community. And yeah, since open source communities can do harm, perhaps see a talk on building a community first. So before we conclude, I want to
29:21
take a look at two projects. One is Apache Fling and the other one Apache Beam. So Fling is a stream processing technology. It was a research project and then a company came and wanted to build a community around it to ultimately also drive the adoption of Fling.
29:51
And I think Fling did a lot of things right because they embraced open source from the beginning. So it meant while I was working at the company that built Fling,
30:01
that we didn't discuss anything internally anymore. We shared everything on the main list. We discussed on the main list, we shared design documents, and we also organized meetups around the world from the very beginning after we founded the company. We also started a conference
30:26
around Fling called Fling Forward, which is still running every year and here in Berlin and in San Francisco. And also the community expanded to China in 2016. Now the company was actually bought in 2019 by a company called Alibaba. But what is amazing
30:46
about this is that this cooperation went on for many years before and still continues. And that, I think, is a huge success of an open community that functions despite, of course, money being involved. And then there's Apache Beam. Beam was originally a Google project
31:07
and it was put on GitHub without any clear open source contribution guidelines, just as a piece of code. But in 2016, Apache Beam or the code that was Apache Beam joined
31:26
the Apache Software Foundation. And I think Beam did a lot of things right because it had very clear contribution guidelines from the beginning. We regularly evaluate contributors for committership and send out encouragement emails. We have very early awarded committership
31:45
for non-code contributions, which at that time, few projects were doing and are still not the norm, I would say. And we also organized Beam Summit, which is a conference which takes place in August this year. And we also do meetups, of course. So
32:09
I'm kind of running out of time here. So let me conclude with just five secrets to building a strong community. Of course, building a community is not an easy task.
32:23
And I'm sorry if you wanted to watch this talk to get the definite answer and the clear way to success. I'm sorry I couldn't share it with you. But I hope I could describe some of the important aspects of building a community. So to summarize, here are five secrets which
32:45
I already covered. So first one is communicate openly. It's called open source for a reason. So you should make sure that everything is openly and transparently in your project.
33:00
That's the only way somebody who's new to your project can join your community. Then document well. This actually ties with the communication as well. So everything that you do should be documented so people don't have to dig into
33:22
old mailing lists, discussions to find out what was actually cited there. So write design documents, write good commit descriptions, always make sure to document. And I cannot emphasize this enough, you need to innovate frequently because
33:40
open source projects, they are also a very competitive market. They're new projects starting all the time. So in order for your community to survive, you need to innovate. Recruiting is super important because enough to believe people are going to leave your community. They're going to go to a different job. They forget about you. And if you don't
34:05
recruit new people all the time, then your community is in danger of dying. And the last point is the relationship. If you foster relationship, for example,
34:20
meetups or conferences, you are building the foundation for your community because ultimately we are all humans and everything is about relationships. So I believe with the critical mass that I mentioned, or with a critical mass, you can build a foundation for your community. And it might be small in the beginning, but if you
34:46
show exemplary behavior, and if you always reach out and you're open to new members, then your community will be successful. With that, I want to conclude,
35:03
and I think we have some time for questions now. Thank you. Thank you, Max, for this motivating talk about building a community. I have one question from Lucian, who is asking what examples of open source projects that succeeded
35:24
without backup from commercial entities can you give? And of course, and this is the most philosophical part of the question, first we should have to define success and without.
35:40
Do I have to repeat the question? No, it's okay. Yeah, I get it. I think there are a lot of examples of successful communities or in projects that are not financially very successful. For example,
36:02
there's this tool called YouTube download, for example, which has an amazing community. I've been using this for some years and everybody's always so helpful there. Whenever there's a new site, which is basically a download script for downloading YouTube videos,
36:22
but also all kinds of episodes, videos you find on the internet, which is really nice if you want to archive them. It's just a utility, but that's a really good project that is not a
36:47
like say Firefox or Thunderbird, where you really have a foundation behind it, also with Apache project, which in the case of Mozilla is really just doing good for the people
37:06
and not primarily profit oriented. The other part of the question was how do you find success I think you define it. How do you define it? And for example, Lucian just added what was,
37:24
for example, the critical mass, the size of the community that makes an episode projects successful. Like when you have 5,000 stars on GitHub, just start being successful or how is it counted? Yeah. I don't think there is like a magical metric that shows you if a project
37:48
is successful or not. I think it's successful if people use it. But I mean, even if they're just a handful of people using it and those people are having fun and they share experiences,
38:01
that's a success to me. I mean, what is not a success to me is I think if, and there are a lot of projects like that, where basically like one person built something and a lot of people use it, but the community around it doesn't grow and that person just
38:22
works his ass or her ass off and nothing happened. Get a stack of issues where it doesn't work like I want or something like that. And also, of course, if nobody uses, if there's just that code on GitHub,
38:41
I think that's a failure. No more questions on my side. Thank you, Max. Thanks for moderating.