Some notes and quotes from this excellent . If you want to cheat a little jump to page 104, but the entire paper is worth reading. Also see page 112 for some good quotes and the writer’s conclusions. Kudos to Mattias on this work.
In addition to the subject matter, it was quite interesting to observe the evolution of collaboration tools and programming languages in the past 5 years.
On the Open Source Project Community and Members
- A good community is one that is honestly friendly, highly responsive, composed of friendly, altruistic members.
- Members must be able to put the interest of the community ahead of their personal interests.
- Code committers should demonstrate perseverance and the ability to self-start.
- It is ideal to keep the same members around for several years.
- Open communication - discussions should happen in public for all to participate in.
- One exception to the open communication - discussion on who can be a committer.
- Open to join - make it easy for committers to push code to the project. (this is simple now in the era of github)
- Members should gain authority on the principle of meritocracy rather than that of an old boys’ club.
- Implement the best collaboration tools and processes
- Give the committers credits on the project website
“Diversity helps to guarantee stability by including different perspectives.” - Wechner
“Open source projects are not one man shows” - Rothfuss
“The community must be able to find consensus and at the same time define priorities.” - Wechner
On the Role of Project Leadership
- Visionary, stay engaged and proactive regarding the future of the project.
- Leaders sometimes need the ability to be assertive in regards release issues.
- Commitment, mostly in the form of investing lots of time, continuous presence.
- Communication skills are more important than design cleverness.
- Experience, knowing as much as possible about the code base keeps things structured better and prevents replication of existing features.
- Keep the developers happy about the amount/quality of their work keeps them better motivated.
- Helpfulness, try to help everyone who wishes to become involved.
- Openness, a trait that stands in contrast with the mentality of closed software projects.
- Patience, think with a long term perspective.
- Personality and charm go a long way.
- Allow people to work on what they want, how they want.
- Keep the tone of communication polite, respectful, solve communication conflicts.
- Must be highly skilled in programming.
“When you lose interest in a program, your last duty to it is to hand it off to a competent successor.“ - Raymond
“You’ve got all of these tasks floating around and then people take tasks that they want to do. I think what makes the core programmers special is that they’re willing to do the tasks that no one else does because I think they take a greater sense of personal responsibility and a more long-term approach.” - Ian Clark
“Besides some amount of this good humbleness it’s important to communicate your vision clearly - and to give arguments why you have this specific vision.” - Wechner
Getting Started - Project Prerequisites
- Choose a Programming Language
- Choose an Open Source License - bears upon collaboration and control
- Complete a usable portion of software - better to have code than just ideas and plans, demonstrate the project’s potential
- Try to anticipate public demand and interest
- Estimate the amount of skill required of the project’s audience
- Achieve a degree of novelty and innovation
- Document - this lowers the entry bar and allows others to collaborate
“It’s always better if there is already code available instead of just ideas. In SourceForge there are many ideas that never catch on. If some code is already available it’s much easier to find people because usually nobody has time to study ideas and plans. You can’t submit patches for ideas. There are so many other things to do, so it must be attractive.” - Rothfuss
“You should publish a software only when it’s quality is sufficient.” - Bühlmann