Running OSS Projects: From Zero to Sixty
CSS JavaScript HTML
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
css
img
js
lib
plugin
.gitignore
README.md
index.html

README.md

View Now License


Running OSS Projects: From Zero to Sixty

Glimpse, an open source web application diagnostics tool, went from a rough back-of-a-napkin idea to a project with tens of thousands of users and developer media attention within a period of eight weeks. Join Glimpse’s co-founder, Nik Molnar, for an honestly raw tale of the pains and lessons learned that arose managing an open source project. Along the way, Nik will cover the tools and techniques that have proven successful over the past two years developing Glimpse, focusing on technical challenges and best practices for community management, communications and open source/life balance.This session is suitable for founders, maintainers, contributors and all users of open source software and aims to spark conversation around the best way to foster open source and open source etiquette.

Outline

Introduction

  • Who I am - quick introduction to who I am, what I do and my background.
  • I do OSS for a living, but I don't have everything figured out
  • Giving this talk because I wish I had it 2 years ago. Does not mane that your project will be successful or have a ton of users, but this should reduce pain in case that does happen - still be pragmatic.
  • Why are you in OSS? Linus law...
  • How I started in OSS - overview of the Glimpse story and the ensuing onslaught after the Hanselbump
    • Video from Channel 9
    • Pictures from Mix
  • Introduction to Tuckman's Stages of Group Development
    • Forming
    • Storming
    • Norming
    • Performing
    • Icons and Instructional Chart
    • OSS is special because the team is constantly churning - so there are always people in each of these stages.

1 Forming

1.0 Selecting a License
1.2 Project Setup
  • Whats your URL from Hanselman story
  • Mission statement/readme.md that expresses the goals of the project and what it will/won't do
  • Developer guidelines
  • Demo/screenshots!
  • Forkability - the ease of which a developer could fork the project which also makes it easy for them to grab the code, build it and get started
  • Keep as many dependencies in source control/package restore as possible
  • Single command build process
  • Developer documentation
  • Forkability helps to ensure distributed leadership
1.3 Selecting a Governance Model
  • Meritocratic Governance Model or benevolent dictator.
    • It is no surprise, therefore, that meritocratic project management committees and benevolent dictators both exercise their decision making power through loyalty rather than legalities. They all know that members are free to take the code and create alternative projects. In fact, this ability to fork is very important to the health of open source communities. This is because it ensures that those involved in project governance strive to make the right decisions for the community, rather than for a single individual or company.
    • YUI as an example

2 Storming

2.1 Communication
  • Incoming: Forums, Mailing Lists and Issue Tracker
  • Outgoing: Blog and social media
  • Internal: HipChat, Trello and Skype
  • Avoid private/internal communications
2.2 OSS/Life Balance
2.3 Dealing w/ $$
  • Mix offer & why we really did Glimpse
    • Money is not evil. OSS and Money can and do go together.
2.4 Nom de plume
  • My story of having issues with Anthony - Even happy/nice emails have turned bad because of past carelessness.
  • the only thing anyone knows about you on the Internet comes from what you write, or what others write about you. You may be brilliant, perceptive, and charismatic in person—but if your emails are rambling and unstructured, people will assume that's the real you
  • On the Internet, nobody knows your a dog
    • Your avatar and handle are your face - try to be consistent
    • User proper grammar, spelling and punctuation
    • Consider subject/title lines carefully
    • Use a diagram if it will help! (AsciiFlow & WebSequenceDiagrams)
    • Provide context! Use a link to another thread or an issue . Make it easy for the reader
    • Edit twice for anything larger than a paragraph
    • Watch your tone
    • Avoid bike shedding and holy wars

3 Norming

3.1 Automate Everything
  • Including community management!
    • CI/GitHub integration
    • StyleCop
    • Documentation, leveraging the wiki?
3.2 Community Management

4 Performing

4.1 Sponsorship
  • TeamCity at CodeBetter
  • RedGate
  • JetBrains
  • MyGet
  • GitHub
  • Atlassian
4.2 Create Opportunity
  • Jump In
  • Automate standards enforcement
  • Thank contributors as loudly as possible
  • Story of Stephen's name on Hanselminutes

5 Adjouring

Conclusion

Not running a project?

  • Pay it forward. Can't contribute to project X? Give to project Y.
  • Requirements
    1. Motivation to share
    2. Ability to collaborate

Resources

Random Notes

Quotes

  • Raymond's Linus's Law: "Given enough eyeballs, all bugs are shallow."
  • Torvald's Linus's Law: "Every motivation that makes a man do something can be classified under 'survival', 'social life' and 'entertainment'.
  • Brook's Law: "Adding manpower to a late software project makes it later."
  • Henry Ford: "Coming together is a beginning; keeping together is progress; working together is success."
  • Metcalfe's Law: "the value of a network grows by the square of the size of the network"
  • Parkinson's Law of Triviality: "the amount of noise generated by a change is inversely proportional to the complexity of the change". a.k.a "Bike shed". Full article at bikeshed.com

Ideas

  • Cathedral and the Bazaar
  • Using semver.org (and semantic release notes?)
  • The pull request hack?
  • Make sure to point out how this applies to other people besides just OSS project owners