Fostering an "Open-Source" Culture at Work

Slide 1

Slide 1 text

#foster opencss.klamp.in FOSTERING AN "OPEN-SOURCE" CULTURE AT WORK Kevin Lamping @klamping opencss.klamp.in

Slide 2

Slide 2 text

#foster

Slide 3

Slide 3 text

http://parentprogramming.xyz any parents in the crowd? 1-hour interviews with parents in tech looking to interview folks

Slide 4

Slide 4 text

Front-end Engineer at InVision

Slide 5

Slide 5 text

#foster opencss.klamp.in OPEN-SOURCE SOFTWARE It’s not about This talk is not about open-source software and why you should use it

Slide 6

Slide 6 text

#foster opencss.klamp.in OPEN-SOURCE CULTURE It’s about It’s about open-source culture, and why it’s important to any company and/or team

Slide 7

Slide 7 text

#foster opencss.klamp.in RELY ON VOLUNTEERS Open-source projects How do open-source projects get people to volunteer their time? OSS doesn’t have a big budget

Slide 8

Slide 8 text

#foster opencss.klamp.in ARE DISTRIBUTED Open-source projects Most open-source projects don't have dedicated, co-located teams. How do they cope?

Slide 9

Slide 9 text

#foster opencss.klamp.in STRUGGLE WITH SCALE Open-source projects How do they support their ever growing user base while staying adaptable? A projects success can also be its demise

Slide 10

Slide 10 text

#foster opencss.klamp.in DO QUITE WELL Open-source projects While there are a million OS projects that fail, many are outstanding successes, because they overcome the problems they face and are stronger for it.

Slide 11

Slide 11 text

#foster opencss.klamp.in CULTIVATE AN  OPEN-SOURCE CULTURE How-to

Slide 12

Slide 12 text

#foster opencss.klamp.in REDUCE THE FRICTION TO CONTRIBUTE Open-Source Culture How do you get contributions from people who are likely already overworked?

Slide 13

Slide 13 text

#foster opencss.klamp.in PRACTICE EMPATHIC CODE MANAGEMENT Open-Source Culture How can you continue to evolve your product without causing endless headaches for those who have helped you get to where you are?

Slide 14

Slide 14 text

#foster opencss.klamp.in EMBRACE HUMAN CULTURE AT WORK Open-Source Culture Just because it's work, doesn't mean it's not human. How do you build a community that’s supportive and encouraging and avoid the politics?

Slide 15

Slide 15 text

#foster opencss.klamp.in REDUCE THE FRICTION TO CONTRIBUTE

Slide 16

Slide 16 text

#foster BETTER TO HAVE PEOPLE THINK YOU'RE A FOOL THAN TO OPEN YOUR MOUTH AND REMOVE ALL DOUBT. ??? opencss.klamp.in May have been Lincoln that said this, may have been Mark Twain

Slide 17

Slide 17 text

I do know it was said by Wilson. w. Wilson on Home Improvement though.

Slide 18

Slide 18 text

#foster BETTER TO HAVE PEOPLE THINK YOU'RE A FOOL THAN TO OPEN YOUR MOUTH AND REMOVE ALL DOUBT. Wilson W. Wilson opencss.klamp.in Idea is, assume the developers are uncomfortable/intimidated when trying to contribute code.

Slide 19

Slide 19 text

#foster opencss.klamp.in THE #1 FRICTION IS FEAR Fear of looking foolish Fear of breaking something Fear of wasting time

Slide 20

Slide 20 text

#foster “A leader’s job is to drive fear out of the organization so that employees will feel comfortable making decisions on their own. Dennis Bakke ” Assume people are uncomfortable/intimidated. Quotation from the book “Joy at Work”

Slide 21

Slide 21 text

#foster opencss.klamp.in AUTOMATICALLY FIND EASY MISTAKES Reducing fear misspelled variables names, diﬀerent coding styles, indentation… who uses tabs/spaces, single quotes/double quotes? So much variation in personal style, it’s inevitable there will be diﬀerences.

Slide 22

Slide 22 text

It’s nicer to hear from a bot that you’re wrong than a human. As a human, you’re less strict than bots, which hurts in the long run.

Slide 23

Slide 23 text

#foster opencss.klamp.in USE A LINTER Reducing fear Checks for style and code errors/inconsistencies ESLint and stylelint

Slide 24

Slide 24 text

