The Hitchhikers' Guide to Free and Open Source Software Development (CompCon 2013)

THE HITCHHIKER'S GUIDE
TO
FREE AND OPEN
SOURCE
SOFTWARE
DEVELOPMENT

INTERESTING
TIMES

~ stream-lined communication
~ broad acceptance of technology
Golden age

WHY?
“DO” OPEN SOURCE

Who here

PUBLIC CODE PRESENCE IS
ATTRACTIVE TO
POTENTIAL
EMPLOYERS

support companies can hire what they see …
Hardware vendors have a big market for FOSS devs so that foss will work on their devices.

PUBLIC CODE PRESENCE IS
THE BEST CV EVA
Bitbucket

Gitorious

CloudForge

Google Code

CodePlex

Launchpad

GitHub

SourceForge

WHY?
OPPORTUNITY

if you want to be good

WHY?
OPPORTUNITY
People
Projects

best people that there are ...

WHO
“DOES” OPEN SOURCE
INVOLVEMENT
Creator
Contributor
User

WHO
INVOLVEMENT

USAGE

Creator

Personal

Contributor

Professional/
Corporate

User

WHO
INVOLVEMENT

USAGE

Creator

Personal

Contributor

Professional/
Corporate

User

Hobby

WHO
INVOLVEMENT

USAGE

Creator

Personal

Contributor

Professional/
Corporate

User

Hobby
Resource

WHY?
Open source
provides a unique opportunity
for the trifecta of
purpose,
mastery
and
autonomy.

WHY?
Learning
Socialising
Minions
Glory!
World Domination

WHY?
SOCIAL
Working with others
Working with people better than you
Exposure to other styles
Get exposure for your project

WHY?
EDUCATION
Opportunity to learn from others
Learn to avoid pitfalls/gotchas
Fast intro to common patterns

It’s exhausting

WHY?
SKILL UP
Try out new ideas.
Try out new technology.
Try out development, unstable versions.
Do things you don’t do “during the day”.

It’s exhausting

WHY?
ETHICS/VALUES
Political Reasons
Altruism
Democracy/Meritocracy

WHY?
BUSINESS
Best Solution Available
Makes Sense for the Project

WHY?
BUSINESS REASONS
• Security

• Interoperability

• Quality

• Auditability

• Customisability

• Support

• Freedom

• Cost

• Flexibility

• Try-Before-You-Buy

Options

QUALITY
“If you have enough
eyeballs all bugs
are shallow.”
Linus’ Law
(actually pre-dates him)

CHOICE AND TRUST
No need to trust software vendor.
Choice to ﬁx yourself.
Right to fork if disagree.
Can contribute.

It’s healthy to question your own work!
It’s healthy to freely collaborate!
PRACTICAL terms

WHAT IS
“OPEN SOURCE”
ANYWAY?

FREEDOM
Free as in “Speech”
or as in “Thought”

community that emphasises the individual over the “organisation”
vs.
company presents a facade

IN THE BEGINNING
... was the
Command Line

IN THE BEGINNING
... was the
incident at MIT Artiﬁcial Intelligence Labs
with the printer drivers in about 1971

SOFTWARE SHOULD BE ...
Completely PRIVATE

v.

Completely FREE

Completely PRIVATE
Sell
v.
Share
Completely FREE

Completely PRIVATE
(Bill Gates)

..
v.

(Richard Stallman)
Completely FREE

Completely PRIVATE
Corporations
v.
Hackers
Completely FREE

Completely PRIVATE

v.

Completely FREE

rights individual
higher purpose
progress of technology

Completely PRIVATE
Protect Owner
v.
Protect Freedom
Completely FREE

rights individual
higher purpose
progress of technology

Completely PRIVATE

v.

Completely FREE

These rules hadn’t been made up
In wasn’t obvious

Completely PRIVATE
Product
v.
Individual
Completely FREE

These rules hadn’t been made up
In wasn’t obvious


