Open Source: Working in a Glass Walled Factory
-
Upload
stephen-james -
Category
Software
-
view
218 -
download
0
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/