Developing Open Source Leadership

1 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 1 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley)
Guy Martin
Senior Strategist, Open Source Group
Samsung Research America
guy.martin@samsung.com
Developing Open Source
Leadership

2 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley)
About Your Instructor
• 21 years in
software/technology
• 12 years in open source
• Leading strategy for Samsung
Open Source Group
• Built open source
consulting/communities for
several organizations

About This Course
• You’ll get out of it what you put into it
• Training is just the beginning
• Open source is > 50% collaboration – so
is this course
• Please ask questions :)

Course Content
• Open Source Development Model
• Best Practices
• Communication & Community
Skills

5 © 2014 Samsung Electronics Co.Open Source Group – Samsung Research America (Silicon Valley) 5Open Source Group – Samsung Research America (Silicon Valley) © 2014 Samsung Electronics Co.
Open Source Leadership
Why and How?

Product Dependency on Open
Source Technologies

New Open Source Skillsets

Open Source Strategy
Consumer
Participant
Contributor
Leader
Start here!
Decide on the desired position based on
company’s OSS strategy

Contributor Scenario -
Recommendations
• Actively participate • Follow community
development processes
• Contribute to development,
documentation and testing
efforts
• Hire open source
developers
• Build up internal open
source leaders
• Host open source activities,
meetings, events, etc.

Leader Scenario
• Leadership roles in open source communities are
earned by establishing trust with the project
members, and by maintaining a high level of
continuous contribution to the project
• Requires significant investment in targeted open
source communities and consortia to establish
leadership agenda
• Requires incremental investment primarily in
engineering, product management and legal
organizations

Leader Scenario – IBM
Example 2001

Leader Scenario – Recommendations
• Achieve a higher level of contributions
• Empower employees to seek contributor and maintainer
status
• Sponsor events, provide financial support for the projects
• Establish open source office
• Establish an open source architect role(s) to pro-actively
guide the use of and contributions to open source software
• Open source proprietary technologies
• Lead architectural and requirements initiatives within these
communities and consortia to achieve commercial
objectives

Open Source Development Model

Closed Source Process
Software Client
Software Vendor
Requirements
Design
Implementation
Test / Integration
Deployment
Maintenance

Open Source Model
User
Community
Developer
Community
Project or Feature Ideas
Architecture and
Design Discussion
Implementation
(coding)
Continuous Testing
and Integration
Deployment
(release)
Maintenance
Patches
(submitted by developers
and users)
Feature Requests
(submitted by developers
and users)
Test Projects to Automate
Testing and Validation

Open Source Model
Characteristics
1. Distributed
development
2. Development
community
3. Community
organization
4. Scalable
development
5. Decision process
6. “Release early,
release often”
7. Submitting code
8. Taking
responsibility
9. Giving credit to
others
10.Peer review
11.Continuous testing
12.Gaining influence
13.Modular designs

Distributed Development
• Characteristics
– Worldwide teams working in their own local time
zone
– Communication channels that reduce the impact of
language barriers
– Responsibility for development allocated to the
individual or team with best capacity to deliver
– Strict quality standards when changing code
– Multiple levels of review before entering final
release
• From an organizational perspective, it’s not that
different from traditional large scale software
development

Development Community
• Accessible to newcomers
– Open development generally strives for
inclusiveness
• Focused on visibility
– Strong emphasis on open decision making
processes and communication
• Self-organizing
– Most projects take guidance from internal
sources (i.e., the people doing the work)

Community Organization
• Tight vertical hierarchy
• Loose horizontal structure
• Small incremental changes
flow upward
Maintainer
Subsystem
maintainer
Subsystem
maintainer
Subsystem
maintainer
Sub-subsys
tem mainta
iner
Sub-subsys
tem mainta
iner
Sub-subsys
tem mainta
iner
Sub-subsys
tem mainta
iner
Sub-subsys
tem mainta
iner
Developer
Developer
Developer
Developer
Developer
Developer
Developer
Developer
Developer
Developer
Developer
Developer
Developer
Developer
Meritocracy drives advancement
and acceptance
Not influenced by marketing

Small project Large project
A Scalable Development
Model
#include <file1.h>
#include <file2.h>
#include <file3.h>
...
Single body of code
Releases available “when they are ready”
Single maintainer

