Post on 10-Feb-2017
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