Open Source Project Management Part 2

Open Source Project Management 2
Semen Cirit

Agenda
• Social and Political Infrastructure
– Benevolent dictators
– Consesus based democracy
– Writing it all down
• Communications
– You are what you are
– Avoiding common pitfalls
– Dificult people
– Handling growth
– Publicity

Social and Political Environment
 Successful projects have in common. «Successful» not just in terms of technical quality, but in terms of
operational health and survivability.
 Operational health is the project's ongoing ability to incorporate new code contributions and new
developers, and to be responsive to incoming bug reports.
 Survivability is the project's ability to exist independently of any individual participant or sponsor
 Formal governance structure, by which debates are resolved, new developers are invited in (and sometimes
out), new features planned
 Less formal structure, but more self-restraint, to produce an atmosphere of fairness that people can rely on
as a de facto form of governance.
Introduction

 final decision-making authority rests with one person, who, by virtue of personality and experience, is
expected to use it wisely.
 do not actually make all the decisions
 could have enough expertise to make consistently good decisions across all areas of the project
 let things work themselves out through discussion and experimentation whenever possible
 Only when it is clear that no consensus can be reached, and that most of the group wants someone to
guide the decision so that development can move on, does she put her foot down and say "This is the
way it's going to be."
 Who can be a good benevolent dictator?
 should phrase critiques or contrary decisions with some sensitivity for how much weight her words
carry, both technically and psychologically.
 not necessarily the ability to produce good design on demand, but the ability to recognize and
endorse good design, whatever its source.
 It is common for the benevolent dictator to be a founder of the project, technical competence, ability
to persuade other people to join
Benevolent Dictators

 As projects get older, they tend to move away from the benevolent dictatorship model and toward more
openly democratic systems
 Whenever a benevolent dictator steps down, or attempts to spread decision-making responsibility more
evenly, it is an opportunity for the group to settle on a new, non-dictatorial system—establish a constitution
 Two common element:
 the group works by consensus
 formal voting mechanism to fall back on when consensus cannot be reached
 Consensus simply means an agreement that everyone is willing to live with
 Someone will usually make a concluding post, which is simultaneously a summary of what has been decided
and an implicit proposal of consensus. This provides a last chance for someone else to say "Wait, I didn't
agree to that. We need to hash this out some more.«
 The version control system gives the project a way to undo the effects of bad or hasty judgement. This, in
turn, frees people to trust their instincts about how much feedback is necessary before doing something
Consensus-based democracy

 Before a vote can be taken, there must be a clear set of choices on the ballot
 Honest broker: posting periodic summaries of the various arguments and keeping track of where the core
points of disagreement (and agreement) lie.
 Honest broker can understand and fairly represent others' views, and not let their partisan sentiments
prevent them from summarizing the state of the debate accurately.
 Approval voting, whereby each voter can vote for as many of the choices on the ballot as she likes
 When to vote?
 Don't think of voting as a great way to resolve debates. It ends discussion, and thereby ends creative
thinking about the problem.
 To prevent a premature vote: The most obvious is simply to say "I don't think we're ready for a vote
yet," and explain why not.
 The vote should not be rushed. The discussion leading up to a vote is what educates the electorate,
so stopping that discussion early can lower the quality of the result.
Voting

 Who votes?
 best solution is to simply take an existing distinction, commit access, and attach voting privileges to it
 Voting contributors: You can't have votes about potential committers posted to a public mailing list,
because the candidate's feelings (and reputation) could be hurt. Instead, the usual way is that an
existing committer posts to a private mailing list consisting only of the other committers
 Polls vs Votes:
 be sure to make it clear to the participants that there's a write-in option: if someone thinks of a better
option not offered in the poll questions
 if the developers simply can't figure out whether a given interface choice matches the way people
actually use the software, one solution is to ask to all the subscribers of the project's mailing lists to
vote. These are really polls rather than votes
 Vetoes:
 A veto is a way for a developer to put a halt to a hasty or ill-considered change, at least long enough
for everyone to discuss it more.
 Any veto should be accompanied by a thorough explanation; a veto without such an explanation