Model
Releases available “when they are ready”
#include <file1.h>
#include <file2.h>
...
Code divided into subsystems
#include <file1.h>
#include <file2.h>
...
Single maintainer

Model
Release criteria become more stringent
#include <file1.h>
#include <file2.h>
...
#include <file1.h>
#include <file2.h>
...
Single maintainer

Model
Release criteria become more stringent
#include <file1.h>
#include <file2.h>
...
#include <file1.h>
#include <file2.h>
...
Delegated maintainership

Model
Delegated maintainership
Releases overseen by dedicated maintainers
#include <file1.h>
#include <file2.h>
...
Further subsystem divisions
#include <file1.h>
#include <file2.h>
...
#include <file1.h>
#include <file2.h>
...

Decision Process
• Decisions are decentralized
by appointing trusted
delegates
– In Linux, called “subsystem
maintainers”
– Trust built by past record
of good participation and
wise decisions on smaller
issues
• Not all decisions need pass
through delegates
– Trivial fixes may go directly
to any maintainer
• Decentralized nature
requires extra focus on
transparency
– Discussions must
happen in the open:
Mailing lists, IRC
• Often the discussion itself
is the documented record
of the outcome

Influence Within Open
Source Communities
• Influence in a project is based on reputation in that
project/community
– Reputation is gained through code contributions and participation
– Reputation in one community doesn't necessarily carry to others
– Reputation in own company doesn't carry to open source
community
– Must prove oneself on each project to gain influence
• The writer of the best code has the most influence
– It doesn’t matter who you are, who you work for, how it was
done before, or how smart you are
• Behavior is important
– Willingness to take and provide feedback (politely)
– Ability to explain motivations behind decisions

Submitting Code to an
Open Source Project
• Well-defined, highly structured
– Retrieve current source code from project
repository
– Write new code, generate patch using
diff
– Submit code as an email to appropriate
subsystem maintainer, via project mailing
list
– Subsystem maintainer decides whether
patch should be accepted or rejected
– If accepted, maintainer will apply patch to
their own tree
– In complex projects, patch proceeds
through several layers of maintainers, and
appears in a main project release
• Comprehensive list of guidelines can be
found in:
– Linux kernel sources (under
Documentation/SubmittingPatches), and
– http://linux.yyz.us/patch-format.html
Development ongoing, with
discussions on mailing lists or IRC
Code functional, tests clean, ready
for first integration
Patch submitted to
maintainer / mailing list
Patch reviewed
Patch integrated, tested, accepted
by maintainer
Patch integrated through
maintainers’ trees
Code integrated into mainline
release
Patchrejectedtobereworked

Taking Responsibility for
Source Code
• OSS development methods favor extra scrutiny on code origins
– Less direct oversight on any individual developer
– Low barriers to entry in distributed development
• Anonymous contributions are almost universally unwelcome
– Who wrote this?
– Who do we go to if there’s a problem?
– What if it wasn’t submitted by the owner of the code?
• Requiring submitters to claim ownership of their code using real
names results in higher quality code and better maintenance
– Credit can be given where due
– If there are questions on the code, anyone can easily see who to ask
– Each developer is personally guaranteeing the quality and the origin
of the code

Working with Upstream

What is Upstream?
upstream (noun)
– The originating open source software project
upon which a derivative is built
– This term comes from the idea that water and
the goods it carries float downstream and
benefit those who are there to receive it.
to upstream (verb)
– A short-hand way of saying "push changes to
the upstream project“, i.e. contribute the
changes you made to the source code program
back to the original project dedicated for that
program.

When is it Time to Start
Contributing Upstream?
• When the costs of keeping your code in sync with the
mainline project exceed the convenience of working alone
• When you want your code to be used by others (including
customers)
• When you want to drive your implementation to become a
defacto standard, or drive adoption of the mainline project
• If you anticipate relying on a certain codebase repeatedly in
upcoming products that complements the mainline project

Motivations for Contributing
Upstream
• Private code is never considered in public
development
– Integrating changes upstream means others are aware of
them, and can plan for and around them
– Reduces the risk of accidental breakage
• Integrating changes into the mainline project reduces the
amount of effort to build a finished product
• Contributed code is reviewed and may attract external
developers
• Contributions strengthen and influence direction of
project