... THE AUTHOR DECIDES

AUTOMATICALLY GRANTS AUTHOR
EXCLUSIVELY RIGHT TO:
To produce copies or reproductions to sell or distribute.
Create derivative works.
To perform or display the work publicly;
To transmit, import or export the work.

This is the essence of why licenses matter.

NO ONE ELSE CAN DO THESE THINGS
WITHOUT THE AUTHOR’S PERMISSION

NO ONE ELSE CAN DO THESE THINGS
WITHOUT THE AUTHOR’S PERMISSION
If they do, the author can sue.

ORIGINAL SOFTWARE
FREEDOMS (~1976)
* The freedom to run the program, for any purpose.
* The freedom to study how the program works, and adapt
it to your needs.
* The freedom to redistribute.
* The freedom to improve the program, and release your
improvements (and modiﬁed versions in general)
Access to the source code is a precondition.
(obviously)

OPEN SOURCE DEFINITION
1. Free Redistribution
2. Source Code
3. Derived Works
4. Integrity of The Author's Source Code
5. No Discrimination Against Persons or Groups
Things that are explicitly stated.

~ as in beer -- no royalties or fees
2. Source Code
3. Derived Works

2. Source Code
~ not obfuscated or require preprocessor, translator, etc
3. Derived Works

2. Source Code
3. Derived Works
~ can be remixed

2. Source Code
3. Derived Works
~ can be remixed
~ rename your version

6. No Discrimination Against Fields of Endeavor
7. Distribution of License
8. License Must Not Be Speciﬁc to a Product
9. License Must Not Restrict Other Software
10. License Must Be Technology-Neutral

Need to be speciﬁed because they’ve been challenged

~ eg. commercial use or “values” (genetic research)


~ applies to next person down, but not next after that


... except if being repackaged and redistributed


... except if being repackaged and redistributed
~ platform or “style of interface”

PROPRIETARY
OPEN SOURCE?
CAN:
give away source and accepted changes
(for free as in beer)
CANNOT:
use the term “Open Source”
as it’s trademarked

PROPRIETARY
OPEN SOURCE?
For your own sake be aware
of where you’re directing your efforts.

LIABILITY
Giving away for free (as in beer)
does not exempt
from being sued.

“This program comes with
ABSOLUTELY NO WARRANTY”

lifesaving
landing aircraft

OPEN SOURCE
PHILOSOPHISING
Traditional FOSS projects have
strong technical focus
and tend to avoid philosophy.
There are dedicated channels for
talking about FOSS philosophy and principles.
In more modern projects there is a resurgence in
interest if you learn some background.
Aaron Schwartz

FREE AND OPEN
SOURCE
SOFTWARE
PROJECTS

Mailing Lists

ACTUALLY LOOKS LIKE THIS:

Mailing Lists

IRC

ACTUALLY LOOKS LIKE THIS:

Bug/Issue Tracking

AND THIS ...

BUT SRSLY ...
Completely PRIVATE
Product
v.

INDIVIDUAL
Completely FREE
community that emphasises the individual over the company
vs.
company presents a facade

One of most important messages of this talk!
Beautiful bouquet that is humanity

EVERY
PROJECT
is
DIFFERENT

One of most important messages of this talk!
Beautiful bouquet that is humanity

COMMUNITY CULTURE
IS NOT SCIENCE
You can not independently derive this stuff.
... and no one expects you to.
Do your research and listen.
Follow the precedent.

PROJECT
TECHNICAL SPECS
How:
responsive, receptive and welcoming
will vary dramatically

PROJECT VARIABLES
• Technology

Andrew Tridgell says: spend a couple of weekends or whatever

PROJECT VARIABLES
• What’s

its scope?

• What’s

• Technology

its proﬁle?

• How

big is it?

• How

old is it?

• Where
• How

in its lifecycle it is?

active is it?


PROJECT VARIABLES
• Technology

• What’s

its scope?

• Who?