#foster opencss.klamp.in ADD AUTOMATED TESTS Reducing fear Provides newcomers with a set of requirements to test their code changes against Allows much more conﬁdence for newcomers that their changes haven't broken anything Unit, Integration, Visual Makes your job easier, as you can have a better trust that changes won’t break stuﬀ.

Slide 25

Slide 25 text

#foster opencss.klamp.in USE “GIT HOOKS” Reducing fear pre-commit, pre-push Run tests/lint before pushing code to other humans

Slide 26

Slide 26 text

#foster opencss.klamp.in USE CONTINUOUS INTEGRATION TOOLS Reducing fear TravisCI, Jenkins Allow more immediate feedback. Catches weird things. Easier for reviews. Better trust that process was followed

Slide 27

Slide 27 text

#foster opencss.klamp.in LET PEOPLE SCREW UP Reducing fear Spend time trying to prevent it, but also spend time planning for recovery from mistakes. Expect failure. Plan for it. Embracing variability vs. Reducing Variability Reducing is good for things like code style, embracing is good for things like experimental work

Slide 28

Slide 28 text

#foster opencss.klamp.in SHOW EXAMPLES Reducing fear An example is worth 1000 technical words

Slide 29

Slide 29 text

Create a style guide, use a style guide tool Easier to get started; can copy-paste example as a starting point

Slide 30

Slide 30 text

#foster opencss.klamp.in DOCUMENTATION WON’T BE READ Reducing fear It’s tough to read all the documentation out there and not everyone has time. Also, many times people don't learn best via written documentation. If people aren't reading the docs, maybe that's a sign that you should try a diﬀerent form of documentation/training

Slide 31

Slide 31 text

#foster opencss.klamp.in STILL, WRITE GOOD DOCUMENTATION Reducing fear Docs should be more useful to the main dev team, as a quick way of pointing people in the right direction.

Slide 32

Slide 32 text

#foster opencss.klamp.in MAKE IT EASY FOR FIRST-TIMERS Reducing fear Have a list of bugs reserved for ﬁrst-timers; simple, changes with well-deﬁned requirements.

Slide 33

Slide 33 text

Kent C. Dodds introduced the idea to me via twitter and blog post

Slide 34

Slide 34 text

#foster THE HARD PART OF GETTING INTO OPEN SOURCE ISN’T THE IMPLEMENTATION, BUT FIGURING OUT HOW TO ACTUALLY CONTRIBUTE Kent C. Dodds TEXT The hard part of getting into open source for the ﬁrst time isn’t the implementation of a feature, but ﬁguring out how to actually contribute code.

Slide 35

Slide 35 text

At first this threw me off. “Only accept from first-timers?” Isn’t that a little biased (says the experienced programmer who has had the luxury of learning on the job)

Slide 36

Slide 36 text

But he addresses it well. He creates the tests that are failing, outlines the requirements, makes a list of to-do items.

Slide 37

Slide 37 text

#foster opencss.klamp.in EMBRACE NON- CONTRIBUTORS Reducing fear Time is limited, making a contribution to a big framework takes a lot of time that people with project deadlines don't have Don't fret too much about it. Be opening and encouraging, but not pushy Don't try gimmicks to get contributions. Contests only serve to undermine eﬀorts

Slide 38

Slide 38 text

#foster opencss.klamp.in EMPATHETIC CODE MANAGEMENT

Slide 39

Slide 39 text

#foster opencss.klamp.in A STORY Empathetic Code Management

Slide 40

Slide 40 text

One app, with many teams (Pardon the really poor drawings)

Slide 41

Slide 41 text

Team Stark

Slide 42

Slide 42 text

Team Lannister

Slide 43

Slide 43 text

Etc Etc TROGDOR!!!

Slide 44

Slide 44 text

Others that are interesting, but don’t really matter to the main storyline

Slide 45

Slide 45 text

Starks have been working 3 weeks on this new feature. A feature that requires some common code to behave a speciﬁc way. They’re a day away from releasing…

Slide 46

Slide 46 text

Unfortunately, yesterday, lannisters released update w/modiﬁcation to code that Team stark was expecting to work a speciﬁc way. Except it no longer does

Slide 47

Slide 47 text

Now team in scramble mode They hadn’t told the lannisters about their work (why would they need to know)?

Slide 48

Slide 48 text

Panic sets in

Slide 49

Slide 49 text

Lannister already merged and shipped the code.

Slide 50

Slide 50 text

Team is relying on those changes for the code that they just shipped. Sooo….