What Should Go Upstream?
• The decision of what source code to push to upstream is guided
by your open source strategy
• Generally, you should drive to upstream:
– Technology enablers contributions – (non-strategic) code that will make
your differentiating offering run better/faster/etc.
– Source code that is of usefulness to all platform users – that they don’t
want to maintain themselves
– Source code that will help them influence the direction of the project
– Source code that will help them push a given implementation to become
defacto standard
– Source code that will help them undercut the competition
– Etc.
• A good guide is to determine what parts of your product are
sources of strategic advantage, and what supports those parts
– The supporting parts are generally good candidates for upstream

Typical Upstreaming Process
Identify in-house modifications
Are there dependencies on private code?
Does it meet coding and security standards?
Obtain company approval to participate by following
your company’s technical and compliance policies
Plan the submission strategy
Prepare the code for submission (code style, generate
patch, verify it applies properly, etc.)
Follow the project’s submission process
Maintain the code, update it based on feedback and
contributions from others
Rework the code
Yes
No
Not accepted –
Take feedback

Best Practices: Requirements

Propose New Features &
Signal Intent
• Public discussion is a prerequisite
– Ensures maintainers are aware of the need and the
problems you are working to solve
– Recruit others to help do the work
– Gather feedback on the usefulness and design
considerations before doing a lot of work (and
being rejected)
– Some projects have active mailing lists, multiple
tries may be needed
• Over-communicate
– Assume you have one chance to convince others

Propose New Features &
Signal Intent
• Accept incoming feedback and work with it
– Incorporating feedback increases the likelihood a
contribution will be accepted
– Feedback is generally legitimate, as others will only
take time to respond if what you’re doing is
important to them
• How it happens in Linux:
– When a feature request is controversial, it generally
requires public discussion on the Linux Kernel
Mailing List (lkml) before code is considered

Getting Buy-in for a Feature
Request
• Contributed features should be:
– Useful to others and not just to your specific usage models
• Features that benefit only a few users will tend to be rejected if there
is no benefit to the majority
– Implemented in small parts, and delivered in a way that
provides immediate benefit
– Strong on security
• Open Source developers tend to be more security conscientious than
closed source developers
– Backed by resources ready to implement and maintain
• Don’t ‘dump code and run’

Typical Feature Request
Process
• What happens in this phase:
– Requester’s opportunity to
make the case for why the
project should plan for their
feature
– In most cases, the requester
already has enough resources
to implement the feature
• Typical actions:
– Requester/developer sends
email to a project mailing list
• The need for the feature
• The problem it solves
• How it fits into the project
• Possible implementations
Feature request sent to mailing list
Discussion on mailing list and IR
C
Feature request is accepted
Feature is tracked
Feature is prioritized
Feature aligned with future releas
e
Development / QA

Process
– Interested parties are given
an opportunity to comment
– Major or intrusive feature
requests will typically be
discussed in great detail
– Other Opportunity to recruit
other development resources
to help implement
– Initial email stimulates
discussion on the mailing list
– Maintainer may comment on
when the project would be
ready to accept feature
– Comments range from brief
approval, to detailed
implementation
considerations
Discussion on mailing list and IRC
Feature request sent to mailing li
st
Feature is tracked
e
Development / QA

Process
– Maintainer and other
interested parties agree
• Feature is strategic to project
• Belongs on roadmap
• Implementation is ok
– General consensus that
feature will be beneficial to
project
– Acknowledgement that
feature will not impact
• Stability
• Security
• Functionality of project
– Maintainer gives approval
st
C
Feature is tracked
e
Development / QA

Process
• What happens in this
phase:
– Most projects or
subsystems within a
project have a process for
tracking features in
upcoming releases
– This is often considered
the authoritative record of
what was proposed and
accepted
– Developer adds detailed
feature information into
tracking tool
Feature is tracked
st
C
e
Development / QA

Process
– Maintainers prioritize features
• What is core to the project
• What is needed, and when
– Maintainers generally have a
global view of dependencies
and future deliverables, and
may prioritize to align
features.
– Minor features and
enhancements may be
requested as soon as they are
ready.
– Maintainer may determine
the priority of the request
relative to other queued
features
st
C
Feature is tracked
e
Development / QA