should be considered invalid on arrival.
Voting

 At some point, the number of conventions and agreements floating around in your project may become so
great that you need to record it somewhere.
 Naturally, when the project is very young, you will have to lay down guidelines without the benefit of a long
project history to draw on.
 No document can capture everything people need to know about participating in a project. Many of the
conventions a project evolves remain forever unspoken, never mentioned explicitly
 If the project is a benevolent dictatorship, or has officers endowed with special powers (president, chair,
whatever), then the document is also a good opportunity to codify succession procedures.
 If someone makes a habit of inappropriately asking for rules to be reconsidered every time the rules get in
her way, you don't always need to debate it with her—sometimes silence is the best tactic.
 If other people agree with the complaints, they'll chime in, and it will be obvious that something
needs to change.
 If no one else agrees, then the person won't get much response, and the rules will stay as they are.
Writing it all down

Agenda
• Social and Political Infrastructure
– Benevolent dictators
– Consesus based democracy
– Writing it all down
• Communications
– You are what you are
– Avoiding common pitfalls
– Dificult people
– Handling growth

Commnunications
 A great programmer with lousy communications skills can get only one thing done at a time, and even then
may have trouble convincing others to pay attention. But a lousy programmer with good communications
skills can coordinate and persuade many people to do many different things, and thereby have a significant
effect on a project's direction and momentum.
 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.
 Structure and formating:
 Don't fall into the trap of writing everything as though it were a cell phone text message
 Write in complete sentences, capitalizing the first word of each sentence, and use paragraph breaks
where needed.
 Send plain text mails only, not HTML, RichText, or other formats that might get mangled by certain
online archives or text-based mail readers.
 When quoting someone else's mail, insert your responses where they're most appropriate,
 If you're writing a quick response that applies to their entire post, and your response will be sensible
even to someone who hasn't read the original, then it's okay to top-post
You are what you are

Commnunications
 Content:
 Make things easy for your readers.
 Don’t exaggerate
 Edit twice
 Tone:
 If you've just given reams of advice about exactly how the person should fix the bug, then sign off
with "Good luck, <your name here>" to indicate that you wish him well and are not mad
 It may seem odd to focus as much on the participant's feelings as on the surface of what they say, but,
to put it baldly, feelings affect productivity.
 Your role is not to be a group therapist, constantly helping everyone to get in touch with their
feelings. But by paying careful attention to long-term patterns in people's behavior, you will begin to
get a sense of them as individuals even if you never meet them face-to-face.
You are what you are

Commnunications
 Don't Post Without a Purpose
 None of these inherently requires a response:
 Messages proposing something non-trivial
 Messages expressing support or opposition to something someone else has said
 Summing-up messages
 Two good reasons to add your voice to a thread are:
 when you see a flaw in a proposal and suspect that you're the only one who sees it
 when you see that miscommunication is happening between others, and know that you can fix it with a
clarifying post
 Productive vs Unproductive Threads:
 Arguments that have been made already start to be repeated in the same thread, as though the poster thinks no one
heard them the first time.
 A majority of comments coming from people who do little or nothing, while the people who tend to get things done
are silent.
 Many ideas discussed without clear proposals ever being made. (Of course, any interesting idea starts out as an
imprecise vision; the important question is what direction it goes from there. Does the thread seem to be turning the
vision into something more concrete, or is it spinning off into sub-visions, side-visions, and ontological disputes?)
 A holy war is a dispute, often but not always over a relatively minor issue, which is not resolvable on the merits of the
arguments, but where people feel passionate enough to continue arguing anyway in the hope that their side will prevail.
Avoiding common pitfalls

Commnunications
 By "difficult" I don't mean "rude".
 Rude people will usually make themselves so unpopular as to have no influence on others in the project, so
they are a self-containing problem.
 The really difficult cases are people who are not overtly rude, but who manipulate or abuse the project's
