Humans of Open Source
•Télécharger en tant que PPTX, PDF•
0 j'aime•47 vues
Presented by: Christian Bromann, Sauce Labs Presented at All Things Open 2020 Abstract: Every open source project has its own unique story to tell, whether it’s a small personal hobby program or a big corporate-funded project. A project always starts with a single person making a single commit and putting it on GitHub. From there the storyline writes itself and, if done successfully, it will highlight the most important component of open source: the people, friendships, and collaborations. Putting code on an open platform like GitHub is easy. There is almost no friction when you iterate on your first versions of your new open source project. However once it grows and more people start using it, it often feels overwhelming when they start filing issues and requesting your support. This often leads to maintainers abandoning their projects as they get burned out and users becoming frustrated when they have to transition to a different framework. People often forget that building a community around an open source project is just as difficult and important as the solution that the project provides. In this talk, Christian Bromann will share his experience of building a community around an open source project. He will provide various tips and tricks that help guide you through the difficulties of acquiring new contributors and will teach you important lessons he learned along the way. At the end of the session you will walk away with actionable ideas that you can apply to your own open source projects.
Recommandé
Recommandé
Contenu connexe
Similaire à Humans of Open Source
Similaire à Humans of Open Source (20)
Plus de All Things Open
Plus de All Things Open (20)
Dernier
Dernier (20)
Humans of Open Source
- 1. HUMANS OF OPEN SOURCE Christian Bromann - Senior Software Engineer
- 2. At my first conference I felt like being backstage at a festival full of Open Source artists. There were always these moments where you would get star- struck if you would see that person, who built that library, working at that big tech company. However, getting into casual conversations with them make you realise that they are just normal people like you or me. Being a passionate Open Source developer then eventually even brought me in situations where I would work with the same artists on a project together. It is fascinating how many doors just open magically when all you do is tinkering on a hobby project and share your passion with others. And the fact that this experience is accessible to everyone if the community is built with good ethics is the best part about it. “
- 3. WEBDRIVER.IO Next-gen browser and mobile automation test framework for Node.js. https://twitter.com/Paztoya_/status/1230588731779932174/photo/1
- 4. TYPES OF OSS PROJECTS SOLO One or two developer responsible for a whole project MONARCHIST all decisions are made by the project lead and a small number of "lieutenants" COMMUNITY A lot of contributors who run the project democratically as peers. CORPORATE Run by a private company but not completely alienated from them FOUNDATION incorporated with officers and directors and all decision- making formalized
- 6. INCLUSIVE OPEN SOURCE PROJECTS DOCUMENTATION There are well written contributing guidelines SCOPE A project has a reasonable set of functions and features COMMUNITY A welcoming language for contributions is being used TECHNOLOGY A project uses common known tools and frameworks
- 7. I was selected to present at SeleniumConf in London about an entirely different topic and during my presentation I had shown some examples using Selenium to drive iOS devices. Several people came up to me after the talk and were more interested in the iOS demo than what I was actually presenting and one of them said I should do that demo as a lightning talk later in the conference. So I signed up, and the next day I took the stage. The lightning talk host had mentioned in the rules for the talks that speakers had 30 seconds to get their presentations going or they'd be passed over for the next speaker. As my luck would have it, my MacBook didn't like the projector. The host started a countdown and just after he said, "1" the presentation finally showed up on the projector and the rest is history. A few months later the same lightning talk host would form a group to start a new open-source project based on the demo I gave at the conference and 8 years later, Appium is still going strong. “ Dan Cuellar Engineering Manager
- 9. Context is everything. Your brain does not do absolutes. Your brain only does relationships. That’s all it ever does and that’s all it can ever do! —BEAU LOTTO “ “
- 10. CONTEXT IS KING
- 11. CONTEXT IS KING
- 12. CONTEXT IS KING ● A short description of the current and desired state ● Link to code that is objective to change ● Including related issues if possible ● Link to contributing guidelines for specific code area ● Proper labelling
- 13. BE HELPFUL! ● Always provide constructive comments or NON at all ● Don’t lose your kindness in all the interactions you make with the community ● Take a break if you feel burned out ● Document question patterns (FAQ)
- 14. I want to look back at my life at any point and feel generally positive about what I’ve done: what I’ve built, who I’ve interacted with, how I left them feeling. —JORDAN HARBAND // @LJHARB “ “ https://github.com/readme/jordan-harband
- 15. # COMMUNITY HOME Build a striving and strong community by providing support and help throughout multiple communication channels!
- 16. My first introduction to the energy and vitality of open-source communities occurred, when I had an opportunity to attend the Selenium conference in Boston. I'd been working with Selenium for several years, using Java or C#, when I first got started with a WebdriverIO project. Having developed a framework , gotten a taste for the power and flexibility of using JavaScript for UI automation, and worked through several WebdriverIO version upgrades, I discovered that not only was the Gitter WebdriverIO channel a great resource for knowledge exchange for the community, but that I was often able to answer questions on the channel. This further increased my confidence and deepened my own understanding of the project structure. Eventually I was able to commit a few changes to the project. Throughout, I've enjoyed the chance to chat with and get to know WebdriverIO users from all over the world. “ Olga Smolyar Quality Development Engineer
- 18. PRAISE CONTRIBUTIONS @MindfulTestDev Am I officially an open source contributor?? @webdriverio. I should add this to LinkedIn. It has never been easier to contribute to open source. What an honor... @webdriverio @pako_88_ https://twitter.com/MindfulTestDev/status/1280956298771783681 👏 https://twitter.com/pako_88_/status/1280953744465825792
- 19. PAIR WITH THE COMMUNITY Vinod Reddy I am always curious to work for the open source projects. I think the time has come. My first PR got merged today to WebdriverIO project. Though I started with a small one, I know I can do a lot there. https://www.linkedin.com/feed/update/urn:li:activity:6712385032478167040/
- 21. JOIN A FOUNDATION # 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
- 22. Make 10 different shelters with this old tire, some wood and a piece of rope. This kind of design exercise tests resourcefulness, and encourages you to think about the nature of the individual components and what happens as they combine. To me, working in open source & open standards is very much like that sort of puzzle. We may use the same tools - people, process, policy, code, etc - but the results can look a lot different. This industry has helped me appreciate this quality and work in a more systemic way; less like an engineer, more like a painter: “How do tools combine to solve the immediate problem, and also celebrate differences and respect surrounding context?” It’s creative, rewarding, and not without frustration or failure. You have to be willing to work on multiple timelines, try new things, and change your perspective. And patience helps. “ Jory Burson Open Source, Open Standards, and Open Engineering Advisor
- 23. THANK YOU! Christian Bromann Sr. Software Engineer at Sauce Labs christian-bromann @bromann
Notes de l'éditeur
- 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
- So yeah, this is me and my story is as follows … The hobby project that I mention here is WebdriverIO
- 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
- 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
- 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….
- … 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 ...
- 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
- 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...
- … 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
- 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
- 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
- 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
- Another lesson I learned is to be helpful and kind even in stress situations Explain graphic…
- 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
- 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
- One person that became a very strong supporter on the WebdriverIO channel is Olga Her story is the following ...
- Another story from Kevin a technical steering committee member is the following ...
- 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
- 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
- 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
- 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
- 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
- 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 ...
- With this fantastic story I would like to thank everyone for listening Thank you so much!