Process
phase:
– Project maintainer
communicates when
they will be ready to
integrate the feature.
– This helps them plan for
a manageable number
of features per release.
– Maintainer may assign
feature to a specific
release.
Feature aligned with future release
st
C
Feature is tracked
Development / QA

Process
phase:
– Developer and any
other resources
recruited in former
steps begin
implementing the
feature, targeting the
release set by the
maintainer.
– Development team
begins work.
Development / QA
st
C
Feature is tracked
e

Best Practices: Design

Design In the Open
• Communicate early and often on mailing lists
• Provide examples and possibly reference implementations
• Anticipate feedback
– Acknowledge good feedback and re-work your contribution
• Respond promptly to questions, particularly from potential
contributors
– Signal willingness to adapt your design if someone else will
do the work
• Plan for modularity, even if the first designs are not

Recruit Others
• Scratch your own itch, nobody else will scratch it for you…
unless they have the same itch
• If you are wanting to decrease your development burden,
write code that will attract others for the same reason
– Make sure your contribution is scoped broadly enough to
attract other contributors
– Be responsive and proactive if someone indicates interest in
your email to the mailing list
• Don’t be surprised if it’s a competitor
– Often the companies with the most to gain from a feature in
an open source project are in the same line of business
– There is a rich history of collaboration between
competitors

Design for Acceptance
• Design your contribution to be written and integrated in the
smallest parts possible
– Smaller patches are easier for maintainers to integrate
– Many open source projects favor a modular approach, because it
promotes extensibility
• Scope the design, and subdivide your plans if necessary
– Larger changes are more likely to be adopted if a series of smaller
changes with concrete milestones
– Communicate the overall plan to provide context, but don’t expect
universal buy-in
• Be as non-intrusive as possible to other subsystems
– If you believe you need to change a core system component,
communicate far in advance and solicit input from their
maintainers before getting started

Best Practices: Implementation

Be Agile
• The line between design and implementation
is very blurry in open source development
– Multiple iterations are expected and encouraged
• Don’t expect perfection the first time
– Code stabilization is part of the community
process
– Allow the developer community to help guide
and shape the code

Start From a Fresh Pull From
the Right Tree
• It is not uncommon to have many versions of the same project
– Each maintainer may have their own tree
– Some projects maintain stable and development trees
• In almost all cases, you should base your work on the tree
that builds the official release
– In Linux, this is Linus’ tree on kernel.org
• Ultimately the project maintainer is final arbiter on what gets
accepted
– If your patch does not apply cleanly to their tree, it will be rejected
• Never assume code as a dependency that isn’t already part of
mainline, unless you’re submitting it yourself
– It’s impossible to test without replicating your custom setup, and
maintainers usually don’t have the resources to do this

Implement Functionality in
Smallest Reasonable Chunks
• Will result in more constructive feedback
– Easier to understand small patches
• Simplified testing
– A small change is less like to have unintended
consequences
– Very important because of lack of traditional
test phase
• You will be expected to submit in small
parts

Reuse Existing, Accepted
Code Wherever Possible
• It makes your contribution smaller
• It reduces the code you must personally debug and
maintain
• It increases your chance of acceptance
– Maintainer already familiar with accepted code
– Most maintainers are very averse to duplicating existing
functionality
• If existing code has most of the functionality you need,
submit a patch to extend it
– Always try this before building your own
– If this is for a key dependency, get your patch accepted before
beginning work in earnest on the main feature

Typical Patch Submission
Process
Development ongoing, with discussions on mailing lists or IRC
Code functional, tests clean, ready for first integration
Patch submitted to maintainer / mailing list
Patch reviewed
Patch integrated, tested, accepted by maintainer
Patch integrated through maintainers’ trees
Code integrated into mainline release
Patchrejectedtobereworked

Creating a Patch
• The patch should be created against the most
recent version of the mainline source code
• The patch should be offset from the root of
the tree
• The patch must apply cleanly
• A freshly-patched version of the code should
build without errors
• A patch should do one thing, and do it well
http://lwn.net/Articles/139918/