Slide 51

Slide 51 text

At this point, people start bracing for a long weekend of refactoring code.

Slide 52

Slide 52 text

The king is just “work the weekend m’kay” and we’ll do a “tiger team” to discuss this on 8am monday morning

Slide 53

Slide 53 text

#foster opencss.klamp.in SEPARATE YOUR INFRASTRUCTURE Empathetic Code Management This could be avoided. Issue was two-fold No one responsible for infrastructure code and communication. Infrastructure code being “pushed” out to teams “Infrastructure” could be a style guide/core JS/CSS.

Slide 54

Slide 54 text

#foster opencss.klamp.in INFRASTRUCTURE TEAM & CODEBASE Empathetic Code Management Need separate infrastructure team, even if one person, to manage changes. Need a separate codebase to manage upgrades

Slide 55

Slide 55 text

Most of the time, the common codebase gets pushed out to all the apps on update. You want to get features out there, right? So what do you do?

Slide 56

Slide 56 text

didn’t Salt n Pepa teach us to push it?

Slide 57

Slide 57 text

#foster opencss.klamp.in DON’T “PUSH” IT Separate Infrastructure Pushing code out to teams creates unexpected changes if not perfectly communicated.

Slide 58

Slide 58 text

Pushing it breaks prod. Don’t break prod

Slide 59

Slide 59 text

it’s a bad idea, open source world has ﬁgured that out. You will break prod with this model. Again and again and again. You’re pushing code out to an untested environment.

Slide 60

Slide 60 text

#foster opencss.klamp.in “PULL” IT INSTEAD Separate Infrastructure Allow the apps the room to "pull" in the code when their ready. This isn't an uncommon model. Almost all open-source projects out there follow it.

Slide 61

Slide 61 text

Teams go to the common repo when they’re ready to upgrade. So app a can be upgraded separate from app b

Slide 62

Slide 62 text

Then when app b has ﬁnished their dev cycle, they can upgrade on their own time. Package managers like NPM follow this model (unless you're using the latest ﬂag, which again, you probably shouldn't be)

Slide 63

Slide 63 text

#foster opencss.klamp.in LOWERS RISK IN UPDATES Benefits Teams able to fully regression test code, at their own pace (no weekends) Test changes with small pilot groups If something breaks due to the release, each team has option to delay upgrade until later Ability to rollback an update because infrastructure is versioned

Slide 64

Slide 64 text

#foster opencss.klamp.in FASTER ITERATION Benefits Able to release code quicker. Shortened release cycles, each version change will be more bite-sized, allowing teams an easier upgrade. Doesn't mean code isn't tested. infrastructure team should have regression tests they run. Also doesn't mean app teams on their own, or that the infrastructure team is free to make any change they want. Teams should be there for each other (empathy)

Slide 65

Slide 65 text

#foster opencss.klamp.in TAKES MORE EFFORT Drawbacks takes eﬀort for a team to pull down code, compared to it automatically being pushed to them trade-oﬀ of the model and needs to be understood and accepted as part of the deal. Easy to blame pull model; important to look deeper at the problem before abandonment

Slide 66

Slide 66 text

#foster opencss.klamp.in VISUAL INCONSISTENCIES Drawbacks hardest pill to swallow, eﬀects app end-user If your infrastructure code includes visual design, splintering versions means having an inconsistent experience across apps which are supposed to look similar.

Slide 67

Slide 67 text

#foster opencss.klamp.in PLAN FOR IT If you know you have a series of visual updates that need consistency across the site, go through the eﬀort to plan a combined release of these changes. Along with this, get in touch with the app teams and see if you can do a coordinated release for all of the apps. It does mean letting go of the beneﬁts described above, but hopefully this isn't a common occurrence.

Slide 68

Slide 68 text

#foster opencss.klamp.in PASSIVELY COMMUNICATE Empathetic Code Management Give information passively, to avoid spamming inboxes and and save time spent in endless meetings

Slide 69

Slide 69 text

https://twitter.com/sosowski/status/517005067334205441 Many ways to do versioning, including the microsoft way. Other’s include dates. But what if we can send information for free with every update?

Slide 70

Slide 70 text

#foster opencss.klamp.in SEMANTIC VERSIONING Passive Communication

Slide 71

Slide 71 text

#foster opencss.klamp.in Major.Minor.Patch Passive Communication MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug ﬁxes.

Slide 72

Slide 72 text

