Hitchhikers Guide to Participating in Open Source talk prepared for PyCon 2014.
This is the extended version that was cropped down to make the final talk.
10. Copy or Transmit
Display or Perform
Sell
Change!
(Remix/make Derivative works)
COPY "RIGHTS"
Assumed to apply automatically.
11. "TO EVERY COW ITS CALF
TO EVERY BOOK ITS COPY"
Jurisdictions similar, enforcement varies.
12. fixed
in any
tangible medium
“
”
creator of a
creative
expression
“
”
Jurisdictions: rules same, enforcement varies.
17 USC §102 Frank Siler "Copyright and You" PyCon 2013
20. FOSSLicensing isa Hack on Copyright
Copyleft doesn't exist without Copyright.
"PROMISE" NOT TO SUE
21. Offsets Copy"rights" as"Freedoms
(and other stuff)
63 Recognised Licenses
GPL and LGPL; Apache License; BSD;
MIT License; Mozilla Public License 2.0;
OPEN SOFTWARE INITIATIVE
+28 rejected licenses.
22. If you're not sure:
Assume your work is Derived
Inherit the original license.
or
Don't copy/use the software.
DERIVED WORKS
25. Wait: AmI theCopyright Holder?
At what point could you re-license Windows?
Your own script?: Yes!
A framework specific plugin?: .. maybe
DERIVED WORKS
"COMP8440: FOSS and the Law"
26. 15% of all repositories had license files
(ie: 85% arenotFOSS)
GITHUB PROJECTS
WITH LICENSES
"all the fruits in the forest are poisonous"
28. .. depends on the project.
What Licensedo I pick?
THIS WAS
MEANT TO BE FUN ...
Very complicated.
29. Would you remember to consider everything?
LimitationofLiability
Disclaim Warranty
(or you can still be sued)
USE AN OSI LICENSE
Carl will be talking which licence to choose after me.
30. 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.
” Don't write your own:
"COMP8440: Licensing" (3min) 18 years later.
31. 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
MODERN CASE STUDY
“
”The term "exploited" is being used a bit lately.
33. Feel strongly about being
exploited by the man
(pick copyleft: eg GPL).
Believing the
community will conquer all
(pick permissive: MIT, BSD, etc).
I am so not a lawyer.
34. Every last major tech company is FOSS now.
QuestionCopyright.org
"SOCIAL WASTE
TRANSACTION COST"
quote Daniel B. Ravicher (famous lawyer)
35. Don't have to enforce.
Breach? Ask politely
.
If you have a good license
can ask FOSS lawyer for help.
(probably unintended)
USING YOUR LICENSE
With GPL never has the little guy lost (groklaw).
36. Outside the Scope of this Talk:
Changing your License
Copyright Assignment/("Contributor Agreements")
Re-licensing
(issuing a license specifically)
Multi-licensing
USING YOUR LICENSE
37. Software Freedom Law Centre
Software Freedom Conservancy
Free Software Foundation (FSF)
Electronic Frontier Foundation (EFF)
Creative Commons, QuestionCopyright, GrokLaw
MODERN HEROES
We need more technical lawyers.
41. Pretty much anything
anyone ever does is for this,
our brains are wired this way.
Recognition
TO FEEL A SENSE OF
CONNECTION
Meet like-minded people.
42. "SKILLUP"
HOW TO BE THE "BEST"
Trythings don't do "during theday"
PursuePerfection
BEST SCHOOL
Do cool things with people better than you.
44. "Make the
world a better place."
Moral values
Democracy/Meritocracy
But not everyone!
ETHICS AND ALTRUISM
Not cool to talk about in old-skool projects.
45. Studying?
Bored with work?
Do something fun and productive.
CONSTRUCTIVE
PROCRASTINATION
Some of the best FOSS projects in history.
48. How big is the project?
How technical and serious is the project?
What is its scope?
KINDS OF PROJECTS
Can't independently derive this stuff.
49. How old is the project?
Where in its lifecycle is it?
~ New project
~ Active progression
~ Mature, maintenance phase
~ Dead
KINDS OF PROJECTS
50. How many people are involved?
What clear roles are defined?
~ BDFL/s
~ Release Manager
~ Core Developers
~ Governance Structure/Software Foundation
KINDS OF PROJECTS
55. Very tiny number of famous projects need:
highly skilled, specific help.
Vast majority of projects need:
all the help in the world.
VERY BIG AND VERY SMALL
56. HAVE A BASIC IDEA
OF THE PROJECT
BEFORE DIVING IN.
For your own sake.
Can have diametrically opposing experiences.
62. What's your interest?
What's your strength?
What skill do you currently want to work on?
What problem to you want to solve?
What do you do in your spare time?
weird form of teamwork
Personal need/"Scratching your own itch"
63. HAVE A GOOD
INTERNAL SENSE
OF WHEN YOU'RE
USING FREE SOFTWARE
LEARN TO LOOK
(which I trust everyone here does ...)
64. LearntoLook
for waysyoucan help.
If you have the right attitude interesting
problems will find you.
THINK LIKE A CONTRIBUTOR
“Lesson #4 The Cathedral and the Bazaar
Go beyond being a Passive User
65. Details, details, details
Isolate, replicate and report bugs properly.
Read and understand documentation
THINK LIKE A CONTRIBUTOR
(spelling, cruft, etc).
When you find bugs:
(for clarity and coherence).
Remember: You're contributing effort, it takes energy.
67. #1 Seek/Find/Reach out
notice itch
find code (eyeball community)
#2 Do your thing
fork, clone
poke around code (grep, code, etc)
commit, push (to your version)
#3 Send back your work
pull-request (comment/email)
68. #1 NoticeItch, Find Source
Seek/Find/Reach out.
#2 Work on your Contribution
#3 Returnyour Contributions
Notify project, get feedback.
69. For your firstcommit:
Punch your weight
Play to your strengths
Have realistic expectations
Talk to the project!
MY FIRST CONTRIBUTION
First time: Like dinner parties and marathons
don't attempt something you've never done before.
70. FIND OUT HOW TO (WHO)
COMMUNICATE
FIND OUT HOW TO
COMMIT
71. Well known projects have:
serious,
dedicated,
committed,
professional
people working on them.
These people have taken serious time and effort.
72. "Ecosystem" around big projects
~ Work up ranks (hard work over long time).
~ Make plugins.
~ Be a good "Cultural fit".
CONCEPT OF "CORE"
Trustworthy committers are a very limited resource
73. Learn the "style" of the existing project.
(Phrasing, structure, etc)
If in doubt: copy
Don’t make up a new style: ask!
There will probably be rules.
Follow them (eg, PEP)
PROJECT STYLE
Step where they step.
74. CONFERENCE SPRINTS!
Tools/projects you use.
Projects people you know are working on.
Projects within your "domain".
"Learn to look" redux
FINDING PROJECTS
After the closing address in about 3 hours.
79. (Stable/Working) >(your Ego)
Expect to get Rejection
but playful, friendly, caring rejection.
Aspiring to Concensus-Based Perfection
(rather than minimum viable product)
HOW FOSS IS DIFFERENT
Particularly in famous projects: free ⊄ ideal
80. In FOSSif you'regoing to: FailFast!
Hot white fear, nobody wants to look stupid.
Do document your failures.
Don't fail on the same thing repeatedly.
Don't assign blame.
FAILURE IS NECESSARY
Failure is comparatively cheap for us.
81. Learn to take"feedback"
(iecriticism)
Accepting criticism is actually a skill.
YOU ARE NOT YOUR CODE.
Development is a continuum.
HOW FOSS IS DIFFERENT
Giving good constructive criticism
is a really hard skill.
82. My patch is amazing
accept it now.
✗
Who is this guy?
Do you think this
patch is OK?
✓
OMG, God wrote this patch.
BE OVERLY MODEST
"completely and self-deprecatingly truthful"
83. SmallProjects
Can Turn on a Dimefor Your Idea
Envisioning and implementing
is expensive for small projects.
SOME PROJECTS ARE FLEXIBLE
(Big/Famous Projects are Not)
Maybe it is about the uber-ego commits.
85. YouareHerebyChoice
Engage Socially
You are statistically more likely to stay involved
with the project for longer.
HOW FOSS IS DIFFERENT
IRC, Email, Sprints, User Groups, Conference
87. Ask your employer!
Give back donate some of your time to the
projects you use at work.
Openly License your internal packages/projects.
THINGS YOU CAN DO
Some of these kinds of projects can be successful.
91. Code Review (learning)
Every project needs:
Designers, Content makers, Writers
Translations!
Many kinds of unusual task!
AS A NON-CODER
All these things take tremendous talent and effort.
92. BeModest and beOK with Yourself
Be confident you can do something they can't.
Beware of the gaping holes in their knowledge
outside code and be gentle about this.
AS A NON-CODER
Programmers aren't very smart,
they will mirror: if you're comfortable they will be.
96. Programming is easy
Software is hard
Only onepersoncould
work on a project atonce.
VERSION CONTROL SYSTEMS
Like "Shared document" but terminator style.
97. SCCS (1972)
RCS (1982)
CVS (1986/9)
SVN (2000) ~60% FOSS 2008
Most Free Software
ever developed.
CENTRALIZED
All these systems are open source.
99. Should youFork?
Centralized: "Forking" is BAD
Distributed: "Forking" is the first thing you do.
DIFFERENCE: FORKING
Discouraged (can be an act of aggression).
109. "Advertising" helps.
Maintenance and care helps.
Enough code to convince
potential co-developers.
FIRST TIME?:
DON'T EXPECT CONTRIBUTORS
"plausible promise"
110. Phrase your problem in a way that's
easily accessible to the
person with the right skills.
Offer Recognition
GETTING OTHER PEOPLE
TO HELP
114. Don't Automatically Reject/Revert
Don't let people find out through an
automated system.
Drop a quick note,
there's usually a reason.
Humans hate rejection, chips away at your soul.
116. 1957 argument that organizations give
disproportionate weight to trivial issues.
Time spent in discussion will be in
inverse proportion to the complexity.
PARKINSON'S
LAW OF TRIVIALITY
“ ”Resist the urge to weigh in, unless asked personally.
117. Like-Attracts-Like
Firstly: Do No harm
Good Judgement
Politeness, Respect, Patience
CHOOSE YOUR CULTURE
Like a motley family, where people can come and go.
118. Your role may tend to be:
Firefighter
Anti-bikeshedder
AS A PROJECT OWNER
120. Be Optimistic (not stupid, hopeful but realistic)
Be Patient, Fair & Tolerant
Have decent Judgement and "Taste"
Traits of a good Leader?:
perhaps: Strength & Resourcefulness
BE A GOOD LEADER
Hard to tell who will make a good leader.
121. "Pull Request Zero"
Have a non-code person
who answers pull requests.
AS A PROJECT OWNER
No feedback makes people think you don't want them.
122. Never Know Who'sWatching
You probably have quality sleepers/lurkers.
You will never see contribution from people
you (or your community's) behavior turns away.
ALWAYS BE CORDIAL
123. .. or you will burnout.
Writea list
highlight thethingsyoulove.
Give everything else away!
LET GO!
124. According to the research:
Average involvement is between:
3 months and 2 years.
PeopleChange!
EMBRACE YOUR CHURN
... and they should!
126. Most of our toolstakeYEARSto learn!
Learn our Basic Tools
We expend most of our effort/lives with them.
The all take practice
it's easy to stagnate.
MASTER YOUR TOOLS
Programmers are often self-taught/from other fields.
127. Text Editor
Pick a good one, learn to use it well.
MASTER YOUR TOOLS
Programmers are often self-taught/from other fields.
128. Version Control (git, hg, svn, etc)
Learn basic commands solidly.
Get comfortable with major operations
( reverting, resolving conflicts,
merging, branching, etc).
MASTER YOUR TOOLS
Programmers are often self-taught/from other fields.
129. Issuetracker
Learn to Write a Good Bug Report:
~ Be Descriptive
~ Do the Homework
"Design decision needed"/"close"v."feedback"
MASTER YOUR TOOLS
Special hell for people who just copy/paste traceback.
130. Command Line(CLI)
Learn to use it well (go beyond ` cd`).
Regular Expressions ( regex).
grepand find
MASTER YOUR TOOLS
aliasing, wildcarding, command substitution,
piping, variables/control structures, iteration, etc
131. Mailing Lists/IRC/IM
When/Which to use?
Who to ask about different matter.
General channels v. channels-with-a-purpose.
Language expectations.
Is there a code of conduct?
MASTER YOUR TOOLS
132. Learn to WRITE
Effectively Communicate
Have a working knowledge of popular markups
( ReST, markdown, etc).
MASTER YOUR TOOLS
(clearly)
135. ... and are solved by.
Communicate! Communicate!
95% human problems are caused by ...
COMMUNICATE!
Shallow and often.
136. StateIt Upfront
StateasSimply asPossible
brief, short, to the point, concise, succint
summary, pithy, crisp, incisive
ASK/EXPLAIN: BE TERSE
“ ”No fluffy language, no big explanation.
Be cordial but just get to the core of it.
137. Do What YouSay You'reGoing to Do
If you can’t: Communicate!
FOSS people are spectacularly understanding.
DON'T SPEAK UP, if you're not "already there".
SET EXPECTATIONS
18%
139. Don’tagonise(spareyourself pain!)
Experienced people often can see/feel
you struggling .
ASK!
(but will be polite)
In short term: it may be intimidating to ask
In medium term: you're learning faster
They know the feel because they've been there.
140. Everyone does.
Everyone is about most things.
The "best" leverage
On feeling stupid:
(and are usually very humble).
SAYING: I DON’T KNOW
Nobel Prize 1996 "Buckminsterfullerene"
146. Don'tCriticiseother FOSSProjects
... without contacting the project first.
Send an email or submit a ticket.
Pull up anyone else you see doing this.
ON EACH OTHER'S TEAM
Save it for the proprietary world.
147. All mistakes will eventually be
washedcleanby timeand entropy.
Communitiesarevery robust.
DON’T GET DISHEARTENED
Nobody cares how many times you fall down,
ONE fewer than the times you get up all that matters.