• What’s

its proﬁle?

• How

well organised is it?

• How

big is it?

• How

is it structured?

• How

old is it?

• How

are decisions made?

• Where

• How

does it communicate? • How active is it?

in its lifecycle it is?


PROJECT VARIABLES

TECHNOLOGY
Technical Depth
[many possible dimensions]

you know what? scratch that, I’m actually going to come back to this later.

PROJECT VARIABLES

What’s its scope?
[Linux Kernel .. .. some niche script]
What’s its proﬁle?
[Python .. .. some widget]

PROJECT VARIABLES
How old is it?
FOSS Projects are hard to kill.
Where in its lifecycle it is?
[Alpha .. .. Established]
Where in its story arc it is?
[Surging .. Stable .. Dying]
samba died twice
dead cat bounce

PROJECT VARIABLES
How big is the codebase?
How big is the program/application?
[Twitter .. .. ]

Sometime big codebase on small application
is a good thing.

PROJECT VARIABLES
How big is the community?
What kind of people are in the community?
[technical, organisational, social, experimental ...]

PROJECT VARIABLES
CATHEDRAL

v.

BAZAAR

PROJECT VARIABLES
How active is it?
[17K emails/month .. .. couple of patches/year]
Faster moving is less tolerant.
Bigger can be more tolerant.

WELCOMING COMMITTEE
Projects might have someone whose role is
to guide new people.
Apache have a whole system.
The project leader might give you
all the time in the world
for a brand new project.
There will probably be nothing at all.
this week, we found a big in plug in
made a patch
it was pushed and released in about 15 minutes

PROJECT VARIABLES
SUMMARY

You will have
completely different experiences
depending on the project.

PROJECT VARIABLES
SUMMARY

Have a basic idea
of the nature of the project
before diving in.
It’ll grease the rails,
make it easy for yourself.

DECISIONS
NEED TO BE MADE
Design
Legal/License
Development Environments and Tools
Triaging
(dealing with incoming)

Someone has to make them.

PROJECT GOVERNANCE
Formal
v.
Informal
Organisational Structure
(gotta have one)

OK so honestly very few projects have formal structure
Most projects are informal
If you have an organisation ... even if it’s rubbish

PROJECT GOVERNANCE
Formal
Constitution
Ofﬁce holders, Board or Steering committee
Annual election
(Debian; Gnome)
Not-for-proﬁt “Software Foundation”
(Apache SF, Python SF, Django SF)
Usually happens when big enough to involve
money and lawyers.
Office holders, “official” membership
common pattern

PROJECT GOVERNANCE
Serious v. Not (silly)
Vast majority of projects are side-projects.
Generally side-projects are less serious
but not necessarily.
Is someone basing their career on it?

ROLES
There is usually identiﬁable author or leader.
Is there an identiﬁable team?
What roles are there?
What roles aren’t there?

ROLES
BDFL
Benevolent Dictator/s For Life
More commonly used in this era.
Usually original author/s.
Though there are exceptions.
Dictates ﬁnal decisions, arbitrage and ends disputes.
Project leader for so long

ROLES
Release Manager
Packaging
Pass tests
Right documentation
Right internationalisation (i18n)
No “release blocking” bugs
Release announcement.

Project leader for so long

ROLES
System Admin (servers, etc)
Website
Artwork
Licenses
Answering Questions
Newb wrangling
(we were all newbs once, we’re all newbs about most things ever, it’s just a phase)

Karen/Russ, django users

GETTING
INVOLVED

How many people use version control regularly/proﬁciently?
101 stuff ... most of are self-taught in most areas, worth glossing over.

START SMALL
A lot of people’s FOSS careers
start with a
one character
patch.
(particularly to big, old, established projects)

You don’t have to “prove” your mad-coding-skillz
or change the world in your ﬁrst commit,
moreover you certainly shouldn’t.
If you know everything else I’m going to talk about here, but still aren’t involved:
Particularly to big, old, established projects
Goes against our instinct