processes in a way that ends up costing other people time and energy, yet do not bring any benefit to the
project
 Handling Difficult People:
 Given that it's so much work to fight, it's often better just to tolerate it for a while.
 Start gathering notes on the patterns you see. Make sure to include references to public archives
 Once you've got a good case built, start having private conversations with other project participants.
 Don't tell them what you've observed; instead, first ask them what they've observed.
 If private discussions indicate that at least some others see the problem too, then it's time to
do something.
Dificult People

Commnunications
 People unsubscribe from the lists, or leave the IRC channel, or at any rate stop bothering to ask questions
 Adjusting communications mechanisms to cope with project growth therefore involves two related strategies:
 Recognizing when particular parts of a forum are not suffering unbounded growth, even if the forum as a
whole is, and separating those parts off into new, more specialized forums (i.e., don't let the good be
dragged down by the bad).
 Making sure there are many automated sources of information available, and that they are kept organized,
up-to-date, and easy to find.
 Conspicuous Use of Archives:
 when you know the answer to some question off the top of your head, if you think there's a reference in the
archives that contains the answer, spend the time to dig it up and present it.
 Also, by referring to the archives instead of rewriting the advice, you reinforce the social norm against
duplicating information
 Well-placed references also contribute to the quality of search results in general, because they strengthen
the targeted resource's ranking in Internet search engines.
 Codifying Tradition
 Who have been with the project a long time were able to learn, and invent, the project's conventions as they
went along
 Writing up the guidelines was not enough. We also have to put them where they'd be seen by those who
need them most, and format them in such a way that their status as introductory material would be
immediately clear to people unfamiliar with the project.
Handling Growth

Agenda
• Legal Matters: Licenses, Copyrights, Trademarks
and Patents
– Choosing a license
– Contributor agreement
– Proprietary licensing
– Trademarks
– Patents

Legal Matters
 free software:
 Software that can be freely shared and modified, including in source code form. The term was first coined by
Richard Stallman, who codified it in the GNU General Public License (GPL), and who founded the Free
Software Foundation (fsf.org) to promote the concept.
 open source software:
 Any license that is free is also open source, and vice versa. In general, those who prefer "free software" are
more likely to have a philosophical or moral stance on the issue.
 FOSS, F/OSS, FLOSS
 FOSS, or sometimes F/OSS, standing for "Free / Open Source Software. FLOSS, which stands for "Free / Libre
Open Source Software.
 DFSG-compliant: Compliant with the Debian Free Software Guidelines
 OSI-approved: Approved by the Open Source Initiative.
 proprietary, closed-source: The opposite of "free" or "open source.«
 public domain: Having no copyright holder
 copyleft: A license that not only grants the freedoms under discussion here but furthermore requires that those
freedoms apply to any derivative works.
 non-copyleft or permissive: A license that grants the freedoms under discussion here but that does not have a
clause requiring that they apply to derivative works as well.
Terminology

Legal Matters
 When choosing a license to apply to your project, use an existing license instead of making up a new one
 Use one of the widely-used, well-recognized existing licenses
 Familiar to many people. Thus, you reduce or remove one possible barrier to entry for your project.
 High quality: they are the products of much thought and experience; indeed most of them are
revisions of previous versions of themselves
 Copyleft licenses:
 GNU General Public License version 3 (GPL)
 GNU Library or "Lesser" General Public License version 3 (LGPL)
 Mozilla Public License 2.0 (MPL)
 Non-copyleft:
 MIT license
 Apache License 2.0
 BSD 2-Clause ("Simplified" or "FreeBSD") license
Choosing a license

Legal Matters
 Contributor license agreement(CLA): it is taken from each person who works on the project, explicitly granting the
project the right to use that person's contributions.
 Doing Nothing:
 This can seem to work for a long time, as long as the project has no enemies.
 They are the true owner of the code in question and that they never agreed to its being distributed by the
project under an open source license.
 Contributor License Agreements:
 for individuals, and one for corporate contributors.
 Request CLAs is not asking for actual copyright assignment. In fact, many CLAs start out by reminding the
