talk I gave at AustinJS, about InnerSource: bringing the best of open source practices to your day job.

1. npm Loves You

2. npm Austin 2016 o/
Bringing Open-Source
Practices to Your Day Job
Ben Coe
@BenjaminCoe, github.com/bcoe

3. open source, a
love story
how I ended up at npm.
1

4. ▪ employee #3 at npm
▪ lead maintainer of yargs
▪ built nyc, the code-coverage tool
▪ manage npm On-Site
About Ben

5. ▪ we all have process horror stories:
▫ this doesn’t mean process is bad!
▪ @ceejbot and I came to a conclusion:
OSS Best Practices

6. ▪ process is important!
▪ process should be automated
▫ from tedium comes frustration.
OSS Best Practices

7. automate all the
things
in automation we trust
2

8. ▪ we use a variety of testing tools:
▫ mocha, lab, tap
▪ we’re not dogmatic about TDD
▫ we’re dogmatic about writing tests.
▪ everything runs with Travis CI
Unit Testing

9. ▪ eliminates the question, did you write a test
for that?
▪ we use the coverage tool nyc
▪ we use Coveralls
Test Coverage

10. var express = require('wombat')
var app = wombat()
app.get('/', function (req, res) {
res.send('Hello Log')
})
app.listen(3000) github.com/bcoe/nyc
tools should be so
simple they’re fun to
use

11. ▪ this one is controversial!
▪ ultimately, we decided:
▫ use whatever coding style you like, but
automate its enforcement.
▪ I ❤ github.com/feross/standard
Coding Style

12. ▪ the longer you wait to upgrade, the more
annoying it becomes
▪ use npm outdated
▪ greenkeeper.io rocks
keep dependencies
up-to-date

13. var express = require('wombat')
var app = wombat()
app.get('/', function (req, res) {
res.send('Hello Log')
})
app.listen(3000)
greenkeeper.io
one of my top five, all
time, favorite robots

14. ▪ npm publish --tag=alpha
▪ npm version patch -m “awesome new
feature”
▪ we run several internal npm On-Sites:
▫ private npm packages are a thing.
we’re npm power
users

15. “engineers are far more tolerable of a
pedantic robot than they are pedantic
people.”
— someone probably.

16. best practices
grow out of
community
npm’s methods didn’t originate in a vacuum
3

17. 180,000publishers
3,000,000+users
240,612packages

18. 3,395,979,161
downloads

19. ▪ unit-testing is a great example:
▫ developers learned running large OSS
projects, the benefits of unit-testing.
▪ people emulate the projects they respect:
▫ this creates a feedback loop!
how do habits spread?

20. “What works best is studying the projects of
other maintainers already on this list,
interacting with the developers, learning
from them, and emulating their
methodologies.”
— blog.npmjs.org

21. ▪ great indicator of quality.
▪ grew out of community
badges!

22. developers converge on the tools that
facilitate these practices
4 Best Practices
Center Around
Great Tools

23. 9/10 Use Travis CI10/10 Use GitHub 3/10 Use Coveralls
top 10 npm packages

24. ▪ a pull request is opened on GitHub
▪ build kicks off on Travis:
▫ installing modules from public and private
registries.
▪ a conversation begins between developers.
the npm workflow

25. ▪ pull-request kept up-to-date by robots:
▫ Coveralls reporting coverage.
▫ Travis CI reporting build status
▪ once merged, module is published to npm
▪ greenkeeper.io notifies other projects o/
the npm workflow

26. ▪ tools work together elegantly.
▪ as many steps are automated as possible:
▫ let humans do what humans are good at.
▪ it feels (a little bit) like you command a robot
army.
what makes this
awesome?

27. enterprise software, a love story
so, why do you
build Enterprise
software Ben?
5

28. ▪ restrictions on infrastructure.
▪ practices lag behind.
▪ process can be overwhelming.
developing enterprise
software is hard

29. OSS methodologies
can work!
▪ OSS practices were designed to help large
asynchronous teams work effectively:
▫ this is applicable in large corporations!
▪ InnerSource: Internal Open Source at PayPal

30. “The results were visible after 6 months. The
Checkout Platform team spends 0% of its
time rewriting code and just 10% reviewing
submissions. The team was able to do a
major refactoring and a 4x increase in
performance without planning for it. The
mindset moved from blocking change to
mentoring and coaching.”

31. ▪ InnerSource is about:
▫ developers taking ownership of repos.
▫ people taking on the role of a lead
maintainer.
▪ developers need tools that empower them.
education is important

32. ▪ good developer tools do more than deliver
an asset to a build server:
▫ there’s a real disconnect between devs
and ops folks here.
what are good
developer tools?

33. ▪ it’s about facilitating communication.
▪ it’s about discovery.
▪ it’s about automation.
▪ it’s about delivering an asset to a build
server.
what do I mean by
this?

34. Demo Time

35. InnerSource Tools

36. how are we working
together?
▪ we’re keeping our roadmaps aligned
▪ we’re looking for tighter integration points
▪ we’re preaching a similar message about
OSS in the Enterprise

37. why this is awesome
▪ OSS software and Enterprise software can
learn a lot from each other.
▪ we can make a developer’s life more
awesome.

38. thanks
any questions?
about anything?
Ben Coe
@BenjaminCoe, github.com/bcoe

39. npm loves you
♥