Open Source: Working in a Glass Walled Factory

Post on 10-Feb-2017

218 views 0 download

Transcript of Open Source: Working in a Glass Walled Factory

Working in a Glass Walled Factory

Managing an internally-sponsored, open source project

Stephen M. James • @tweetllama • DevWorkshop 2015

Survey of audience

Why? open-sourcing an internal project

Prestige & reputation of being forward thinking and contributing to the community

Prospects may already be familiar with part of your codebase

Increased usage cases and coverage rare bugs found more quickly

To further your own job prospects

publicly proven track record

Experimentation mindset and "outside" release cycle

that is, not within the company release cycle

Democratization of the code even if just internal open-source–no ivory towers.

Value-add for partners and third-parties seamless look and feel

And my favorite, the off-chance that some non-profit organization is using the code to

raise awareness of social injustice or defend the orphan, window, or alien.

Introduction

A UI library of jQuery plugins

My

Know your audience

What is the business goal of your project?

Open source = drive thru?

Our default was not recommended.

WAT!

Change all your declarative markup?

Easy isn’t always best for internal clients.

Optional dependencies?

Is this a side project?

Or an essential part of your company or department?

Are you architecting in a “white lab coat experience?”

Creation is an intrinsic motivator.

Maintenance usually requires extrinsic motivation.

If only code documented itself

clearly and released itself.

Chores

Facilitation Who’s going to be responsible

for this project?

Am I really following semver?

Semver is implicit 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 fixes.

When to break things

@oskay

I built my house on a pre-fabricated foundation called Bootstrap, how do I move it off

lessen dependency dependency

Pull request your own code

or at the very least diff it

Make the “right” way, the easy way

structure and branching example

Write tests, and hook up to continuous integration

free licenses for travis, saucelabs, etc.

Be humble. Be open to being wrong.

Easy on the guilt there buddy,

this is software.

Project health + personal health

issue resolution, dependencies, complexity, monitoring for open source

IsItMaintained.com

Bithound.io

Be nice

“I don’t have to time !nd the previous issue” instead of berating

The project has arrived... Now how do I sunset it?

Communicate the path forward to the community

Stephen M. James • @tweetllama

Let’s create a culture of learning, experimentation, and fail fast. Thanks for listenin’! Deck eventually available at slideshare.net/interactivellama/