#foster opencss.klamp.in 0.10.35 0.10.36 Passive Communication Small patch change. Trust, but verify with automated tests.

Slide 73

Slide 73 text

#foster opencss.klamp.in 0.10.36 0.12.0 Passive Communication Larger change. Expect a little bit of work regression testing and updating code usage.

Slide 74

Slide 74 text

#foster opencss.klamp.in 0.10.36 1.0.0 Passive Communication Big change. Expect a good day or two to upgrade.

Slide 75

Slide 75 text

#foster opencss.klamp.in NODE STABILITY INDEX Passive Communication Allows you to introduce new components with a disclaimer. Add index with component documentation.

Slide 76

Slide 76 text

#foster NODE STABILITY INDEX 0 - Deprecated 1 - Experimental 2 - Unstable 3 - Stable 4 - API Frozen 5 - Locked Can have an experimental component live next to a stable one Allows more ﬂexibility

Slide 77

Slide 77 text

#foster opencss.klamp.in UPDATE OFTEN Passive Communication Update regularly, otherwise it’s meaningless and not worth it. Mgmt might also not like it b/c it reveals a certain amount of hesitation around code :/

Slide 78

Slide 78 text

Another form of passive communication is changelogs Change log is a ﬁle which contains a curated, chronologically ordered list of notable changes for each version of an open source project. Make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.

Slide 79

Slide 79 text

#foster CONVENTIONAL CHANGELOGS (): autogenerate from git commit messages

Slide 80

Slide 80 text

#foster CONVENTIONAL CHANGELOGS fix(pencil): stop graphite breaking when too much pressure applied Patch Release

Slide 81

Slide 81 text

#foster CONVENTIONAL CHANGELOGS perf(pencil): remove graphiteWidth option BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reason. Major Release (big breaking change)

Slide 82

Slide 82 text

#foster opencss.klamp.in EMBRACE HUMAN CULTURE AT WORK

Slide 83

Slide 83 text

#foster opencss.klamp.in DON’T BECOME GOOD AT MEETINGS Embracing Human Culture These behaviors build silos by keeping communication hidden. Anyone not at a meeting won’t know the information.

Slide 84

Slide 84 text

#foster opencss.klamp.in CLOSED-SOURCE CREATES SILOS Embracing Human Culture Unless publicly recorded, meetings and emails are “closed-source”. Meetings & emails don’t scale. This creates silos of information.

Slide 85

Slide 85 text

#foster opencss.klamp.in SILOS FOSTER POLITICS Embracing Human Culture Silos encourage politics & discourage outside voices. Becomes more about who you know than what you can ﬁnd out. How is someone supposed to help when they don’t know the details? Communicate in the open, via github, chat rooms, message boards, publicly recorded hangouts

Slide 86

Slide 86 text

#foster opencss.klamp.in HAVE A PUBLIC CHAT ROOM Embracing Human Culture Slack/Hipchat/gitter.im Chat history that’s searchable Easier for quick discussion. Team can help out, instead of an individual. People can lurk. Allows for distributed/remote work

Slide 87

Slide 87 text

No content

Slide 88

Slide 88 text

#foster opencss.klamp.in PRIORITIZE IN THE OPEN Embracing Human Culture Work as if you’ll never meet your users face-to-face in real life. Follow a “remote-ﬁrst” model. https://www.getdonedone.com/remote-ﬁrst-approach-workplace/

Slide 89

Slide 89 text

workingon.co, waﬄe.io, trello.com

Slide 90

Slide 90 text

#foster opencss.klamp.in COMMUNICATE PRIORITIZATION Embracing Human Culture Some people assume that because you're in the same company, you have the same priorities as them (and will therefore do their work for them). You (and your management) need to have a strategy for this. If not, all new work will halt while you hand-hold teams.

Slide 91

Slide 91 text

#foster opencss.klamp.in GROW THE BACKLOG Embracing Human Culture Don't fear an endless backlog. It's okay to have too much work to do. It’s better to track the work than forget it.

Slide 92

Slide 92 text

#foster opencss.klamp.in LEAVE TIME TO WRITE Embracing Human Culture Blog posts. Weekly ‘write ups’. A-ha’s. Keep a history of why decisions were made, you'll forget why a month later otherwise when someone asks.

Slide 93

Slide 93 text

Example blog post from the lead maintainer of EmberJS. Will be handy reference for future prioritization.

Slide 94

Slide 94 text

