Developing OSS Leadership (LinuxCon NA - 2014)

Developing Open Source
Leadership
Open Source Group –– Samsung Research America (Silicon Valley) 1
Guy Martin
Senior Strategist
Samsung Open Source Group
guym@osg.samsung.com
@guyma, @SamsungOSG

Content
• Open Source Development Model
• Best Practices
• Communication & Community
Skills
Open Source Group – Samsung Research America (Silicon Valley) 2

Open Source Leadership:
Why and How?

Product Dependency on Open
Source Technologies

New Open Source Skillsets

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

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
• Empower employees to seek contributor and maintainer
status

Open Source Development Model

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

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)

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

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 useful to all platform users – that they don’t want to
maintain themselves
– Source code that will help them influence the direction of the project
• 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

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

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’

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

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

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/

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

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

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

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’

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

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
Leadership != Control
Humble Bold

Thank you.

Developing OSS Leadership (LinuxCon NA - 2014)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie Developing OSS Leadership (LinuxCon NA - 2014)

Ähnlich wie Developing OSS Leadership (LinuxCon NA - 2014) (20)

Mehr von Samsung Open Source Group

Mehr von Samsung Open Source Group (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Developing OSS Leadership (LinuxCon NA - 2014)

Hinweis der Redaktion