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

Social and Political Environment 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

Social and Political Environment 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

Social and Political Environment 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

Social and Political Environment 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

Social and Political Environment 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

Organizations, Money and Business 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

Organizations, Money and Business 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

Organizations, Money and Business 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

Organizations, Money and Business 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

Organizations, Money and Business

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

Thank you