Writing a Patch Email
1. Find and follow project guidelines on how
to format patch emails
– Some projects use scripts to extract patch
information from emails
2. Send one patch per email
– Particularly true when sending large numbers of
related patches
3. Include [PATCH] in the subject line
– Mailing lists usually have a lot of traffic

Writing a Patch Email
4. Maintain threading when replying
– When sending an update, reply to your original
message
5. Numbers don’t lie
– Include benchmarks or quantitative
justification for your approach
6. Avoid attachments and MIME
– Both can cause errors for scripts that
automatically import accepted patches

Deconstructing a Linux
Patch Email
To: subsystem.maintainer@project.org
CC: project-mailing-list@project.org
Subject: [PATCH {version} {x/y}] {Subsystem}: {Single-line description}
Body:
{Detailed description of changes to go into git log}
Signed-off-by: Developer Name <developer.email@example.com>
Acked-by: Another Person <another.person@company.com>
---
{properly formatted patch as plaintext}
Sent to subsystem
maintainer
CC to the project
mailing list
Version of project
If patch is part of
series (e.g., 1/5)
Area of the projec
t patch applies
Meaningful
description
Detailed explanatio
n
Patch content
Required
authorship line
Optional
acknowledgement
Required delimiter
http://linux.yyz.us/patch-format.html

Be Patient and Persistent
• Send patches and responses in public,
never in private
• Accept criticism, and rework the code
• Make incremental changes that are well
communicated
• Resubmit the patch
• Be persistent and polite

What if My Patch is
Rejected?
• Code may be rejected for any reason
– Poor quality, inconsistent formatting
– Too much function in one submission
– Inconsistent with broader subsystem strategy
• This doesn’t make you a bad coder
– Revise and try again
• When replying, filter unnecessary feedback
and focus just on the technical aspects

Escalation
• Sometimes patches slip through the cracks
• If you haven’t received an
acknowledgement after a reasonable
amount of time, resend it
– Typically one week
– Add this line to the top of the email:
• “Patch escalation: no response for 7 days”

Checklist Before Submitting
Patch follows all coding style guidelines
– Run scripts/checkpatch.pl to scan your patch for
coding standard violations
Patch applies cleanly against main project
tree
Project builds cleanly after patch is applied
Patch is tested to do what it claims
Header of file is documented properly, is in
English, and follows kernel style guidelines

Checklist Before Submitting
 Patch email has:
– A detailed subject line
– Signed-off-by line
– Detailed description of what the code does and why it is being
submitted
– Notification of any dependencies being sent as additional
patches
– Only one patch
 Patch email is properly formatted
– Follows code submission guidelines
– Has no attachments
– Is not in HTML or “rich text” format
 Email is being sent to the right person, and CCs the proper
mailing list

Reporting Bugs
• Not uncommon to uncover bugs in other peoples’ code during
development
• If the project uses Bugzilla
– Search for duplicate bugs first
– Report the bug in relevant components
– File separate bugs for separate issues
• If the bug is in the Linux kernel
– Email the maintainer of the code, and cc linux-kernel@vger.kernel.org
– Read the files REPORTING-BUGS and MAINTAINERS in kernel sources
– If the bug include an ‘OOPS’ message, see Documentation/oops-tracing.txt
– If you can, try to create a shell script that replicates the problem, and send it with
your bug report
– Running scripts/ver_linux in the kernel source will provide useful information
for the bug report

Best Practices: Testing

Testing is Continuous
• Source code change management processes favor continuous testing
– Every developer works on a complete branch of the tree
• Community processes require basic QA from the start
– A patch must compile and meet basic standards before it will be considered at
any level
• Tools like git are built with continuous testing and integration in mind
– Patches that cause problems can be found and reverted
• Automated build suites help detect problems quickly
– Detect major problems within 24 hours
– May automatically file bugs in bugzillas
• Some projects create and maintain test suites specific to their codebase
– Community QA engineers may simultaneously develop the test suite and analyze
the builds

Best Practices: Maintenance

Maintaining Your Code
• Don’t “dump and run”
– Abandoned code will be worked around and
eventually removed
• Disclose problems quickly, and provide
workarounds and fixes
– Pretending nothing is wrong will only buy you
trouble
• If you can’t maintain it, pass responsibility along to
a successor, or arrange to have it removed
– If your code is important, someone else will step up

