Difference between revisions of "Developing Open Source Software For Success"
m (1 revision imported) |
(No difference)
|
Latest revision as of 21:30, 20 May 2015
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: http://www.youtube.com/watch?v=ZSFDm3UYkeE !! - 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.
Takeaways
- 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