START SMALL
Projects hate:
Big, unexplained patches
from people unknown to the community.
Not impressive.
Big old projects may dismiss out-of-hand.
“dropping bombs”
“drive by shootings”
Even if it’s good code -- it’s just not done that way.
It’s got to be consumable by the project.

START SMALL
Break up your
feature
in to
patches.

should do this anyway.

VERSION CONTROL
AKA SOURCE CONTROL
MANAGEMENT (SCM)
How many regularly use version control?
Don’t want to bore to tears.

VERSION CONTROL
BASICS
Assume:
THERE IS NO UNDO BUTTON
Everything you commit is on the public record. Forever.
Commit with care.
Do NOT be reckless.

WHAT IS
VERSION CONTROL?
Writing code is easy,
constructing programs is hard.
Many people
working on same codebase is hard.
Solution: take small, logical, incremental steps.

in the form of ...

ALWAYS SMALL
Always take the time to
break up your patch into the
smallest, logical unit.

Easier to understand for everyone
(committer, future-you).
Easier to revert.
Rule of thumb: what you may need to revert.

DIFF/PATCH
The tiny step is called a: patch
Small, logical, incremental steps.

Ofﬁcial terms: diff and patch.
These were the original tools that were used.

Atomic unit of code development.
Patch originally written by Larry Wall
Tapes, TAR in the beginning,
actually learning SCM takes years

DIFF/PATCH
Put code changes into standardised format.

Standard is: “uniﬁed format”
(or “unidiff” or “-u”)

$ diff -u ...


UNIDIFF

wikipedians may be familiar

UNIDIFF

A PATCH! any unidiff scm will be able to “APPLY” this
you can write these by hand if you want
can be reversed (or “reverted”)
some examples without original source

DIFF/PATCH
Congratulations!
You have a patch ﬁle!


The patch/s are then “sent*” to the project.
*what this means varies.


COMMITTING/INTEGRATING
Code change is then
committed or integrated
in to a version of project.
Though it’s normal for patches to be rejected.
Your patch might directly conflict with someone else’s work.
this is known as a merge-conflict
and usually needs human arbitrage to fix.

SEND/MERGE/COMMIT/
PUSH/PULL-REQUEST
... sent* to the project ...

This is where projects become so divergent
own research needs to be done to on this process.
A lot of project use multiple integration methods.

PATCH SUBMISSION:
LINUX KERNEL EXAMPLE
Very strong rules.
Very clear guidelines.
https://www.kernel.org/doc/Documentation/
SubmittingPatches
5,000 word piece of documentation
which is strongly adhered to.

PATCH SUBMISSION:
LINUX KERNEL EXAMPLE
Patches to Linux Kernel are submitted by email.
They get a lot of email:

lkml.org/lkml/2013/
20-25 emails an hour, depending where in the world

SOURCE CODE
MANAGEMENT
(SCM)
SYSTEMS

WHAT IS SOURCE CODE
MANAGEMENT (SCM)?

WHAT IS SOURCE CODE
MANAGEMENT (SCM)?
Where is your MASTER codebase repository?

WHAT IS SOURCE CODE
MANAGEMENT (SCM)?
Early version control system:
CENTRALISED SERVER

CENTRALISED
VERSION CONTROL
FIRST GENERATION SCM
+
-

Provides development history
Manages ﬁles individually
Only one person editing at a time
No merge capability
eg, SCCS (1972), RCS (1982 free and more evolved)

rcs 1982

CENTRALISED
VERSION CONTROL
CVS (CONCURRENT VERSIONS SYSTEM)
+
+
-

Parallel development
Merge & conﬂict resolution (based on diff/patch)
Poor rename and directory support
Poor branch merging
Most operations require contacting centralised server
Dominated FOSS 1991 to 2005.
Use can still be found.

1990

CENTRALISED
VERSION CONTROL
SUBVERSION (SVN)
+
+
-