#foster opencss.klamp.in CODE REVIEW TIMELINES Embracing Human Culture If you know you don't have time to review a PR right away, make a quick comment saying so. Everyone understands people get busy Bigger PRs require more time, and likely more cycles of feedback. Make sure both sides understand this. Same for emails/other communication

Slide 95

Slide 95 text

#foster opencss.klamp.in CONSTANTLY SEEK FEEDBACK Embracing Human Culture People have a tendency to hold back “small things” until the become big. Talk about importance of “small things”. It takes time to build rapport with contributors.

Slide 96

Slide 96 text

#foster opencss.klamp.in BE THANKFUL FOR CRITICISM Embracing Human Culture Story: I asked for feedback on a change, didn't receive any, until someone commented the change will "suck the soul out of the codebase" I could be upset about the rudeness, or I could be empathetic towards the person. Most (myself included) want to hide feelings; hold them in until they can't It may feel good/righteous to call someone out, but it doesn't promote a healthy project ecosystem

Slide 97

Slide 97 text

#foster WE’VE PAID PEOPLE FOR THEIR HANDS FOR YEARS, AND THEY WOULD HAVE GIVEN US THEIR HEADS AND HEARTS FOR FREE IF WE’D ONLY ASKED. Bob Chapman, Truly Human Leadership opencss.klamp.in Contributors are volunteers when it comes to their ideas. You can't force good behavior. You have to foster it.

Slide 98

Slide 98 text

#foster opencss.klamp.in BE A GOOD OPEN- SOURCE CITIZEN How to If you’re not an maintainer, you can still contribute well

Slide 99

Slide 99 text

#foster opencss.klamp.in READ THE DOCS Be a good open-source citizen read the contributing guide, changelogs, etc If they suck, contribute your own (or at least mention it as an issue)

Slide 100

Slide 100 text

#foster opencss.klamp.in ASK IN THE OPEN Be a good open-source citizen ask questions in the open (chat rooms, forums) if you’re comfortable lurkers, latecomers beneﬁt Automatically turned in to “docs” (if chat history searchable)

Slide 101

Slide 101 text

#foster opencss.klamp.in TEST CHANGES Be a good open-source citizen Hardest part of updating is testing Test on your machine, for changes you (or others) have made Needs lots of Quality Assurance

Slide 102

Slide 102 text

#foster opencss.klamp.in PROVIDE FEEDBACK Be a good open-source citizen Make sure there is a good rapport Be objective with feedback Talk with feelings: “this change gives me a weird feeling” (non-judgemental, doesn’t say that it’s wrong, just that it feels wrong)

Slide 103

Slide 103 text

#foster opencss.klamp.in CONTRIBUTE YOUR BEST Be a good open-source citizen Don’t worry about contributing what’s “most needed” We need passionate people Find what motivates you and chase it Don’t prioritize for the project owner, prioritize for yourself

Slide 104

Slide 104 text

#foster opencss.klamp.in BE PATIENT & GIVE HUGS Be a good open-source citizen Don’t have to be physical hugs; it never hurts to say thanks and show appreciation, or be an empathetic ear to a maintainer who needs to vent

Slide 105

Slide 105 text

#foster OPEN-SOURCE CULTURE SUMMARY ▸Reduce friction to contribute ▸Practice empathetic code management ▸Embrace the human community ▸Be a good open-source citizen

Slide 106

Slide 106 text

#foster opencss.klamp.in RESOURCES openresources.klamp.in

Slide 107

Slide 107 text

#foster RESOURCES BOOKS ▸ Creativity, Inc ▸ Joy at Work ▸ Why Motivating People Doesn't Work… and What Does

Slide 108

Slide 108 text

#foster RESOURCES TOOLS ▸ eslint.org ▸ stylelint.io ▸ travis-ci.org ▸ semantic-release ▸ conventional-changelog ▸ wafﬂe.io/Trello ▸ Gitter.im

Slide 109

Slide 109 text

#foster RESOURCES PODCASTS ▸ Preaccident Investigation ▸ The Future of Work ▸ Western Devs Episode: Internal Open Source

Slide 110

Slide 110 text

#foster RESOURCES LINKS ▸ The Pull Request Hack ▸ Turds aren’t always turds ▸ Using Open Source Methods in a Private Company ▸ Internal Open Source: Changing Internal Culture For The Better (Presentation) ▸ Bring Kindness back to Open Source ▸ First-Timers Only ▸ And more at http://openresources.klamp.in