the hitchhikers' guide to free and open source software development (compcon 2013)

THE HITCHHIKER'S GUIDE TO

FREE AND OPEN SOURCE

SOFTWARE DEVELOPMENT

http://en.wikipedia.org/wiki/The_Hitchhiker's_Guide_to_the_Galaxy




@elequ or elena

INTERESTINGTIMES

~ stream-lined communication~ broad acceptance of technology

Golden age

WHY?“DO” OPEN SOURCE

Who here

PUBLIC CODE PRESENCE IS ATTRACTIVE TO

POTENTIALEMPLOYERS

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

Bitbucket

CloudForge

CodePlex

GitHub

Gitorious

Google Code

Launchpad

SourceForge

PUBLIC CODE PRESENCE IS THE BEST CV EVA

github.com

bitbucket.org


OPPORTUNITY

if you want to be good


OPPORTUNITY

People

Projects

best people that there are ...

WHO“DOES” OPEN SOURCE


INVOLVEMENT

Creator

Contributor

User


INVOLVEMENT

Creator

Contributor

User

USAGE

Personal

Professional/Corporate


INVOLVEMENT

Creator

Contributor

User

USAGE

Personal


Hobby


INVOLVEMENT

Creator

Contributor

User

USAGE

Personal


Hobby

Resource


Open source provides a unique opportunity

for the trifecta of purpose, mastery

and autonomy.


Learning

Socialising

Minions

Glory!

World Domination


SOCIAL

Working with others

Working with people better than you

Exposure to other styles

Get exposure for your project


EDUCATION

Opportunity to learn from others

Learn to avoid pitfalls/gotchas

Fast intro to common patterns

It’s exhausting


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


ETHICS/VALUES

Political Reasons

Altruism

Democracy/Meritocracy


BUSINESS

Best Solution Available

Makes Sense for the Project

WHY?BUSINESS REASONS

• Security

• Quality

• Customisability

• Freedom

• Flexibility

• Interoperability

• Auditability

• Support Options

• Cost

• Try-Before-You-Buy

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 fix 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

FREEDOMFree as in “Beer”

FREEDOMFree as in “Speech”or as in “Thought”

PROGRESS

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 Artificial Intelligence Labswith the printer drivers in about 1971

[COOKING]

SOFTWARE SHOULD BE ...

Completely PRIVATE

v.

Completely FREE


Completely PRIVATE

v.

Completely FREE

Sell

Share


Completely PRIVATE

v.

Completely FREE


Completely PRIVATE

v.

Completely FREE

(Bill Gates) ..

(Richard Stallman)


Completely PRIVATE

v.

Completely FREE


Completely PRIVATE

v.

Completely FREE

Corporations

Hackers


Completely PRIVATE

v.

Completely FREE

rights individual

higher purposeprogress of technology


Completely PRIVATE

v.

Completely FREE

Protect Owner

Protect Freedom

rights individual

higher purposeprogress of technology


Completely PRIVATE

v.

Completely FREE

These rules hadn’t been made upIn wasn’t obvious


Completely PRIVATE

v.

Completely FREE

Product

Individual

These rules hadn’t been made upIn wasn’t obvious


... THE AUTHOR DECIDES

COPYRIGHT

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.


COPYLEFT