‘CVS done right’
Project-wide revisions
Each developer has ‘checkout’
Most meta-data is only stored on central server
Committing require contacting central server
Very commonly used before new generation.
Still commonly used.

WHAT IS SOURCE CODE
MANAGEMENT (SCM)?
Since early 2000s
DISTRIBUTED

Everyone gets a ‘clone’:
+ entire codebase
+ entire revision history

DISTRIBUTED
VERSION CONTROL
BAZAAR (BZ)
MERCURIAL (HG)
DARCS
MONOTONE (peer-to-peer)
GIT

Since great Distributed Version Control wars of ~2005
started in the 90s, blew out ’02-05 when linux switched to not GIT (bitkeeper)

Currently has a lot of support and momentum.

People say it’s complicated.
TAKE CARE MENTALLY VISUALISING STATE OF CODE

necessarily complicated!
install git

WHAT IS A GIT REPOSITORY?
Any ﬁle tree with the special /.git directory

~ delete and ceases to be
~ can put anywhere and it will try and ﬁgure out

WHAT FILES ARE IN A
GIT REPOSITORY?
Explicitly add and rm ﬁles to/from repository

can put in any dir, but won’t know until you tell it.

WHAT FILES ARE IN A
GIT REPOSITORY?
Explicitly add and rm ﬁles to/from repository
Be speciﬁc:
$ git add hello.txt
Or general:
$ git add .

can put in any dir, but won’t know until you tell it.

WHAT FILES ARE IN A
GIT REPOSITORY?
You can explicitly tell git to ignore the existence of certain files
listing files to be ignored in:
.gitignore
This can be per directory.

Gotcha: .gitignore won’t work on files
you’ve already added.

GIT CLONE

~ all revision history
~ entire working codebase

GIT CLONE
Find an open source repository.


GIT CLONE
$ git clone https://github.com/jquery/jquery.git


GIT CLONE
$ git clone https://github.com/jquery/jquery.git

The the code is yours. All yours.

MAKE CHANGES
FORK
If you’re going to make changes then fork the project.

Only make changes to your own tree.

Forking used to be an anathema.

MAKE CHANGES
BRANCH

Create branch:
$ git branch mydevbranch

Use branch:
$ git checkout mydevbranch

MAKE CHANGES
GENERATE PATCHES
So you’ve changed the code.
On your own fork.
On a development branch.

You need patches.

WHAT’S GOING ON IN A
GIT REPOSITORY?
$ git status

Will recognise ﬁle changes.
Automatically translate to patches/hunks.

WHAT’S GOING ON IN A
GIT REPOSITORY?
$ git status
Recommended GUI tools
Linux: gitg
others: SourceTree

GIT WORKFLOW
1. Make code changes.
Study your newly created patches/hunks.
(debug, debug, check, check, proof, proof)

GIT WORKFLOW
2. “Stage” patches/hunks
(using $ git add or GUI tool)

GIT WORKFLOW
“Stage” patches

GIT WORKFLOW
3. “Commit” staged changes to the repository.

GIT WORKFLOW
3. “Commit” staged changes to the repository.
(using $ git commit -m “handy mandatory message”)

VERSION CONTROL
BASICS
Rule #0:
Assume everything you commit is
FINAL and FOREVER

Rule #1:
NEVER commit your PASSWORDS
or any other sensitive or personal settings or information.

VERSION CONTROL
BASICS
Rule #:
Don’t commit buggy code.
Way to burn trust and respect.

Rule #:
Atomic changes. That is: SMALL, logical changes.
Break up feature in to a bunch of smaller patches.
Drive-by patches are universally despised.
whole weekend

VERSION CONTROL
BASICS
Rule #:
Explain yourself.
Be terse, clear and explain why change is necessary.

Rule #:
The committer’s time is probably more valuable than yours.
Being fewer of them it’s probably true.

COMMITTING
Congratulations!
You have a commit.


