Every FOSS project, will encounter (and have to overcome if it wants to keep growing) the three key challenges:
- Proper integration of newcomers
- Maintaining vision and values
- Keeping an open ear for the users
Yes, there will be many exciting technical problems, but the key growth factors are people related. In FOSS, everything revolves around the contributors, and it all comes down to the community to attract, integrate and support. As FOSS communities, we need to acknowledge this and work on setting up a culture that will enable us to thrive. Let’s talk about this!
Was given as keynote at PgConfEU 2015 PgConfEU2015
Introduction
There are 10 million GitHub repositories, and many new projects are added daily. What will make some projects attract hundreds of contributors, have a thriving community that will continuously take time to stop by and give hours of its precious time, while others will not have that success? Is it the technology? The innovation and creativity of the project? The ecosystem it is a part of? The support of influential people and other projects? Yes, of course. All that will have its stake.
But, if I had the chance to speak to each and every one of you here, and ask you: what makes you come back here? Why this project? What makes us come around and celebrate, learn, share, greet and meet every year like this? Maybe all the answers would have a unique ring to them. But there will be one underlying note: Belonging.
I would like to share two stories from my past as a contributor. Let’s call them project A and project B.
The contributing experience
I’ve been following project A for a while and wanted to be a part of if for Google Summer of Code. I felt really intimidated by all of those awesomely smart people that have built it - how do I start? What to do? Can I do anything at all? At university we were learning C and C++, but we only did short exercises and we have never built a real project, worked on a legacy code or collaborated with a big remote team. I’ve never before worked with a bugtracker or tested code. You can imagine :). Project A had a page with bugs beginners can look at, introduction to their workflow and much documentation. That does not help you with the feeling of inadequacy but it pushes you forward. Project’s A community was very welcoming, reviewing my code regularly and fast, without making me feel bad for it. They were active on all open communication channels and were patient with all the people who showed interest. Project A made me feel like I can fit in, be a part of it. Needless to say, I did that GSoC and continued to preach everywhere about it. I made friends for life in that community.
Let’s take a look at project B then. This was somewhat later so I had all the newly acquired skills I lacked last time. I was feeling better with approaching and thought the process will go more smoothly. Project B also had the same infrastructure, and many open communication channels. I was interested in the general idea of the project and where it’s heading, but I had no idea where to actually start. I tried following a bit on IRC first, but communication was brief and not informative, so I tried emailing. I got a response to build the project and look around There was a problem with the build, which they said they know about it, but offered no help. After asking what can I do I got an answer that they are currently doing a feature freeze and that I should wait a bit. I stuck around for a while still that maybe I will get a ping or so, but that didn’t happen. I tried actually writing some code on the side, but I just moved on at the end.
A big difference in experience! We should never forget that most of us contribute to free software in their free time, but we don’t work for free. People value their skills differently in different contexts, and that is the case here as well. You contribute to free software, to be a part of something bigger and greater than yourself. You exchange your small code for a working finished product - but you also exercise purpose and get the feeling of reward when the community loves back. Being part of things is nice! With the long days and the short amount of time we have to allocate even to things that make us happier as people, we really need environments that will let us thrive and be creative. As we can see from the stories about my experience with Project A and Project B, the brilliance of code was not crucial. Neither the fame and glory of both of the projects. What was crucial was the support. The open doors of the community. That kept me coming back, and still keeps me coming back.
And what is a community? Community is just a group of people, united by the same purpose.
If I may quote Nóoirín Plunkett who was around free software lot longer that me:
“You see, Open Source is all about the people. Really, on almost any project you would want to be a part of, the code comes second. People are what distinguish a project that is a joy to work on from one that is a chore; people are what make the difference between a project that is flourishing and one that languishes in the bitbucket. Sure, you will only stay up all night coding on a project if it is solving a problem you think is important; but unless you have people with whom you can collaborate, discuss, design, and develop, you are probably going to lose interest or get stuck before too long.”
It’s US, every single person and the values we’ll agree to stand by together as a group, that will determine the life and death of our project.
That being said, what can we do about it?
There are three steps we can follow to achieve this.
- Proper integration of newcomers
- Maintaining vision and values
- Keeping an open ear for the users
Proper integration of newcomers
In FOSS, everything revolves around the contributors, and it all comes down to the community to attract, integrate and support. The successful adoption and retention of the newcomers is a big part of this.
In every FOSS project, generational relay must happen at some point. The hotshots and know-it-alls of the project leave the project, leaving a huge knowledge gap behind. The bigger the impact and the longer the involvement of the person leaving, the bigger the knowledge gap would be. This leads to lots of “orphaned code”, and as Felipe Ortega says in Open Advice, the greater percentage of orphaned code, the harder it is to maintain the project. He also mentions the study done over Debian maintainers, calculating the so called half-life ratio. The findings were that the half-life of a Debian maintainer are 7.5 years. There is a clock ticking on everybody’s engagement in the project no matter how dedicated and we need to take that into consideration to be able to bridge the gaps and continue doing amazing things. Anyone with an Internet connection and a computer can contribute. We need to harvest that force.
Due to this churn, we need to ensure a steady income of contributors. We need to to help with onboarding anybody new who is interested, and guide them through the difficulty of becoming “one of us”. We need people that we can leave the house to when life pressures us to leave for any reason.
Maybe you’ll say - why do I need to bother with this. I like to hack. I like the thrill of finding the way to make something work, the elegance and speed that it will present. I like writing code and I already do so much by coding for this project, why should I bother with helping others? There was no one for me at the beginning and I am still here.
And all the respect for that, I hear ya. I totally get it. But! Studies find that we are less likely to help someone that we have been in the same shoes with. They call it “the empathy gap”. We have struggled and pushed through the other side, and now when here the past looks easy and like no big deal. Usually, we are wrong. We have also stood on the shoulders of giants, and now it is the time to offer ours.
The new perspectives and the multiplied coding power can only help what we are doing. Some practical steps for a good newcomer integration could be:
Beginner bugs - they don’t necessarily all need to be with beginner coding level, just out there on the open so people can catch one easily. It saves lots of communication and reduces the possibility of the new interested person to feel overwhelmed and intimidated.
Open communication channels - but only if you mean it! Whether it’s mailing lists, IRC, some other arrangement, make sure you are responsive and there. Create as many mailing lists as you want, or as many channels, as long as there is one that people will regularly monitor and be there on, and it’s clearly stated on a visible place that is so.
Review code - but for real. Don’t leave patches in the tracker forever. If you have no ability to do so in the moment, make it clear, as well as waiting times. Newcomers will be thrilled to have submitted something and to see it integrated. Make them feel happy and like they are needed!
Invite new people to already established events - we live and do most of our work on the Internet. We read sentiments between lines and we interact with IRC nicks. Do you remember your first conference? What all of those IRC nicks suddenly became faces and real people? I bet that when you were reading the mailing list after you could totally understand the tone of the person posting better, and everything just made more sense. Even your idols, the ones you admired for their brilliance and often saw their names on various places around the project, became closer and more tangible, real people. Invest in helping your newcomers financially to attend your events. Crowdfund, ask the sponsors specifically (it’s good for them as well) or any other way that you can think of. Meeting the greater community will make the new people feel more like they belong and that their presence is cherished.
Become part of the programs like Outreachy and Google Summer of Code. Mentorship is a great way to build up the contributor base, and gives visibility of the project to people who might not have naturally found it or became attracted to it.
Diversity of contributions - as we said: Anyone with an Internet connection and a computer can contribute. Create infrastructure so people can help you with writing the documentation, create great designs, help you out with marketing and outreach. This is really, really important. Just a few projects utilize the force that is out there and does not necessarily write code. For me, this is one of the surest ways to keep a project growing.
Maintaining vision and values
Except welcoming the new people, we need to pass them on something. What have we been building all this time? What kind of values have we been standing behind and what is our mission?
I feel like this part has the most to do with retention of the people that will come to us.
Striving for excellence of code could mean more tedious work for the people who are new. We can balance this inequality by offering a sort of a mentoring and more diligent code reviews. This is applied everywhere - in passing on and with that maintaining the vision and values it will more be a game of equal propagation of the old and the new - the project is made by the community, and the community is composed of the ever changing contributor base. The zeitgeist of that community would be important to follow. And we will need to equally give and take.
In order to successfully pass on the the pillars of what the project was built upon and still standing on, transparency is crucial. Don’t make decisions behind closed doors and just serve them. In order for people to feel like they belong, they need to feel informed and included in every aspect of the projects. Although is important for the maintainers to preserve the standards and sometimes make some unpleasant decisions like refusing patches, they are not gods.
When referring to company cultures Businesses Researchers say that the culture is set by the first employees in the company. In order to build a respectful and productive environment, attention to the culture element is super important from the very beginnings. It is never too late to revise behaviour and improve it and that should be done often, but establishing a healthy organisation gives us a tremendous advantage.
A culture of respect helps us code better!
“Our results show that the level of politeness in the communication process among developers does have an effect on the time required to fix issues and, in the majority of the analysed projects, it has a positive correlation with the attractiveness of the project to both active and potential developers.” - Would you mind fixing this issue? An Empirical Analysis of Politeness and Attractiveness in Software Developed Using Agile Boards. May 2015.
What comes handy to help that kind of environment built is processes. Although the direct correlation of processes and culture seems unlikely from the start, good processes are the backbone of healthy organisations and productive settings. Defining clear and effective steps to go about any kind of potentially confusing and problematic task is a gatekeeper of peace.
In short: It is our responsibility to set standards of code excellence and respect and help the community adopt them and improve them further, by leading by example. People will stick around only if they feel like they belong, so we need the perfect balance of flexibility and assertiveness. The only way to do this is to listen.
Keeping an open ear for the users
While we are at the topic of listening, we come to the third part, and that is keeping an open ear for the users. The general sentiment of the talk is centered around the contributor as the nucleus of the project, but I didn’t want to miss out to address the importance of user feedback.
A big percentage of us go into free software to “scratch their own itch”. We have a need and we have the skills to provide ourselves with what we need, so we set off into the adventure that is making it. That combined with our general enthusiasm to hack and solve problems, mainly by giving instructions to our machine, can keep us a bit disengaged from what other users need.
As power users we can easily forget that things are not as intuitive to the general public as they are to us. I see this constantly happening with some brilliant free software that is made. The diversity in contributions play their crucial role here - design and UX contributions are rare in free software, but are very much needed. If we make our software more usable, our user base would grow, which will expose us to more people, and we’ll get more contributions. The cycle of excellence! If there are no designers or UX contributions around, a good way to get in touch with what the users want is to read forums, or answer support questions.
Plus, always keep in mind that the biggest percentage of your new contributors lays in your user base. Take advantage!
Conclusion
There is much more than the code to a successful project. We are driven by the desire to create and build, and retained by the sense of community and belonging. We need a respectful and welcoming culture to thrive and grow together with the project.
As Henry Ford said:
“Coming together is a beginning, keeping together is progress, working together is success.”
I really believe in the idea of free software and joyfully spend all the time I can in it. I admire each and every one of the people who gather to make things together, who stand behind the principles of sharing knowledge and open standards. I believe we have enough power to change the world, and we can do that one successful project at a time. Let’s get to work!