Developing Open Source Software For Success

From DevSummit
Revision as of 21:30, 20 May 2015 by Vivian (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Facilitated by Ben Wolfe, OpenMRS

Lessons learned from OpenMRS and its initial community building to foster a successful open source project.

Ben Wolfe of the OpenMRS project Successful open source project

collaboration vs cooperation

collaboration - couple things to do

cant be all about just putting the code out there should have other people come in share their ideas to shape how its going

ownership - usually in debates between options it is best to work with a compromise

respect of each other

they user a pseudo agile development approach - developers develop and comes back then group reviews and revise

mailing list tools for users to help themselves some are on both and help across the

confluence - wiki ( developing)

Search engine indexable archive is important

nabble will do archiving and indexing of mail lists

Important for documentation to be out there. (wiki)

People are more prone to act on something posted then an empty page.

Keeping a tight focus - doing one thing well, try not to extend yourself beyond you project,

Modular architecture to let people add in specific apps

document well how to interface modules so people don't have to guess what they need to do

discussions - blogs - links from blogs to project svn commits -

feed aggregator - feedjack as an example some of the many sources for the activity monitor - rss listserve, - rss maillist - rss blog posts wiki updates svn commits tickets

news & announcement feed ticketing - trac

did not have many added developers, so it was easier going though keeping a small set of developers

Documentation is good

Open source is a lot of work vs in house

50% harder to make open source (keeping code generic)

team support - About every six week get together for a face to face.

mailing lists one for implementers, one for developers

Annual conference for all users developers (depending on size)

Push for openness have everything archived publicly request any private questions be posted for public answer.

Be aware of 'poisonous people'. Watch this youtube video: !! - There is a Google Tech Talk video in YouTube presented by subversion developers on the topic of 'poisonus people'

avoid having a low 'bus factor' (how many people hit by the bus that would kill the project)

IRC channel general channel (good for google summer of code student chat) Good way to connect with others Maybe schedule an official regular chat event.

Freenode admin channel request your room can be held.

check out Mibbit, an AJAX IRC client that can connect via browser.


  • In developing - collaboration is better than cooperation, where participants have more ownership of the project
  • Showing project Activity on the start page is a good way to to attract new users
  • Documentation on a wiki is important for continued user help at keeping it up to date
  • A modular well-documented base is good for growth down the road, but costs a lot in development time in the beginning