PUSHING


Got it? you make a change, you ask the main project to “pull” it in to their project

COMMITS/PULL REQUESTS
Committed patches
may then be “pulled” in to a version of project.

Committed patches
They usually don’t do this automatically.

Committed patches
You ask the “upstream” to accept your
commit using a pull-request

Committed patches
You ask the “upstream” to accept your
commit using a pull-request
pull-requests are regularly not accepted.
(it’s not personal).

CONTRIBUTING
“STYLE”
Learn the “style” of the existing project.
Phrasing, structure, etc.
There will probably be rules. Follow them. eg: PEP8
If in doubt: copy
Don’t make up a new style, you’ll look like a fool -- ASK!
NOW you have TOOLS to COMMUNICATE and CONTRIBUTE
TOO BIG: RKM learnt in weekend, core within a month or two.
But noone on earth doing for linux kernel -- drive by shootings, gotta know you, trust you -LINUXCON LAST WEEK

CONTRIBUTING
COMMUNICATE
Shallow and Often
.


CONTRIBUTING
COMMUNICATE
Don’t be out on a limb!
.


SAY
THANK YOU
Occasionally send an email or make a post saying:
“Thanks!”

No matter how big or famous a project,
there’s usually more criticism than thanks.
It’s nice to be grateful :)

DON’ T ASK ME


Growing Open Source Seeds
How (Not) To Build An
OSS Community
Kenneth Reitz
* Hello
* Enjoying PyCon? Food Coma?
* Talk about something near & dear: community

Questions?

github.com/kennethreitz

Thanks.
Questions?
@daniellindsley
https://github.com/toastdriven

Running an open source project

OPEN SOURCING
A PROJECT
“cookiecutter”
projects on github.
Detailed blog posts.

EXISTING PROJECTS
Do you actually want help?
“My Precious”
Let others in.
Consider the beneﬁts of help!
All the things you no longer have to think about.

EXISTING PROJECTS
Think about what needs to be done.
Write a post about how other people can do.
If you want help, be speciﬁc.
Explain exactly what and how.
Write a list.
Make tasks and issues.

EXISTING PROJECTS
INSTALLATION and DEPENDENCIES

For the love of humanity ...
Ensure it’s possible to compile/install!
er, documentation?
Write it down as you’re doing it.

EXISTING PROJECTS
TEST DATA

For the love of humanity ...
Give us something to play with!

JSON, XML, Sqlite3, scripts ... anything ...

GOOD LEADERSHIP
Don’t REJECT or REVERT without an explanation.
Contact the contributor before you do it.
Don’t let them ﬁnd out publicly ﬁrst.

It’s gutting to have something rejected, but there’s usually
a good reason -- explain it! It makes it OK.

EXISTING PROJECTS
COMMUNICATE
95% of human problems
... are caused by and
can be solved by ...

EXISTING PROJECTS
COMMUNICATE
Shallow and Often
.

EXISTING PROJECTS
COMMUNICATE
Things that seem obvious,
often aren’t obvious.
.

EXISTING PROJECTS
COMMUNICATE
... that includes listening.
.

EXISTING PROJECTS
BURNOUT

Take time off.
Ignore everything except security issues.


EXISTING PROJECTS
BE NICE
If someone leaves:
Thank, don’t bitch
Don’t bitch about open source project
without contacting owners, reporting bug
(random blog post!)
>> if anyone you know does this call them out on it.


LICENSES

Don’t want to go too deep on licenses.
It’s boring as batshit
If you care, you care a lot.

LICENSES
Bad license decisions
have long term consequences.

Unfortunately there are no easy answers.

LICENSES
Original samba license:

Copyright (C) Andrew Tridgell 1992.
Permission to use, copy and distribute this software is given to anyone who
wants to, for NON-PROFIT only. You may not charge for this software or any
derivatives of it without first contacting the Author.