Responding to Bugs
• Many projects use Bugzilla
– Register an account, and contact the bugzilla
maintainer to add your project and name to the list
of components
– You should be the default assignee
– Respond promptly, and close or transfer bugs as
appropriate
• The Linux kernel uses email instead of bugzilla
– Respond to bug emails promptly, and CC the kernel
mailing list

Accepting Patches to Your
Code
• If your code is useful, others may want to
enhance it
– Be open to the community process
– Be available to the maintainer if asked for your
input on a patch
– Consider the technical comments people
make on the code, and justify any
disagreements that you have with them

Open Source
Community/Communication Skills

What are Communities?

Rule #1
No two communities are exactly the same!

Rule #2
Communities don’t work for individual
companies

Internal versus External
• As leaders, you have to ‘manage’ internal vs.
external expectations about open source projects
you are involved in
• You serve as a ‘consultant’ to other internal co-
workers and managers who may not be as familiar
with Open Source as you will be
• Be honest with both groups
– If you cannot comment to external community about
something, tell them why (‘internal product decision’, etc.)
– If the community wants something your company
doesn’t, try to find common ground with both parties

Preparing to Engage with Community

Determine your Strengths
There are many skills required in open source
projects, and many roles to fill:
• Software Developers
• Testers/Quality Assurance
• Documentation Writers
• User Experience/GUI Designers
• Evangelists/Communications Experts
You can have more than one role if you have the
time and necessary skills.

Determine your Time
Commitment
• Commit to what you can realistically deliver
• Communities respect completed work more than
hollow offers of help
• Your commitment reflects not only on you, but on
your company

Get to Know the Community

Understand How the
Community Communicates
• Learn which methods are accepted & preferred:
– Email lists
– IRC
– Web forums
– Bug trackers
• Observe and learn how questions are
asked/answered
– http://catb.org/~esr/faqs/smart-questions.html

Understand How the
Community Communicates
• Before asking a question of the community
– Search any message archives/logs for the answer
– Read any user documentation
– Search the web for the answer
– Read any Frequently Asked Questions (FAQ) documents
– Read the source code!
– Experiment and document your experiments
• Find the correct forum
– Don’t post technical questions to a user list, for example
– Show how you’ve tried to find the answer on your own

Understand How the
Community is Governed
• Some communities (such as Linux Kernel) are
hierarchies with clear chains of command
• Some communities (such as the Debian project) are
flat democracies
• Understanding community governance helps you
address your questions to the right audience

Get to Know the People
• Relationships (even virtual ones) matter in
communities
• Understanding how people work helps get your
ideas accepted in the community
• Participate in conferences/meetups as much as
possible to help build ‘human networks’

Engage with the Community

Communicate What You’re
Working On
• Don’t work on something for the community ‘in
private’
– Someone else will probably have duplicated your effort
– Other changes in the project may obsolete/conflict with your
work
• Project maintainers can help plan for future releases if
they know what’s coming
• Community participants don’t like last minute feature
‘surprises’

Acknowledge Resources You
Use
• Give credit where it is due for libraries/resources
you use
– Helps others find these resources
– Provides positive feedback for the creators, encouraging
them to keep maintaining these and creating new ones

Give Back to the Community
• Code contributions
• Answer questions from other members
• Facilitate hardware gifts if possible
• Help arrange conferences/meetups
• Offer to speak at conferences/events
• Your contributions reflect on you and your company!

Plan an Exit Strategy
• Train your potential successor
• Introduce your successor to the community
• Insure that your code contributions will be
maintained by someone from your company
• Inform the community as soon as possible so that
they have time to plan for the transition

Communication Tools Etiquette

Mailing List Etiquette
• All communication is generally in English
• Keep on topic
– Try to stick to one topic per email, and make the subjects descriptive
– Keep subject lines intact, as archives and mail clients use them for threading
– If the topic changes, start a new thread
• Don't use attachments
– If you want to email code or documents, copy/paste in the email message or
provide a link to a web site (such as pastebin)
• Don't use HTML email
– It may confuse some mail clients, and cause formatting problems
• Reply and forward messages “inline”
– Some mail clients forward as attached text files; disable this

