Humans of Open Source

Editor's Notes

• #2: Hey everyone, thanks for joining the talk Thanks ATO for having me! And Good morning! I am Christian Bromann - Senior Software Engineer at Sauce Labs working in the Open Source Program Office there If you have any questions during the talk please post them in the chat, we might not have enough time for a Q&A ...Alright Today I speak about Open Source and would like to highlight the Human aspect of it If you are a person working in OSS you are certainly not only writing code - you are also working with humans within a certain community Something that I find personally the most exciting about it I am a big fan of Humans of New York And you might have noticed that the title and the cover slide is aligned to that theme While the focus of my talk will be to share some experience on how you build an OSS community I also would like to highlight some OSS stories of people I’ve met over the years and appreciate for their work in the OSS community Starting with myself
• #3: So yeah, this is me and my story is as follows … The hobby project that I mention here is WebdriverIO
• #4: I started using it as I had to test a SPA as part of a university project Soon enough I would apply it to more projects even outside of my university And started running into issues, bugs and the need for some enhancements I started looking into the source code and tried to wrap my head around how it was all put together Eventually I made my first PR which helped me to transition from an OSS to an OSS contributor
• #5: If you would characterise OSS projects you could put them into 5 different buckets WebdriverIO was the typical Solo project Which is the type of project that almost 80-90% of all projects are Where there is one or two developers responsible maintaining it Now, almost 8 years later WebdriverIO has become a Monarchist all decisions are made by the project lead and a small number of "lieutenants" It just needs a bit more active contributors to make it a Community project: Selenium A clear governance structures the collaborator into a technical leadership team and a project leadership team Decisions are made democratically at all times Cooperate: React The roadmap of these tools is dictated by the corporation behind them While there are corporate projects that are more collaborative in roadmap discussion At the end of the day the company has the last word Foundation: GraphQL, Node.js All decision making is formalized Consensus is found by a set of diverse people affiliated to different companies … Building communities is different depending on the type of OSS project you maintain
• #6: When a Open Source project gets created the person or people behind usually start with specific goals and expectations Just a small hobby thing that you put on github This will probably always stay a solo project if the contributor doesn’t find collaborators and interested people To help grow to a monarchist or community project On the other side Corporate projects are funded by companies and rarely try to build up a contributor base The ones that do are likely to to transfer the project to a foundation For projects that look for contributor, the first problem to tackle is….
• #7: … to make a project inclusive Inclusiveness in tech has its special role already It can fill a whole talk by itself It this context it means to allow contributions not only from senior developer and experts in the field but also from junior devs and people starting in OSS There are really 4 essential factors that make your OSS project inclusive SCOPE To keep the barrier low of understanding the codebase it often makes sense to split code into multiple sub packages / projects To keep the set of features and functions at a reasonable size Reducing the cost of onboarding to a large problem space TECHNOLOGY It’s of course always great to use latest and greatest from the language ecosystem E.g. adding TypeScript to your JavaScript project or introducing a cool build dependency that works on Mac but not on Windows Be aware that certain technology choices might be good for the project but harmful for a community as people either have to learn something new or are faced with setup challenges that are just too difficult to solve DOCUMENTATION While it is not only important to have good user facing documentation It is as crucial to also provide well written contribution guidelines that explain what contributions you are looking for and how they are suppose to be made COMMUNITY Invite people to join a project and don’t take it for granted Show gratitude in PRs and praise contributors for their work It is one thing to give a 👍 on a PR But a whole different if you write a personalised thank you text for a first contributor in order to keep that person engaged Once you have a more inclusive project you have to go out and tell people about it ...
• #8: Someone who has a very interesting story about how he showed people a new project is Dan Cuellar (Eng Manager at Apple) has a really special story about this … What Dan didn’t know when he decided to give this lightning talk about this little hack he worked on was that It was the foundation of a project that even 8 years later is a defacto standard framework for mobile automation and a core business feature of many companies in the testing space
• #9: Now that showed your cool project to people and got them interested, it’s time to collaborate When you started working on the project as a single contributor to created a lot of context from certain problem spaces to specific code areas If you have been working on a code base for a while you exactly know where in the code to look at when fixing a certain bug This knowledge has to be documented...
• #10: … Beau Lotto said to this … Future collaborators might see all the information by looking at the repo, the code and the problem space - but these are useless As long as they can’t refer to the context, contributors have no access to what they are looking for So as maintainer we have the obligation to not only document bugs - but also provide context to it
• #11: Here is a great example from myself in the past The thought line back then was: add support to the jasmine framework, just look how it was implemented in Mocha and make it work in Jasmine It expects a lot of context by anyone who has not been involved in the project Without any context you can’t really expect that people will just start working on the issue
• #12: You can do this experiment by yourself E.g. if you're a web dev like me go look into the Haskell or Fortran OSS projects of NASA on GitHub Look into the source code or try to understand an issue someone has posted If you are like me you will be: “WHAT?” In a lot of companies people are buried in work and have a lot of responsibilities as well as an endless backlog of tasks They can’t invest 20hrs of self training to understand context and learn about the project They want to feel productive quickly Because Open Source is very much just like social media - a game to get rewards Getting many rewards makes it addictive Someone who has to work for hours to get a tiny reward is not gonna play the game again By providing context, doing the additional mile, we can tremendously shorten the way to reward others and reward us at the same time
• #13: Often you think, “well I can just keep this around, I just takes 10min to fix it”, I will get to it eventually Much better is if you spend 1 minute to write a proper description Link to the right code places and contribution guidelines So that it becomes almost step by step description how to solve a bug where the only context needed is reasonably low So someone else will be able to pick things up
• #14: Another lesson I learned is to be helpful and kind even in stress situations Explain graphic…
• #15: I love this quote from Jordan (TC39 member) which reminds me about these situations … read quote If you feel burned out by the amount of work, having the additional burden of open source can just feel like the last straw I have learned that this is a red flag and means to take a break, stop doing what you are doing
• #16: Another way to build up a community is to give them a home Where you can offer support and have regular conversations with the user This can be very time consuming in the beginning but pays off once the community has reached a certain level and size At some point people automatically support each other without you being needed to interact anymore Believe it or not but some people prefer to spend 30 min throughout the day in the support chat to help people out rather than contributing code Support on this level is very appreciated by users Gitter or Slack are very common chat applications but don’t restrict yourself just to the obvious ones People will always prefer their favorite communication channels
• #17: One person that became a very strong supporter on the WebdriverIO channel is Olga Her story is the following ...
• #18: Another story from Kevin a technical steering committee member is the following ...
• #19: Which brings us to chapter 3: lead and inspire Once you have build a little community , there are usually only a handful people that really active and lead the project These people have to inspire the community with their actions by giving back It is important to give back success moments to reward people for their engagement This increases incentives to continue contributing
• #20: One of such things that is easy to give back and reward contributors is to invite them to the github org There is really no reason to close up your project organisation and make it an inclusive club In the WebdriverIO project everyone who makes some sort of significant contribution will be invited to the WDIO org This is defined in the governance Compared to before these users now have triage access to all repos There are other projects that even give first time contributors full write access For a maintainer that might sound scary in the first place but people are very unlikely to abuse that power Provide information about the trajectory of contributions and the role of users in the project It’s similar to any other job where people want to know what their career path might look like
• #21: Another excellent utility to give back to the community is to offer Open Office Hours It is a bit more time consuming than other initiatives but can be very powerful Use the calendly app to block certain hour slots on your calendar weekly allow people to sync with the team on certain issues This exercise has a high ROI as you Not only teach individual contributors on the codebase But also give them all context necessary to fulfil their task Important to require an issue to work on Issue list needs to be well groomed and described Otherwise time is used to walk through the code rather than actively working on issue It provides High level of engagement with individual contributors Teach contributors on the code base, provide them context and help them make more contributions with increasing complexity While it costs a lot of time it has a high ROI Different people will require different level of attention I had OOH where I had to teach people on JS and some basic programming concepts But also people that just wanted to check in where a call was done after 10min
• #22: Lastly once you have grown your community and started to impact the ecosystem with the project You can look into how to govern this at scale
• #23: One option can be to consider to join an OSS foundation There are plenty of such foundations like OpenJS Foundaiton Apache Foundation Software Freedom Conservancy … to just name a few This move can be an excellent way to ensure a safe and sustainable growth of your project A foundation can be a neutral organization to host and sustain projects, as well as collaboratively fund activities for the benefit of the community at large Foundations can support with Legal issues Marketing governance Depending on the foundation certain governance structures are required to join Helps to met a certain level of open governance (e.g. defined rules for decision making, not more than ⅓ of project leads within one company etc.) Can help to remove bus factor as infrastructure will be transferred to the foundation Can help to define growth goals and project progression stages Financially Collaboration (e.g. WebdriverIO and Mocha) However, it should never be the goal to join a foundation just for the matter of joining it and put the logo on the website It should be seen as a growth goal Applications (depending on the foundation) only make sense on a certain level of ecosystem impact Also as a member of such a foundation you should also consider to contribute to foundation level projects and help govern it which in itself can be very time consumimg
• #24: I would like to close up the talk highlighting the story of someone who I admire for all her work at the OpenJS Foundation and the W3C It’s Jory Burson who shared the following ...
• #25: With this fantastic story I would like to thank everyone for listening Thank you so much!