LICENSES
OSI lists 63 approved licenses, 9 as 'widely used'
GNU lists 81 free software licenses plus 28 non-free licenses

LICENSES
GPL
GNU Public License.

You must keep the software open.
You must give your changes back.

LICENSES
GPL V2
pre-GPLv3 (2007)
FOSS Licenses were much simpler.
75%+ projects were GPL.
If you liked a company, you would license as LGPL.
Number of other licenses, notably:
BSD (Berkely)

LGPL:
● Allows linking with proprietary programs
● Also used to avoid inter-project licensing problems

LICENSES
GPL V3 (2007)
Written to address:
● Internationalisation and clariﬁcation of legal language
● Stronger patent provisions
● Prevention of hardware restrictions (“tivoisation”)
● Optional clauses to aid license interoperability
● DMCA avoidance (“effective technological measure”)
It is a very good license. Arguably too good.
There has been a trend away from GPL.
It would be impossible for apple to comply with the GPLv3 license requirements on iPad and
iPhones unless they license devices' security systems as same.
GPLv3 licensed software will not get in to any app store. full stop.

LICENSES
COMPATIBILITY
Probably not fun.
~15% of all repositories had license ﬁles
~25% of those have the license only
mentioned in the Readme ﬁle

Read more: Armin Ronacher (author of Flask), Late July, 2013
Can tell because people like Apple and Google don’t want a bar of it.

LICENSES
POST-GPL
Interesting Times
Most popular: GPL
Apache Software License 2.0 (ASL2)
BSD
(with additional clauses)
(do whatever you like, just don’t sue me, even close source)
MIT
(do whatever you like, just don’t sue me)

LICENSES
Mongrel: popular ruby web server
Zed Shaw
Under one of “please don’t sue me” licenses.
Later regretted decision.

Until recently “Twitter” used it (on top of Apache).

LICENSE:
ZED SHAW
“Open source to open source,
corporation to corporation.
If you do open source,
you’re my hero and I support you.
If you’re a corporation,
let’s talk business.”

TOOLS
Learn to use:
Text Editor
(pick a good one, learn to use it well)

Source Control Management (SCM)
(eg: git)

These take YEARS to learn!

TOOLS
Learn to use:
Issue tracker
(not as obvious as it seems)
IRC
Mailing-lists

“Design decision needed”/“close” v. “feedback”
ﬁelds you should and shouldn’t ﬁll in

TOOLS
Learn to use:
Command Line (CLI)
(eg: bash)
grep (or ack) and find
Regular Expressions
(aka: regex)

TOOLS
Learn to:
WRITE
(clearly)
Popular markups:
ReST
Markdown
Honestly these 10-odd tools are my day-to-day everything.

SAYING: I DON’T KNOW
Harry Kroto

On feeling stupid:
Everyone does.
Everyone is about most things.

The “best” leverage this
to their advantage
(usually very humble.)
HE ... was
IT’S a CONTINUUM

ASK/LISTEN
Rule of Thumb:
stuck for ½ hour.

Go to: IRC, mailing-list
Don’t agonise, spare yourself the pain!

Often:
~ experienced people can see/feel you struggling (but seldom say anything)
~ so, in short term you feel like gumby BUT: learn something, might actually look clever
~ in medium term: your corpus is building faster

ASK/EXPLAIN
State as
simply as possible.
State it up front.
Time is precious: be terse
terse
təәrs/
adjective
1. sparing in the use of words; abrupt.
"a terse statement"
synonyms:
brief, short, to the point, concise, succinct, crisp, pithy, incisive,

No ﬂuffy language, no big explanation.
BE CORDIAL
Just get to the core of it.

BEING INVOLVED
Names/code
to
Faces/personalities

TURN UP!
Decisions are made
by the people
who turn up.

Hackerspaces
User Groups
Conferences

Congratulations you are already here.
Connect and develop.

SET PEOPLE’S
EXPECTATIONS
Probably the most valuable thing
I’ve learnt in the last 5 years.