ORIGINAL SOFTWAREFREEDOMS (~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 modified 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.



2. Source Code

3. Derived Works



~ as in beer -- no royalties or fees




2. Source Code

3. Derived Works




~ not obfuscated or require preprocessor, translator, etc




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 Specific to a Product

9. License Must Not Restrict Other Software10. License Must Be Technology-Neutral

Need to be specified 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 exemptfrom being sued.

“This program comes with ABSOLUTELY NO WARRANTY”

lifesavinglanding 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

ACTUALLY LOOKS LIKE THIS:

ACTUALLY LOOKS LIKE THIS:Mailing Lists

ACTUALLY LOOKS LIKE THIS:Mailing Lists IRC

Bug/Issue Tracking

AND THIS ...Bug/Issue Tracking

BUT SRSLY ...

Completely PRIVATE

Product

v.

INDIVIDUALCompletely FREE

community that emphasises the individual over the companyvs. 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 SPECIFICS

PROJECT TECHNICAL SPECS

How: responsive, receptive and welcoming

will vary dramatically

• Technology

PROJECT VARIABLES

Andrew Tridgell says: spend a couple of weekends or whatever

• Technology

PROJECT VARIABLES

• What’s its scope?

• What’s its profile?

• How big is it?

• How old is it?

• Where in its lifecycle it is?

• How active is it?


• Technology

PROJECT VARIABLES

• Who?

• How well organised is it?

• How is it structured?

• How are decisions made?

• How does it communicate?

• What’s its scope?

• What’s its profile?

• How big is it?

• How old is it?

• Where in its lifecycle it is?

• How active is it?


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 profile?

[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 twicedead 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

PROJECT VARIABLES

CATHEDRAL BAZAARv.

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 youall 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 patchit 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.

PROJECTGOVERNANCE

(PEOPLE)

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 structureMost projects are informal

If you have an organisation ... even if it’s rubbish

PROJECT GOVERNANCE

FormalConstitution

Office holders, Board or Steering committeeAnnual election

(Debian; Gnome)

Not-for-profit “Software Foundation”(Apache SF, Python SF, Django SF)

Usually happens when big enough to involve money and lawyers.

Office holders, “official” membershipcommon 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 identifiable author or leader.

Is there an identifiable team?

What roles are there?What roles aren’t there?

ROLES

BDFL

Benevolent Dictator/s For LifeMore commonly used in this era.

Usually original author/s.Though there are exceptions.

Dictates final decisions, arbitrage and ends disputes.

Project leader for so long

ROLES

Release Manager

PackagingPass tests

Right documentationRight internationalisation (i18n)

No “release blocking” bugsRelease 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/proficiently?

101 stuff ... most of are self-taught in most areas, worth glossing over.

START SMALL

A lot of people’s FOSS careersstart with a

one character patch.

(particularly to big, old, established projects)

You don’t have to “prove” your mad-coding-skillzor change the world in your first 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 patchesfrom 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 CONTROLMANAGEMENT (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

DIFF/PATCH

The tiny step is called a: patch

Small, logical, incremental steps.

Official 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: “unified format” (or “unidiff” or “-u”)

$ diff -u ...



DIFF/PATCH

UNIDIFF

wikipedians may be familiar

UNIDIFF

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

DIFF/PATCH

UNIDIFF

DIFF/PATCH

Congratulations! You have a patch file!



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.

... sent* to the project ...

SEND/MERGE/COMMIT/PUSH/PULL-REQUEST

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

... sent* to the project ...



PATCH SUBMISSION:LINUX KERNEL EXAMPLE

Very strong rules.

Very clear guidelines.

https://www.kernel.org/doc/Documentation/SubmittingPatches

5,000 word piece of documentationwhich 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 CODEMANAGEMENT

(SCM)SYSTEMS

WHAT IS SOURCE CODE MANAGEMENT (SCM)?


Where is your MASTER codebase repository?



Early version control system:

CENTRALISED SERVER

CENTRALISED VERSION CONTROL


FIRST GENERATION SCM

+ Provides development history- Manages files individually- Only one person editing at a time- No merge capability

eg, SCCS (1972), RCS (1982 free and more evolved)

rcs 1982

CENTRALISEDVERSION CONTROL

CVS (CONCURRENT VERSIONS SYSTEM)

+ Parallel development+ Merge & conflict 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


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.



Since early 2000s

DISTRIBUTED

Everyone gets a ‘clone’: + entire codebase

+ entire revision history

DISTRIBUTED VERSION CONTROL

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 file tree with the special /.git directory

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

WHAT FILES ARE IN A GIT REPOSITORY?

Explicitly add and rm files to/from repository

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


Explicitly add and rm files to/from repository

Be specific:

$ git add hello.txt

Or general:

$ git add .

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


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 CLONEFind an open source repository.



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


https://github.com/jquery/jquery.git


The the code is yours. All yours.


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




MAKE CHANGESFORK

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 CHANGESBRANCH

Create branch:$ git branch mydevbranch

Use branch:$ git checkout mydevbranch

MAKE CHANGESGENERATE PATCHES

So you’ve changed the code.On your own fork.

On a development branch.

You need patches.

WHAT’S GOING ON IN AGIT REPOSITORY?

$ git status

Will recognise file changes.

Automatically translate to patches/hunks.

WHAT’S GOING ON IN AGIT REPOSITORY?

$ git status

Recommended GUI tools

Linux: gitg

others: SourceTree

git-scm.com/downloads/guis

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(using $ git add or GUI tool)

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”)

“Commit” staged changes


Assume:THERE IS NO UNDO BUTTON

Everything you commit is on the public record. Forever.

Commit with care.

Do NOT be reckless.


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.


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


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.



They usually don’t do this automatically.




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




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: copyDon’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!

.



SAYTHANK 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 :)

AN EXISTING PROJECT

DON’ T ASK ME



How (Not) To Build An OSS Community

* Hello* Enjoying PyCon? Food Coma?* Talk about something near & dear: community

Thanks.Questions?

@daniellindsleyhttps://github.com/toastdriven

github.com/kennethreitzQuestions?

Growing Open Source Seeds

Kenneth Reitz

Running an open source project

ORBE ON YOUR WAY

BE CORDIAL

OPEN SOURCINGA PROJECT

“cookiecutter” projects on github.

Detailed blog posts.

EXISTING PROJECTS

Do you actually want help?

“My Precious”Let others in.

Consider the benefits 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 specific.

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 find out publicly first.

It’s gutting to have something rejected, but there’s usuallya 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 PROJECTSBE 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 batshitIf 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

LICENSESGPL

GNU Public License.

You must keep the software open.

You must give your changes back.

LICENSESGPL 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

LICENSESGPL V3 (2007)

Written to address:● Internationalisation and clarification 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.

LICENSESCOMPATIBILITY

Probably not fun.

~15% of all repositories had license files~25% of those have the license only

mentioned in the Readme file

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.

http://lucumr.pocoo.org/about/

http://lucumr.pocoo.org/about/

LICENSESPOST-GPL

Interesting TimesMost 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 serverZed 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.”

LICENSES

Watch this space.

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”fields you should and shouldn’t fill 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.

Harry Kroto

On feeling stupid:

Everyone does.

Everyone is about most things.

The “best” leverage thisto their advantage

(usually very humble.)

SAYING: I DON’T KNOW

HE ... wasIT’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

tersetəә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 fluffy language, no big explanation.BE CORDIALJust get to the core of it.

https://www.google.com/search?safe=off&q=define+brief&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CC4Q_SowAA

https://www.google.com/search?safe=off&q=define+brief&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CC4Q_SowAA

https://www.google.com/search?safe=off&q=define+short&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CC8Q_SowAA

https://www.google.com/search?safe=off&q=define+short&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CC8Q_SowAA

https://www.google.com/search?safe=off&q=define+concise&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDAQ_SowAA

https://www.google.com/search?safe=off&q=define+concise&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDAQ_SowAA

https://www.google.com/search?safe=off&q=define+succinct&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDEQ_SowAA

https://www.google.com/search?safe=off&q=define+succinct&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDEQ_SowAA

https://www.google.com/search?safe=off&q=define+crisp&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDIQ_SowAA

https://www.google.com/search?safe=off&q=define+crisp&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDIQ_SowAA

https://www.google.com/search?safe=off&q=define+pithy&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDMQ_SowAA

https://www.google.com/search?safe=off&q=define+pithy&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDMQ_SowAA

https://www.google.com/search?safe=off&q=define+incisive&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDQQ_SowAA

https://www.google.com/search?safe=off&q=define+incisive&sa=X&ei=v7REUv_bB4SskAWHjoG4Bg&ved=0CDQQ_SowAA

BEING INVOLVED

Names/code

to

Faces/personalities

TURN UP!

Decisions are made by the people who turn up.

HackerspacesUser GroupsConferences

Congratulations you are already here.Connect and develop.

SET PEOPLE’SEXPECTATIONS

Probably the most valuable thing I’ve learnt in the last 5 years.

CONTRIBUTING

COMMUNICATE

Find the venues to do so.

Mail-listMight be several!

IRCIssue Tracker

Wiki



BEING INVOLVED

Real world is not uni.

Flexible

FOSS is really flexible.

Young projects can turn on a dime for your idea.

Envisioning and implementing all the fine 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.

INTERESTINGTIMES

Stream-lined ability to contribute/communicate.

Culture is changing: tech is becoming mainstream.

Re-learning old lessons.

Not just chicks, it’s older, multicultural.

INTERESTINGTIMES




Demographic imbalance is being addressed.


CHANGINGDEMOGRAPHICS

Difference is a continuum.

Shared culture and technical knowledge.

Skills!


INTERESTINGTIMES




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.

THANK YOU!

Contributors: Be Cordial

• Keep all interactions with a maintainer as respectful as possible.

• They have likely donated a signi!cant 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.

• This could be their !rst ever interaction with an open source project.

• A little bit of kindness goes a long way.

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.

Just Say No

Learn to Say No

• Saying ‘No’ is extremely di!cult.

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

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

But it’s HOW YOU SELL IT ...

Don’t make it complicated.

Open source makes the world a better place.

Focused PurposeMove 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

DocumentationJust 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

CommunicationWill 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* Twitter

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

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

ListenGraciously 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)

Technology

open source open source

open source skill

open source opportunityif

source code

open source social working

open sourcewho

freedom free

software vendor