Managing an internally-sponsored, open source project

1. Working in a Glass
Walled Factory
Managing an internally-sponsored, open source project
Stephen M. James • @tweetllama • DevWorkshop 2015

2. Survey of audience

3. Why?
open-sourcing an internal project

4. Prestige & reputation of being forward thinking
and contributing to the community
Prospects may already be familiar with part of
your codebase

5. Increased usage cases and coverage
rare bugs found more quickly
To further your own job prospects
publicly proven track record

6. 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.

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

8. 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.

9. Introduction

10. A UI library of jQuery plugins

11. My

12. Know your audience

15. What is the business goal
of your project?

16. Open source = drive thru?

17. Our default was not recommended.
WAT!

18. Change all your declarative markup?
Easy isn’t always best for internal clients.
Optional dependencies?

19. Is this a side project?
Or an essential part
of your company or department?

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

21. Creation is an intrinsic motivator.
Maintenance usually requires
extrinsic motivation.
If only code documented itself
clearly and released itself.

22. Chores

23. Facilitation
Who’s going to be responsible
for this project?

25. Am I really following semver?

26. 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.

27. When to break things

28. @oskay

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

32. Pull request your own code
or at the very least diff it

34. Make the “right” way,
the easy way
structure and branching example

36. Write tests, and hook up to
continuous integration
free licenses for travis, saucelabs, etc.

37. Be humble.
Be open to being wrong.
Easy on the guilt there buddy,
this is software.

38. Project health + personal health
issue resolution, dependencies, complexity,
monitoring for open source

39. IsItMaintained.com

40. Bithound.io

41. Be nice
“I don’t have to time find the previous issue”
instead of berating

42. The project has arrived...
Now how do I sunset it?
Communicate the path forward
to the community

43. 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/