CONTRIBUTING
COMMUNICATE
Find the venues to do so.
Mail-list
Might be several!
IRC
Issue Tracker
Wiki

BEING INVOLVED
Real world is not uni.
Flexible
FOSS is really ﬂexible.
Young projects can turn on a dime for your idea.
Envisioning and implementing all the ﬁne
details is expensive for new projects.

TELL PEOPLE WHAT
YOU’RE DOING
For their sake.
Save them from wondering.

DO WHAT YOU SAY
YOU’RE GOING TO DO
But, if you can’t
communicate!

FOSS people are spectacularly
understanding.

Don’t get disheartened.
All mistakes will
eventually be washed clean
by time and entropy.
Communities are very robust.

INTERESTING
TIMES
Stream-lined ability to contribute/communicate.
Culture is changing: tech is becoming mainstream.
Re-learning old lessons.

Not just chicks, it’s older, multicultural.

INTERESTING
TIMES
Demographic imbalance is being addressed.


CHANGING
DEMOGRAPHICS
Difference is a continuum.
Shared culture and technical knowledge.
Skills!


INTERESTING
TIMES
Demographic imbalance is being addressed.
Copyright is being questioned.
Patent-wars.
WATCH THIS SPACE

CONCLUSION
There will always be some form of
“Open Source”.
People like us will make it happen.
This is the version we’ve currently got and it’s changing.

Contributors: Be Cordial

•

Keep all interactions with a maintainer as
respectful as possible.

•

They have likely donated a significant
amount of time and energy into their project.

•

They don’t owe you a moment of their time.

Maintainers: Be Cordial

•

You have the crucial responsibility of being
immensely thankful to all contributors.

•
•
•

They are the lifeblood of your project.
Ignore non-constructive feedback.
Some people just take things too seriously.

Maintainers: Be Cordial

•

Be careful with the words you chose.
Contributors sometimes take what you say
very personally.

•
•

Take the opportunity to educate the user.

•

A little bit of kindness goes a long way.

This could be their first ever interaction with
an open source project.

Sustainability
•

Sustainability is one of the biggest
challenges of open source.

•
•

Everyone has a limited amount of time.
It’s easy to become the bottleneck of
your own projects.

Learn to Say No
•
•

Saying ‘No’ is extremely difficult.

•

If you say yes often, your project will be
ruined. Tragedy of the Commons.

People ask for crazy features. They send
seemingly practical pull requests. They
are trying to help.

But it’s HOW YOU SELL IT ...

Open source makes
the world a better place.

Focused Purpose
Move together or be torn apart by momentum.

* Be careful not to turn it into an end-all unless you’re sure it can be
* Spin off advanced/specialized functionality as a plugin that builds on top

Documentation
Just because you built it
doesn’t mean they will come.

* Except for rare situations (absolute need or so sexy!), without this, no one will use it
* Case in point: It’s why many of you know about Flask but virtually no one knows about Itty
* Lack of docs means most people will get frustrated & move on

Communication
Will make or break you.

* This goes along with focus
* People want to know it’s actively developed on, what the future holds, how to get help, how
they can help
* IRC
* Mailing lists
* Website

Make Contribution Easy
It’s the only way you’ll get any contribution at all.

* GH/BB model of fork & pull req
* Deﬁne **how** others can contribute
* I suck at this one

Listen
Graciously accept both positive &
negative feedback.

* You should consider yourself a success when you acquire haters
* Remember there are lots of happy people who are quietly using the software
* I’m super-thin-skinned, so I struggle with this one nightly

The Hitchhikers' Guide to Free and Open Source Software Development (CompCon 2013)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (10)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie The Hitchhikers' Guide to Free and Open Source Software Development (CompCon 2013)

Ähnlich wie The Hitchhikers' Guide to Free and Open Source Software Development (CompCon 2013) (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

The Hitchhikers' Guide to Free and Open Source Software Development (CompCon 2013)