FOSS Community Models and Processes
From Wiki
AVOIR Community process
(some comments were missed at the beginning of the discussion)
Our community process is lightweight
Architecture of product is importance; well-defined architecture makes governance easier because discussions, ideas and debates happen within that context.
Follow community process even when in same room
Board, separate list
Importance of guidelines at the process level – how we interact with one another at the code level it's easier, process is well-defined
Most work done via mailing list seldom more than 20-30 messages per week.
Dev list active every day, 50-60 messages/day new students, proposal ideas, new business opportunities
Implementor list: support for installation, configuration
Important lesson from our case: keep it simple, don't have too many rules
Code process: because of the modular architecture, either lives in 1 of 2 repositories (core and modules). We use cvs, others use subversion. Any developer gets commit rights. Developers usually come in through one of the nodes. Register through our gforge site, administrator gives them commit rights. We've found this hasn't presented us with any problems. People don't generally make commits on other people's code. We encourage people to commit often, as soon as it runs, before going home at end of day
Importance of bug tracking: particularly important in diffuse community, developers separate from users. Need to be able to track bugs and feature requests, processes around additions. We use mantis. This process is an important improvement. Pr
OpenMRS Community Process
We have a weird hierarhcy of community. User and developers, but also per-site.
Most of our developers are users of our system, or work for companies that use OpenMRS.
Multiple versions of software, e.g. Partners in Health version
Started out small, 3-4 developers. Had a “primary user” who gave great feedback, tested new releases. Stayed that way for 2 years, and then Google Summer of Code brought in 10 new developers. We had to get them indoctrinated, get them up to speed on the development environment. Getting 10 developers to jump on project was a difficult process.
We have a wiki which is all the doc for OpenMRS. Had to revamp and change, especially the front-facing page for OpenMRS so people knew where to go. Took a couple of months. So we've evolved to support external developer community.
We created feeds to allow people to track changes and code commits. Posts to lists and forums, blog posts (general, developers). Feeds centralized getting information. Really helped core and new devlopers know what's going on.
For version control, anybody that asks to commit we give them rights. We're modular, we'll take new modules. For core, we review before applying, if it breaks, we undo.
Things we are still working on include how to add more developers. People want to pay developers, it's tough to know
18 months ago we identified that if we exposed the developers to routine implementations, they got bogged down. We created a separate list for folks implemention OpenMRS, which works as a helpline. Folks can post questions and get answers, and the group learns each others' work patterns. This is helping us to get a bigger footprint in Africa
QUESTIONS
What do you use for project management?
OpenMRS: we use Trac, split with the wiki. We assign tickets and features, have discussions in the bug tracking section. We don't have hard deadlines.
AVOIR: we also use bug tracking tool for project management. For paying customers, we hire a project manager, so it depends on the nature of where the development comes in. 4 development levels: 1) itch scratching (folks just do it for themselves), 2) non-developers who have an idea, toss the idea out, and developers can take it on, 3) paying project, mission critical application. Process depends on where in that spectrum the coding falls.
Questions: do you use any system analysis tools?
AVOIR: Depends on the process and how much money there is to pay for it.
Question: I thought the value of FOSS was collaboration. What is sounds to me is collaboration is really quite limited unless you're a big public project. It might be difficult to attract and manage participation. How complex is it to manage these developers? How do I get them to participate? Long term, it's a great place to be, but short term, I'm private sector, it's confusing me becaues it's not sounding like an easy option.
Derek: If you see FOSS as a way to get free development done, you will fail. It's not like that. It's like any other activity that attracts volunteers, it requires engagement. Those volunteers don't just come out of thin air. There really isn't a one size fits all answer to how you build these communities.
Justin: our developers start out as implementors. They need a feature, and our module architecture allows them to build them and add it with minimal politics.
Rob: you won't attract developers just opening up the source.
Derek: one of the great things about FOSS is you don't have to collaborate with folks to actually collaborate with them. You can use libraries others have written; you're working “with” other developers by using their code.
Chris: looking at our mobile and PDA applications, we looked for open architectures that we could use. In looking for open source tools. OpenMRS itself is build on about 8 open source packages. In terms of the long term sustainability of the open source, it has to be cool and something that people want to work on.
Comment: My confusion is you think of an application and decide to go open source, it may not be possible to be people to come in. If I want to use PHP, I can go find what I need. I benefit from the openness. We benefit from the fact that the access is there.
Q: how do you do promotion and choose your contributors?
Derek: we choose whoever asks. And we don't do good outreach and promotion. We need to be in the Debian and Ubuntu repositories.
Rob: we also take whoever comes. There are universities where people have connections. In terms of promoting openMRS, it's word of mouth. It is our yearly conference that people come to.
Justin: we're going to technology conferences and trying to present and seeing what feedback we get. But we're not selling the product.
