Practices Perfected In OSS Can Reshape Enterprise Development

npm, Inc. helps more than 3 million open source developers build communities, learn, collaborate, and ultimately publish software that’s used by many of the largest companies in the world.

I believe that this open source development process works. Some great studies back up this belief: In their 2015 article InnerSource: Internal Open Source at PayPal, PayPal describes introducing open source practices into their engineering culture, and the results are exciting:

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.

In this post I focus on tooling, one important aspect of the open source process:

how developers interact with a community to discover best practices, and in turn find the best tools;
how this ad-hoc standardization process puts developers in a good place to automate all the things.

I’ll conclude by discussing the steps that npm On-Site and other industry leaders are taking to bring these open source tools and practices into the enterprise.

Best Practices are Community Driven

It’s amazing to watch best practices spread across OSS communities. Just a few years ago, projects rarely had unit-tests; now unit-tests are one of the first things folks look for in a healthy project. Developers learned running large open source projects that writing descriptive unit-tests was a great habit: It helped people familiarize themselves with codebases, and prevented regressions as new features were added.

How do good habits like unit-testing spread? There’s a wonderful feedback loop created by the social sites where people share and discover code:

npm’s website maintains a list of most-depended-upon modules, getting a module on this list is a great motivator for module builders. But how do developers get on this list? 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. This process means habits and best practices spread quickly across the whole community.

Badges are a great example of this process:

![Build Status][travis-image] ![Dependency Status][gemnasium-image] ![Coverage Status][coveralls-image]

Among the first things developers look for in a healthy OSS project is a set of green badges along the top of its README documentation. These badges emerged organically from the developer community to indicate qualities including passing unit-tests, healthy code coverage percentages, and up-to-date project dependencies. The emergence of badges has, in turn, lead to better software development practices in the community. So cool!

Best Practices Center Around Great Tools

As effective development habits spread across the community, developers start to converge on the tools that best facilitate these practices. Let’s look at the top 10 modules listed on the npm registry:

10/10 are published to npm.
10/10 host their code on GitHub.
9/10 run their unit tests on Travis CI.
3/10 use coveralls.io for tracking test coverage.

As the developer community arrives at a standard set of tools, incentives grow for these tools to work together elegantly.

Consider one average workflow of an npm module developer:

a user pushes code to GitHub and creates a pull request;
a build kicks off on Travis CI, installing modules from npm, and running tests;
the GitHub pull request is automatically updated with status messages from Travis CI and Coveralls;
upon build completion, coveralls.io maintains a history of coverage information, and will fail a build if this coverage decreases;
once the pull request is merged, the package is published to npm.

Various checks and balances automatically ensure code quality along the way — and at the end of the day, all of our badges remain green.

With the right set of tools, tasks that were once frustrating and manual — e.g., making sure that a pull request doesn’t break your project — become fun.

Do you think that Open Source practices apply well in the Enterprise? Are there other useful tools that make your development workflow better? I would love to hear from you.