reader of this, for example like so:
«This is a license agreement only; it does not transfer copyright ownership and does not change
your rights to use your own Contributions for any other purpose.»
 Developer Certificates of Origin (DCO): A Simpler Style of CLA:
 contributor intends to contribute the enclosed code under the project's license
 the contributor includes a "Signed-Off-By:" line in her patches or commits, using the same identity, to
indicate that the corresponding contribution is certified under the DCO.
Contributor Agreement

Legal Matters
 Trademarks do not restrict copying, modification, or redistribution.
 Trademark is unrelated to copyright, and does not govern the same actions that copyright governs.
 Trademark is about what you may publicly call things, not about what you may do with those things
nor with whom you may share them
 Ex: The Mozilla Foundation owns the trademarked name "Firefox", which it uses to refer to its
popular free software web browser of the same name.
 Patent:
 It doesn't matter who writes the code, nor even what programming language is used.
 Once someone has accused a free software project of infringing a patent, the project must either stop
implementing that particular feature, or expose the project and its users to expensive and time-
consuming lawsuits.
Trademark, Patent

Agenda
• Organizations, Money and Business
– Types of corporate involvement
– Hire for the long term
– Contracting
– Funding non-programming activities
– Open source and organization
– Hiring open source developers
– Evaluating open source projects

Organizations, Money and Business
 Sharing the burden
 Dependent services
 Creating an ecosystem
 Supporting hardware sales
 Undermining a competitor
 Marketing
 Proprietary relicensing
 Donations
Types of Corporate Involvement

 The need for a newcomer to learn the ropes each time would be a deterrent in any environment.
 But the penalty is even stronger in open source projects, because outgoing developers take with them not
only their knowledge of the code, but also their status in the community and the human relationships they
have made there.
 A long-time developer knows all the old arguments
 A new developer, having no memory of those conversations, may try to raise the topics again, leading to a
loss of credibility for your organization;
 A new developer will also have no political feel for the project's personalities, and will not be able to
influence development directions as quickly or as smoothly as one who's been around a long time.
Hire for the long term

 If you hire a contractor you want her work to be accepted by the community and folded into the public
distribution.
 If the project has written standards (e.g., about coding conventions, documentation, writing regression
tests, submitting patches, etc), the contract can reference those standards and specify that the contracted
work must meet them.
 Add to contract:
 written standards (e.g., about coding conventions, documentation, writing regression tests,
submitting patches, etc)
 IV&V , Use Third-Party Review Throughout Development. Benefit is large: the difference between an
end product that is not useably open source and one that is truly open source, able to be deployed
and supported by anyone.
 Two independent commercial entities able to deploy and support the software: the primary development
vendor, and the IV&V (Independent Verification and Validation) vendor.
 The best tactic for successful contracting is to hire one of the project's developers—preferably a committer
Contracting

 Quality Assurance (i.e., Professional Testing)
 Legal Advice and Protection
 Documentation
 Usability
 Providing Hosting/Bandwidth
 Providing Build Farms and Development Servers
 Sponsoring Conferences, Hackathons, and other Developer Meetings
Funding non-programming activities

 Dispel Myths Within Your Organization
 Open source software is insecure, because anyone can change the code.
 Open source comes with no support.
 Open source is cheaper.
 If we open source this project, we'll have to spend a lot of time interacting with outside developers.
 If we open source this project, then we'll have to release all our other stuff as open source too.
 Other companies / cities / whatever will pick up this software and start using it right away.
 Foster Pools of Expertise in Multiple Places
 Don't Let Publicity Events Drive Project Schedule
 Innersourcing: real commitment reduce managerial and organizational barries to engineers following their
own lead in contributing to projects across the company
Open source and Organizations

 Look at bug tracker activity first.
 Measure commit diversity, not commit rate.
 Evaluate organizational diversity.
 Discussion forums.
 News, announcements, and releases.
Evaluatiating Open Source Projects

Open Source Project Management Part 2

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (18)

Similar to Open Source Project Management Part 2

Similar to Open Source Project Management Part 2 (20)

More from Semen Arslan

More from Semen Arslan (10)

Recently uploaded

Recently uploaded (20)

Open Source Project Management Part 2