Mailing List Etiquette
• Reply at the bottom of messages
– Also called “bottom posting”
– Put your response after the text to which you are responding
• Posts with CAPITAL LETTERS will be ignored
• The way you communicate matters
– You will never lose points for professionalism
– Many participants are international, so be as clear and
straightforward as possible
– Avoid sarcasm, don’t take things personally
– Not everyone will be professional - “Don’t feed the trolls”
• Your conduct reflects on you and your company!

Responding to Feedback
• Feedback is likely to come in short, small bursts.
– Read, revise, and retransmit the code
– If you get someone that is reading and commenting on the code
each time, that's great! Keep sending the code.
• Feedback from developers may be brief or strongly worded
– Do not take it personally
– Maintainers process a lot of code, and must triage quickly
– Their goal is to improve code quality through intensive review
• Work with the community
– Take the good suggestions you get and incorporate them into
your code
– If there are solid technical reasons why bad suggestions are bad,
explain those reasons clearly

Etiquette When Replying to
a Patch
• Use "reply-all" by default, except in special
circumstances
• Never make a privileged conversation public
without the consent of the other party
• Keep the subject line intact, so you don’t break
threading
• Ensure HTML formatting is disabled

Etiquette When Replying to
a Patch
• Avoid mail clients that convert the original
message to an attachment when replying
• Always comment inline
• Do not delete the body of a message when
replying

Internet Relay Chat (IRC)
Etiquette
• ‘Lurking’ is acceptable behaviour on an IRC channel
– Just listening in on a channel helps you understand how
the project developers interact
• Don’t ‘ask to ask’ (or say ‘Is anyone here?’)
– If there is another conversation going on, wait until it
completes
– If there is no other conversation, just ask your question
– Keep the question concise and to the point
– You never lose points by being professional
• Don't paste large code segments into an IRC
channel
– Provide a link to a web site (such as pastebin)

Internet Relay Chat (IRC)
Etiquette
• Be aware of time zones
– In large geographically-distributed projects, not all
developers are online at the same time
– Be patient and wait at least 24 hours for a response
• Ask your question multiple times
– Give updates on what you’ve tried to fix a problem
– Provide a summary later of any solution
– Consider posting a summary of any solution to the
project mailing list for archival purposes

Bug Tracking (Bugzilla)
Etiquette
• Keep bug reports concise but thorough
– Add all important details, but leave out unnecessary
information
– Provide specific details on how to recreate the bug
– Provide access to error messages
– Provide log file snippets, or, if the data is large, links
to pastebin or another website
• No pointless comments in bugs
– Don’t put ‘me too’ messages in comments
– In general, don’t comment unless adding
something new or important for the bug assignee
to know

Etiquette
• There is no community obligation to fix
bugs
– Do not demand bug fixes by a certain date/release
point
– If the bug is critical to you, offer to fix it yourself
or help the bug assignee fix it
• Criticize code, not people
– Be constructive in your criticism, do not attack
people

Etiquette
• Don’t change fields of bugs you don’t own
– Do not change priority, target milestones, etc.
– If you need to request a change, put a comment in the
bug itself
• Don’t complain about decisions
– If a maintainer has marked a bug as INVALID or
WONTFIX, don’t file a duplicate bug
– If you believe the decision was invalid, provide
supporting evidence in a comment

Top 5 Things to Remember

#5 – Understand
Community Governance
• Each community is different
• Contributions need to ‘fit’ with other code/patches

#4 – Understand
Community Motivators
• Successful communities are powered by motivated people
• Motivation can be: status, money, peer recognition

#3 – Be Careful of ‘Custom’
Licenses
• Communities do not work well with ‘custom licenses’
• Gaining contributors/momentum requires low barriers to entry
http://opensource.org/licenses/index.html

#2 – Communities Need
Nurturing
• Posting code to public sites is not collaboration
• Community participation is a cycle – expect change

#1 - Be Humble, But
Bold
• Community leadership is earned, not granted
– Accept community feedback and rework code
• Bring technical expertise to the table
– Contributions need to be ongoing to maintain leadership status
Humble Bold
Leadership != Control

Thank you.

Developing Open Source Leadership

More Related Content

Similar to Developing Open Source Leadership

More from Samsung Open Source Group

Recently uploaded

Developing Open Source Leadership

Editor's Notes