Code Explorers Guide to the

Open Source Jungle

Getting started with open source, and
quick start guide on developing
software in collaboration.
Anoop Thomas Mathew
This book is for sale at
http://leanpub.com/opensourcebook
This version was published on 2014-05-14
This is a Leanpub book. Leanpub empowers authors and
publishers with the Lean Publishing process. Lean
Publishing is the act of publishing an in-progress ebook
using lightweight tools and many iterations to get reader
feedback, pivot until you have the right book and build
traction once you do.
This work is licensed under a Creative Commons
Attribution-NonCommercial-ShareAlike 3.0 Unported
License
Tweet This Book!
Please help Anoop Thomas Mathew by spreading the
word about this book on Twitter!
The suggested tweet for this book is:
I just bought Code Explorers Guide to the Open Source
Jungle by @atmb4u
The suggested hashtag for this book is #openlearnability.
Find out what other people are saying about the book by
clicking on this link to search for this hashtag on Twitter:
https://twitter.com/search?q=#openlearnability
Contents
Preface i
Chapter Description i
Contents ii
About this book iv
1 In the Beginning 1
1.1 Long Story Short 1
1.2 Advantages of Open Source Software 4
1.3 What is worth Open Sourcing 5
1.4 Getting Started with Open Source 6
2 Knowing by Using 8
2.1 First Interaction 8
2.2 Area of Interest 8
2.3 Different Types of Open Source Software 9
2.4 Anatomy of an Open Source Project 11
3 First Aid Toolkit 13
3.1 Tools in the Toolkit 13
3.2 First glance on Development Process 16
3.3 Frequently used Terminology 17
CONTENTS
4 Collaboration is Communication 19
4.1 Channels of Communication 19
4.2 You are what you write 21
5 Forms of Contribution 26
5.1 Documentation 27
5.2 Bug Reports 27
5.3 Code Review 29
5.4 Feature Requests 29
5.5 Development 29
5.6 Release and Maintenance 30
5.7 Testing 31
5.8 Tutorials, ScreenCasts and Code Snippets 31
5.9 Translations 32
5.10 Design and Artwork 32
6 Running the Show 33
6.1 Ideation 33
6.2 Packaging and Tool-Chains 34
6.3 Managing Community 34
6.4 Version Control 35
6.5 Documentation 36
6.6 Goals and Milestones 36
6.7 Testing; without, you fail. 37
6.8 Quality Assurance 39
6.9 Knowledge Management 39
6.10 Stepping Down 40
6.11 Tips for Creating good open source Software 40
6.12 Version Control and the git Workflow 43
CONTENTS
7 Paying Bills 45
7.1 Business Models 46
7.2 Entrepreneurship and Open Source 46
7.3 Keeping business along with development 47
8 Time Management 49
8.1 Keeping Yourself Motivated 49
8.2 Get a Partner 50
8.3 Not too less, Not too more 50
8.4 Goal Oriented Time Management 50
9 Licenses FAQ 52
9.1 Available License Types 53
9.2 What Kind Of license Should I Choose? 54
9.3 Jurisdiction 59
10 Your Fortune Cookie 68
CONTENTS i
Preface
Oh! Please dont ask me to read a book, and that too, a
book on open source! - I do understand the feeling thats
running through your head right now. Please bear with me,
Ill try to be interesting, and the maximum extent be away
from being boring and being philosophical.
This book is a boiled down version of my experiences
with open source software for past years, as a user, tester,
developer, creator and contributor. Aim is to educate the
readers about what all can be done with open source, and
explore the untapped possibilities existing with it.
I will trying to be generic while going through this
book, without specifying names and projects, since my
aim is to emphasis the processes and principles which
are commonalities for most of the software engineering
projects.
Chapter Description
Each chapter has been designed to be independent of other
chapters, and conveys a single idea throughout the chapter.
If you feel that ideas discussed in the chapter is something
you already know or not relevant to you at the moment,
feel free to skip ahead to the next chapter.
CONTENTS ii
Contents
1. About this book
The motivation behind this book and why you
should read this book.
2. In the Beginning
Serves as a beginners guide to getting started
with open source.
3. Knowing by Using
Discusses about using the open source soft-
ware. How to tackle usual hurdles.
4. First Aid Toolkit
Tools and Concepts to be familiar to begin with
the collaboration with the community.
5. Collaboration is Communication
Teaches you ways of communication in an
open source world, and the common netiquette
to follow.
6. Forms of Contribution
Discusses different forms of contribution, fo-
cuses more on the non-conventional jobs in the
open source projects.
7. Running the Show
How can each of us run an open source project
effectively, without getting into trouble.
8. Magic with Time
Effective time management tips for open source
developers
CONTENTS iii
9. Licenses FAQ
Open Source licensing options and its signifi-
cance.
10. Your Fortune Cookie
Relevance of contribution, and the social effects
of open community.
About this book
Checking each update on facebook, twitter and other social
sharing applications, there was very little time to be aware
of the software development process happening; or at least,
the exposure has been minimal. Used to be very curious
about things; how does a car work, what does a gear do,
why do things work the way they do, and not otherwise. A
lot of questions.
I had the same questions with the computers Im work-
ing on now. But some how, I just couldnt find enough time
to get into the zone. To learn more on how software works.
How the pieces of code, gets shape and form, handles
terabytes of data, data changes shape and becomes all these
images, and transforms itself to videos and web pages!
I was wonder struck!
Wanted to know more about it, but the coziness by the
mainstream operating systems and all the abstractions! I
want to learn about the magic that happens. Im curious.
Welcome to the world of curious people. Welcome to
the world of collaboration. Welcome to open source.
..
Open Source provides a shortcut to learning deep
about technologies buried within the software we use
everyday. It lets you do open heart surgery on a
About this book v
..
software.
Im not here to tell you the difference between open
source and Free Software. Imnot here for the philosophical
preaching. Im not here to evangelize the war of open
source projects on properitory software. Im here to guide
you in learning the internal workings of epic software
and enable you to create and help creating elegant
software projects, built by people across the world,
which will touch billions of lives and change the course
of history.
About the Author
Anoop Thomas Mathew is the Director of R&D, Pro-
foundis Inc., and leads the engineering efforts on products
like Vibe and iTestifyIt. He is a Technology Evangelist,
Designer at Heart, Public Speaker, Python & JavaScript
Hacker. Loves Music, Books and Drawing. He has spoken
at conferences like Fifth Elephant 2012, FOSSMeet 2011,
PyCon 2012, FOSSMeet 2013, DevCon 2013, PyCon 2013 to
name a few. More info: infiniteloop.in
http://profoundis.com/
https://vibeapp.co/
http://itestifyit.com/
http://infiniteloop.in/
1 In the Beginning
The beginnings are always troublesome, if you know what
I mean. Things wont work in your way. Particularly, when
it comes to logical machines, there is only one way to get
it right, and another million way to go wrong.
This is a very interesting stage, like taming the dragon.
Passion and perseverance is the key at this stage. If you
dont have both, this would be the right moment, to take a
step back and turn around.
Adios!

Oh! Wonderful, you chose the adventure, and not to

step back. Believe me. You have taken the first and the most
difficult step in the entire journey. Congratulations!
This is the book you wanted to read a year before!
1.1 Long Story Short
1.1.1 Long Long Ago
Millions of years nature spend in evolution and over the
years, the intellectual capabilities have increased by folds.
The craftsmanship of creating elegant solutions and meth-
ods that had emerged in the animal as well as in the plant
In the Beginning 2
kingdom. Humans, being a part of the animal kingdom, too
have got a flare of these skills.
These skills, keep us on a different platform from that
of our ancestor species. Human beings took a leap ahead of
other species, and over time, built more of this cognitive
skills. It gave us the power to create and control the
world around. To understand the world around us, in the
scales smaller than the smallest and larger than the largest
existed. It enabled us to travel farther and deeper. This
made us rulers of the world.
This power of imagination and creation started in
person. And later on as nomads became settlers. Found
ways to communicate. They communicated these inge-
nious techniques. This lead to a different level of ideation.
They started forming ideas in groups, started creating
communities and build social order.
1.1.2 Industrial Revolution
People were living like that for a very long time. Without
In the turn of 18th century, something magical happened.
Till then, wheels turned with humans or animals. Now,
machines started shifting the gears and the wheels started
turning faster; way too faster than humans could ever do
in the past.
This also allowed him to spend more time designing
and developing rather than working for his basic needs.
This gave him the opportunity to create even bigger and
complex machines, which evolved faster and in just a mere
In the Beginning 3
matter few decades.
1.1.3 Enter Computers
Machines reduced human physical effort. Over time it was
inevitable to have machines which are capable of handling
his cognitive efforts. Machines were built to solve puzzles,
manipulate numbers, store information. Computers were
born.
1.1.4 Corporations and Ingenuity
Humans had the power of collaboration and ideation long
time before. All these advancements in the human society
gave rise to a systemic yet bizarre construct, which enabled
the budding of corporations. Corporations aimed at the
principle of more, rather than on better. This strategic
difference limited the scope of corporations from trying
ingenious ideas and risky ventures.
There are a few exceptions for this. Still, this tend to
be true for the most of the companies by number. But, the
remarkable fact is that, the few of those exception compa-
nies rule the industries. Power of expression to people and
groups bring-in unimaginable value to the institution.
These cabals can yield better solutions for common-
niche problems. Rather than work, these kind of interesting
puzzles will make people more focused and creative and do
wonders.This makes open source the right candidate for the
best way to learn, teach and create software.
In the Beginning 4
1.2 Advantages of Open Source
Software
Open Source Software, philosophically creates a demo-
cratic system for developing software and maintaining
its quality. Developers as well as the users as the co-
developers, contribute into the development process, which
gives it a lot of advantages when compared to a closed
source development framework.
The availability of the source code and the right to
modify it is very important.
The right to redistribute modifications and improve-
ments to the code, and to reuse other open source
code, permits all the advantages due to the modifia-
bility of the software to be shared by large commu-
nities.
The right to use the software in any way. This,
combined with redistribution rights, ensures (if the
software is useful enough), a large population of
users, which helps in turn to build up a market for
support and customization of the software, which
can only attract more and more developers to work
in the project.
There is no one with the power to restrict in a
unilateral way how the software is used, even in a
retroactive way.
There is no single entity on which the future of the
software depends.
In the Beginning 5
No black boxes are possible.
There is always the possibility of forking, or creat-
ing an alternative code base if the current one is in
some way perceived as wrongly managed.
No per-copy fees can be asked for modified versions,
and anyone can use the current code base to start
new projects.
There are fewer conflicting priorities due to market-
ing pressures.
1.3 What is worth Open Sourcing
There is trick suggested by Jeff Atwood called the rule of
three. Quoting him below.
There are TWO rules of three in [software]
reuse:
1. It is three times as difficult to build reusable
components as single use components,
and
1. a reusable component should be tried out
in three different applications before it
will be sufficiently general to accept into
a reuse library.
So, its quite evident that easier something to build, less
valuable its going to be in the open source. Also, if its more
difficult abstracting the application specific components,
the decision to open source has to be rethought.
In the Beginning 6
1.4 Getting Started with Open Source
To be a developer, you must first be a user.
1.4.1 Using Open Software
Its not going to be any different from mainstream software,
and it is certain that, its very likely not going to work the
way you want like other software and on the flipside, you
can make sure that it works the way you want it, provided
you are willing to put in considerable effort towards it. Its
like a double edged sword. Other than this customization
and development opportunity, open source software is as
similar as closed source software.
1.4.2 Getting Help
For the initial comfort, you can always take refuge in
tutorials. Tutorials will give you step by step instructions to
get the software working. Slowly, we move into the official
documentation and later to the references section as we
grow deeper into the intricacies of the software. If you are
particular in getting help from another person, you can try
mailing lists and IRCs discussed later in this book.
In the Beginning 7
1.4.3 Collaboration at Heart
Open source projects thrive only on a single reason, Hu-
manity. Humans are social beings and are more creative
when different ideas are put together. Collaboration cre-
ates more usable, diverse and elegant software than one
developed without a collaborative ideation or a public code
review.
Each chapter ahead would walk along you with the
concepts you must be knowing while working with open
source.
2 Knowing by Using
2.1 First Interaction
First baby step is to getting used to an open source op-
erating system like Linux or FreeBSD. Its not necessity,
but the environment will be more receptive. Ive seen
people pick up and grow faster with open source operating
systems. Credit goes to the bugs they encounter, and to
the successful efforts to fix them and the efforts in vain.
This gives an opportunity to learn a lot about the inner
workings of operating system as well as nitty gritties of
other software components.
2.2 Area of Interest
This directly leads us to the next obvious step, to know
what is your area of interest. Its a little philosophical and
abstract. To think about it, lets take a piece of white paper,
and take into account, each and every possible fields like
kernel development to documentation, from device drivers
to web applications. Consider each of the alternatives, and
rate each of them.
More over, get used with a few open source tools in
that space. Try using the most popular web application
framework for your next web project, or check out the
Knowing by Using 9
latest video player, or use another popular web browser.
You can get a sense of the priorities of the open source
software and where it lacks lustre. If you find you can make
it shine, there is a vacant seat for you.
2.3 Different Types of Open Source
Software
System Software
It is a difficult task to create software for different
devices by the same developer from the same device. This
makes a collaborative effort more viable way to develop
system software. Also, these software are so unique that
one hardware needs only one driver, which should provide
all the required APIs.
Linux and FreeBSD are two popular open source op-
erating system variants, out of many. They do boast of
the number of drivers available for devices. If you are
interested in embedded or base device interfacing, this is
the right place for you to be in. Android on the other hand,
is an even popular mobile operating system based on Linux
kernel.
Libraries
Libraries or Plugins or Modules are another class of
software which are very viable for open sourcing. If you
look at the web market, a lot of Wordpress and Django
Knowing by Using 10
extension libraries or modules are available, as reusable
components. Examples would be a testimonial system, a
commenting system, user accounts and social login etc.
Logic is very simple, keeping the reusable parts of the
project separate so that others, and of course, yourselves,
dont need to repeat the same development cycle over and
over.
More over, libraries are a smart way to maintain quality
of the code, well documented and clearly defined APIs.
This is because, multiple projects are using the same code
and it is the basic necessity to provide consistent APIs and
detailed documentation.
Libraries form a very integral part of Linux subsystem,
and most of the programs we use will be using a ton of
stable libraries. This make it convenient to be maintained
by different maintainers, and still, on an entity, feel like a
single software.
Caution on using Libraries
It should be noted, that libraries even being
a necessary part in the puzzle, usually de-
pendent libraries go missing, unmaintained or
change their APIs all together without notice,
and can bring in catastophy. Be aware of this
weird yet plausible situation, and make your
choices wisely. Look for libraries which are
actively developed, widely tested and have
very good following
Knowing by Using 11
Utility Applications
The most familiar class of open source applications
fall into this space, like Firefox, GIMP or LibreOffice or
VLC. These programs helps us to use the devices more
effectively.
Being a regular user of open source operating system,
in course of time introduces you to a ton of utility appli-
cations. Development in utility applications is a polarized
one, one end of expert and competent developers and the
other end with a large number of non-technical users, who
provide feedback and feature requests.
Frameworks
Software often requires a scaffolding or a blueprint
to start with, which includes a lot of commonly used
functions for a number of different purpose, but will be in
a templated manner. Say, for example lets take Django, a
web application framework. Every web application needs
some kind of a request and response handling sequence,
and Django has created a framework to handle such fre-
quently used functions.
2.4 Anatomy of an Open Source
Project
Any open source project is modelled on a few undocu-
mented, unwritten principles. These rules are evolving over
time from the initial days.
Knowing by Using 12
1. Every project would have a central person (Benevo-
lent Dictator For Life - BDFL) or a committee to plans
and decide on the general course of the software.
2. There will be a source code downloading facility, ei-
ther an ftp, http and/or a version controlled interface
to do so.
3. There will be a README / INSTALL file to explain
the installation of the program from the source,
supported platforms etc.
4. Dependencies - open source relies on a network of
other open source projects, and are called depen-
dencies. You must satisfy the minimum required
dependencies to be able to run an open source code.
5. Documentation/Installation - explains the installa-
tion process and how to use the software effectively.
3 First Aid Toolkit
This chapter discusses most common practices (and tools)
for developing open source applications.
3.1 Tools in the Toolkit
3.1.1 Development Tools
Integrated Development Environment (IDE) like Eclipse or
Netbeans helps you to do the entire development workflow
within a single software. Or it can be code editors like vim,
emacs or sublimetext which gives you extra functionality
over basic text editors.
In contrast, IDEs abstracts a lot of processes including
the tool chain and build process. For a beginner, this ab-
straction raises a number of alarming confusions. Ideally,
they should start with basic command line and text editor
before moving into fully fledged code editing environ-
ments.
3.1.2 Build Tools
Often collectively called as the tool chain, these are the
build components in the open source development process.
These tools may be compilers or interpreters like gcc or
First Aid Toolkit 14
python. It can be tools like make, scons or cmake, highly
depended on which area you are working on and what are
you trying to achieve. General rule of thumb is to first work
with a project already in the domain, and follow the tools
used, after identifying its advantages and traits.
3.1.3 Version Control
As we are into the business of software which will be
handled by hundreds and thousands of persons everyday,
we need to have a log, as well as a system to keep track
of who is changing what. A number of tools are available.
Among them, git is the one which stands out. Initiated by
Linus Torvalds, creator of Linux kernel, git allows teams to
handle code completely decentralized, offline and efficient.
github.com
While Im writing this book in 2014,
github.com, bitbucket.org etc, are few
popular amongst other code hosting
platforms available for open source
programmers, built around version control
software such as git and mercurial.
3.1.4 Bug Tracker
There are tons of project tracking services, including, but
not limited to github, trac, mantis, jira etc.
First Aid Toolkit 15
3.1.5 Testing
Tools may differ from project to project. But a test runner
has to be integrated with the build process to ensure code
quality. Passing a test suite before committing into the
repository is a great way to prevent breaking code from
entering the system on the first place. Also, each and every
newfeature, should accompany tests to make sure that they
are working as they are intended to be.
First Aid Toolkit 16
3.2 First glance on Development
Process
Open Source Development Process
First Aid Toolkit 17
3.2.1 Documentation and Wiki
Look for Getting Started
Getting Started section usually focuses on the
first time users and would be relatively less
project specific.
Documentation and Wiki pages is usually made avail-
able within/along with the project website. There might be
downloadable User Manual as well. Wikis usually covers
tutorials and general help, while documentation covers in-
depth, systematic information about each of the compo-
nent. README or INSTALL files also come handy very
often.
3.3 Frequently used Terminology
Repository The location where code resides. It is
usually a version controlled online location. A com-
pressed source download method is also found.
Fork Creating a new copy of an existing project and
working on it as an independent contributor. Forks
can be merged back to the original project, provided
the owner is interested and willing to accommodate
the new changes in the fork.
Patch A file which contains the changes made by a
specific person. It contains a diff of old version of
First Aid Toolkit 18
the code to the new one with changes. Any other
developer with the same repository can include this
patch to reproduce the same software that was de-
signed by the patch creator. Widely used when the
user who creates the patch doesnt have write access
to the central repository.
Commit Process of adding a changeset to a version
controlled repository. Commit logs the changes, user
info and the time. Commits can be rolled back to re-
trieve older versions and navigate through different
versions of the same software
Branching To create an isolated version of the same
code, so that new code experiments could be carried
out without affecting the live copy of the code. Any-
thing happens on a branch, stays on that branch.
Maintainer A person responsible for a particular
project or a file in a project. He will be including new
changes to it.
Pull Request A request made by the contributor
to the maintainer to include the changes done by
him/her on his/her branch/fork to the primary repos-
itory to be added upstream.
4 Collaboration is
Communication
As we discussed earlier, open source is all about commu-
nity, and while collaborating in a community, first and
foremost thing to be kept in mind is, everyone elses time
is as valuable as yours. So try avoiding confusions as
much as possible as it leads to waste of time, of the entire
community.
4.1 Channels of Communication
In software, collaboration happen mostly
online, through IRC/IM chats, mailing list
emails, forums, wiki pages and documenta-
tion.
4.1.1 IRC
IRC or Internet Relay Chat is an Instant Messaging plat-
form over which most of the popular open source com-
munity have a channel. This is where general discussions
Collaboration is Communication 20
as well as weekly meetings are conducted. Its no different
from an IM, but people tend to respond a bit delayed.
There are popular clients while allows users to connect
to corresponding channels on appropriate servers. One of
the most common IRC server provider is freenode.net.
They have got an browser version of IRC client.
4.1.2 Mailing List
A mailing list is a group e-mailing facility, where open
source developers and users discuss over development and
on bugs or usage support.
All the news regarding the new releases as well as new
committers, weekly/monthly meeting minutes would be
available in the mailing list logs. This is helpful in learning
the history of the project for a budding developer.
4.1.3 Documentation
Primary source for any information regarding the project.
Is a necessary part of any open source project. It will have
detailed explanation regarding installation and usage of the
software. Extension and also the developer guide for de-
velopers who intent to contribute to the project. Usually a
reference section is also included with the documentation.
4.1.4 Tutorials and HOWTOs
These are blog posts or similar documents, explaining to
a newbie, how to get on track with the software. They
Collaboration is Communication 21
should be light on language and technology. Steps must
be as simple and minimalistic as possible. Screencasts also
works great as beginner tutorials.
4.1.5 Website
Homepage and front facing page for the project. Needs
to express the what, why and how explicitly. All links to
the source code, bug tracker, mailing list, documentation,
tutorials etc, must be provided in the website.
4.2 You are what you write
The mostly used medium is what you write, and that makes
it very clear that you should be good enough in written
communication to be heard. Some well established written
communication netiquette are explained below.
Be concise. Get to the point. Many of the members
on the lists are hard at work coding for one company
or another. Some of those coders take breaks to check
these lists to see whats going on and how they can
help. They dont have time to read through your life
long journey.
Be specific. Before you post your problem make sure
you have collected the relevant data. If you have
a video problem make sure you know the video
card you are using, the driver you have installed,
the version of the kernel you are using, and which
Collaboration is Communication 22
release of the distribution you use. The more relevant
information you give the more likely you will get
help.
No Flame wars - Which one is better is a very person
to person question, and trying to win someone who
doesnt agree with your ideaologies are very likely
waste of time. Its better to explain project ideologies
in a wiki, and avoid unproductive discussions.
Be Constructive
Man 1: You know what, I use Software X.
Its much faster and stable than other distri-
butions Man 2: Do you have this Q feature?
This Software M got the that. You must check
it out Man 1: No ways. Im sure Software X
is the best. It has got W feature. Man 2: M
has got R, S and T features, do you have any
idea? (and a lot of further waste of time.)
Do NOT top post. What is top posting? Top posting is
replying to an e-mail where your reply sits neatly at
the top of the reply email. Instead, either reply at the
bottom of the e-mail or in line. The main reason for
this is so people can followthe thread of conversation
that has taken place. Even though this may sound
trivial it is taken very seriously in Linux and open
source mailing lists. You will be ignored if you top
post constantly.
Collaboration is Communication 23
Do not insult peoples grammar. Yes, there are gram-
mar police all over the place. But the one thing
you must remember is that many of these lists are
populated by people who use English as a second
language. So mocking someone who may wind up
saving your skivvies some day is not the best way to
make friends.
Do not post off topic. This is another issue that
resides just under top posting for most annoying to
avid mailing list denizens. Keep your posts on topic.
Of course there will be the occasional off topic post
you will need to get out. For those instances make
sure you start the subject with OT:
Do not hijack threads. If a thread spawns a new topic
for you, post that new topic in your own thread.
Never steal someone elses thread from them.
Emoticons do not sweep away an insult. You can not
reply, But didnt you see my ;-) indicating I was jk?
OMG! WTF? You see where this leads?
Some developers, when faced with fixing, or adding a
feature to an open source project are under the mistaken
impression that the first step before any fixing takes place,
or before adding a new feature takes place is to make the
code easier for them to work on.
Easier for them usually is a combination of renaming
methods, fields, properties, locals; Refactoring of methods,
classes; Gratuitous split of code in different files, or merg-
ing of code into a single file; Reorganization by alphabetical
Collaboration is Communication 24
order, or functional order, or grouping functions closer
to each other, or having helper methods first, or helper
methods last. Changing indentation, aligning variables, or
parameters or dozen other smaller changes.
This is not how you contribute to an open source
project.
When you contribute fixes or new features to an open
source project you should use the existing coding style,
the existing coding patterns and stick by the active main-
tainers choice for his code organization.
The maintainer is in for the long-haul, and has been
working on this code for longer than you have. Chances
are, he will keep doing this even after you have long moved
into your next project.
Sending a maintainer a patch, or a pull request that con-
sists of your fix mixed with a dozen renames, refactoring
changes, variable renames, method renames, file splitting,
layout changing code is not really a contribution, it is home
work.
The maintainer now has to look at your mess of a patch
and extract the actual improvement, wasting precious time
that could have gone to something else. This sometimes
negates the effort of your contribution.
If you really have an urge to refactor the code, first
of all, discuss the changes with the maintainer with the
rationale for the changes. If the maintainer agrees with
the changes, make sure that you keep your refactoring and
changes independent from code fixes, it makes reviewing
the code a lot simpler.
Collaboration is Communication 25
The alternative, to keep your fork, is usually a guaran-
tee that your effort will be wasted, and wont help other
users. People have tried to do this. It is attempted every
year, by hunders of developers who in tbe back of their
minds are thinking I can do better and I wont make the
same mistakes.
So respect the original coding style, and if you want to
make refactoring changes, discuss this with the maintainer.
5 Forms of Contribution
First shot code contribu-
tors are very few.
An often held misconception is open source
is all about developers. The fact remains,
more than 80% of the community comprises
of technical writers, reviewers, bug reporters,
maintainers and translators.
Being a developer is not the only thing you can do for
open source. A code coughing machine doesnt make
a good developer either. It needs understanding of the
human-computer interaction mechanism, stickiness to the
process, persistence, and above all a well formed social
outlook.
Other tasks such as translation or testing would be
insightful for a new developer to get accustomed with the
community as well as the code base.
Contrary to the normal belief, a ton of ways are avail-
able contributing to open source other than development.
Most common job descriptions available with open source
projects are listed below.
Documentation
Forms of Contribution 27
Bug Reports
Code Review
Feature Requests
Development
Release and Maintenance
Testing
Tutorials, ScreenCasts and Code Snippets
Translations
Design and Artwork
5.1 Documentation
Documentation is the process of letting users and devel-
opers know what does your code do, and how to use it
in the right way. Usually done by the author himself, but
there are cases where English is not authors first language,
and needs someone else to work with him to make the
documentation effective. Rephrasing documentation to be
more simpler and accessible is another interesting task
within documentation.
Documentation should ideally contain an Installation
section, Getting Started, detailed functionality of each and
every utilities available and extensive API reference guide.
5.2 Bug Reports
Anything non-trivial program has bugs -
anonymous developer.
Forms of Contribution 28
A great way to contribute to the community. Many
bugs are platform specific and users on that platform can
only
Not at all difficult as you
may think!
Go to the project page, search for
bugs/issues/tickets
Usually its a bugzilla bug tracker or
github issues or any other ticket man-
aging system.
Create an account, and find create a
bug report button.
Go ahead and create a bug report, u
will need a title for the bug and a
short description of what you expe-
rienced. Additional information like a
screenshot of the bug, environment de-
tails, severity of the bug and whomyou
think would be the right guy to look
at it are optional details you can add
along with a bug report.
Forms of Contribution 29
5.3 Code Review
A time consuming, yet interesting way to learn and enter
into the development of the software is to review others
contribution. Its one among the easiest ways to get more
context about the repository, and getting into the developer
circle in the project.
5.4 Feature Requests
Avid users of the concerned software knows the Achilles
Heel of it better than a seasoned developer. They would
know which new feature would make more sense and what
bugs to fixed in priority. These people care raise feature
requests and ask core developers to create those features.
Many a time, these kind of feature requests and discus-
sions over them, decide the course of the project, leading it
to a much better position and acquiring larger userbase.
5.5 Development
Developing in a real world open source project contributes
to a very tiny portion of the time. Time is mostly spend on
designing and discussing other plausible solutions for the
problem or a more efficient way to implement the existing
solution.
Once the solution is confirmed, its programmed in the
corresponding programming language, tests are written
Forms of Contribution 30
and using the tool chain, compiled/interpreted to create the
desired output. Always make sure that the code committed
to the repository are bug free and end-to-end tested. There
are not many things more embarrassing for a programmer
than having an explicit bug on the public code committed.
It is well advised to include the documentation for
the newly added code together with the same commit. To
document line by line is an excellent practice to ensure that
other developers will be able to decypher what each lines
mean.
5.6 Release and Maintenance
Packaging the software for the easy consumption and
upgradable should be of top priority. Users working with
archaic versions of software bundled with the deployment
will have to compile the code from the source to use the
latest version.
Every package will have a maintainer, who keeps track
of new features included, version and packages to different
platforms the software has to be distributed. Most of the
packages in the open source has the potential to be dis-
tributed across all platforms including UNIX distributions,
like Linux, FreeBSD and Mac OS as well as Windows
environments.
Forms of Contribution 31
5.7 Testing
The Linux kernel development works in a very peculiar
way. You can write some code, make sure that all tests
passes on your machine. You can contribute a patch. And
if the code is valuable, it will be pushed upstream.
Now, youd think what if that code is not working
on platforms other than that of yours. Exactly! Linux
kernel has the most number of platform supported and
it is achieved by multiple people from multiple bizarre
platforms test report bugs and get it fixed. Considering
these facts, we must understand the significance of writing
tests, and running tests in the development process.
Benchmarking the project in comparison with other
available projects in the similar field would provide valu-
able insights regarding where the project stand compared
to its peers.
5.8 Tutorials, ScreenCasts and Code
Snippets
If you are good at technical writing, communication, this
task is for you. Writing blog posts, HOW TOs, enriching
documentation, creating Getting Started video tutorials
and sample code snippets fall into this category. To grow
the community, the most important task is to making the
getting started part the easiest.
Forms of Contribution 32
5.9 Translations
Translating open source projects to native languages had
been one of the primary task any developer can easily
get started with. This has got two significant advantages;
contribution process is relatively easy, and can instantly
connect with the softwares local community.
5.10 Design and Artwork
At the end, it should look great. It had been the case of
open source software till the mid 2000s, very numb looks.
Even now, artistic skills of programmers are in question.
This creates a separate group of people who can think in
an artistic sense and design websites, posters, logos, and
documents for the open source projects.
A presentable open source project is always preferred
to a dull looking project; even if the software is designed
elegantly.
6 Running the Show
Starting to play around with a community is interesting,
but more than a interesting game as soon as the project gets
popular. It needs careful nurturing at each stage to keep
the project alive and on schedule. Some ideas on how an
entire open source project lifecycle works is discussed in
this stage.
6.1 Ideation
Everything starts with ideation stage. To get an idea is easy,
but to validate whether it is interesting to others as well
is a very difficult process. This is not a necessary thing
in open source, while something being in the open source
domain, is supposedly used by a lot of people and others
contribute in the general development workflow discussed
in the previous chapter.
Ross Gardler, former Manager of OSS Watch, believes
that the scope of an open source project can be formalised
by looking at a number of key attributes that characterise
an open development community, namely:
a deep level of user engagement: if you dont have
users then there is no point having a project.
Running the Show 34
collaboration: a means of working within a diverse
group of people, something that the Internet has
obviously made easier.
agility: once work begins and there is a serious
engagement with users, ideas and plans may need
to change.
sustainability: having the capacity to keep develop-
ing an application solution over the necessary period
of time.
tools: wikis, bug and version-trackers and email lists
to support the development of the community and
keep track of intellectual property rights, if relevant.
6.2 Packaging and Tool-Chains
Development activity on open source projects is constant
and concurrent among many developers. Sometimes the
changes made by one developer interfere with those made
by another developer. Often the version control practices
used in the open source community resolve these conflicts,
but sometimes they do not. Frequent automated builds and
tests of the software being developed are powerful tools
that help catch logical conflicts early.
6.3 Managing Community
Software developers spend a large part of their time com-
municating with each other. Clear and effective technical
Running the Show 35
communications are needed to keep the team in sync and
to allow individuals with key knowledge to apply that
knowledge where it is needed.
One tenet of the open source community is that tech-
nical communications should take place in public forums.
Mailing lists are the backbone of open source communica-
tions. Beyond that, open source projects need support for
precisely communicating technical details and for group
decision-making.
There can be weekly/monthly/yearly meetup (online/of-
fline) for the developers in order to discuss the progress
and also, future plans. Every task should be assigned to
someone in the community, so that everyone is responsible
for some part or the other.
6.4 Version Control
Every software development project needs version control.
This is very important to keep track of the history as well
as maintaining integrity while multiple person are working
on the same code from different geographical locations
at the same time. Open source projects need strong and
flexible support for many concurrent developers working
on overlapping sets of files.
Running the Show 36
6.5 Documentation
Document Every Line
It might sound absurd, but in a few weeks,
even the code written by you will look like
gibberish.
Let others know whats in your head. Open source
projects also need standard templates for design docu-
ments, technical documentation, and end user documenta-
tion. A well-organized project should facilitate distributing
these documents. But, the nature of open source projects
demands that these files are globally accessible, and that
administrative overhead be minimized and responsibility
be spread out over the members of the development com-
munity. A central wiki could serve as an ideal candidate
for collating all such documentation, tutorials, and guides.
6.6 Goals and Milestones
Every project needs explicit goals, resources, and a sched-
ule. The open source community has addressed these issues
in a uniquely flexible way. Shared to do lists keep track
of tasks that need to be done. Personal to do lists keep
developers on track. Milestone lists set flexible deadlines
for individual features based on feedback from users and
developers.
Running the Show 37
6.7 Testing; without, you fail.
Its like doing the first flight with a 1000 souls on board.
The chances of going under is very high, and without
any previous consideration, you are stepping into disaster.
Enter Testing.
Testing is an integral part of the development, and
ideally, open source projects, which is being developed
from different locations all over the globe, should have a
code coverage of 100%. Meaning, each line of code should
be accompanied by a test.
Wait! what is testing by the
way?
Lets consider a case here. Person A and Person
B is working on the same project. Person A is
working on feature 1 and person B on feature
2. Person A finished feature 1 and moves on to
feature 3. In the mean time, Person B finishes
feature 2, and tries to include his changes.
Problem here is Person Bs feature 2 is break-
ing Person As feature 1.
What can we do about it? Before Person B
includes his new set of changes, he runs the
test suite, which contains testing cases for the
features Person A has added. Now that there
exists tests, its easier for Person B to identify
Running the Show 38
that feature 2 is breaking the code, he can make
changes so that feature 1 is also intact.
Even if all testing practices are prominent and popular
in the open source world, Id recommend unit test or
module testing as a mandatory. This ensures that each
module is working perfectly. One thing to be remembered
while attempting to write a test is to make sure you are
focusing on the things that are likely to break, and are
depended on external factors, like a global variable, or a
user input. A good test would consist of all possible cases
that will completely cover all the features.
Write test for the feature
you add
It is ideal, recommended, and in some com-
munities mandatory for each of the feature
addition to be accompanied with comprehen-
sive test cases.
Software engineering practices are key to any large
development project. This site provides a home to conduct
open source or collaborative software projects integrated
with a set of hosted development tools to facilitate project
teams adopting the best practices that have proven them-
selves in the open source community.
Running the Show 39
6.8 Quality Assurance
Open source software products have achieved a remarkable
degree of quality. This is something that the closed source
development world has found to be one of the most difficult
and costly aspects of software development.
Developers are self-selected by their interest and knowl-
edge of the application domain. Requirements are tacitly
understood by developers who are themselves users of
the software. Technical communications (including bug
reports) are conducted in public. The public nature of open
source helps developers take pride in their successes and
think twice before releasing faulty code.
Furthermore, debugging is much more effective when
split among many people who have diverse knowledge
and accessbility. For example, one person might have a
non-UNIX machine. He may not know anything about
programming or development, but he can make sure that
the software which he uses is working exactly as intended
and report bugs, if any.
6.9 Knowledge Management
Knowledge is the valuable resource that sets experienced
developers apart from novice ones. Sharing knowledge
effectively has been key to the success of the open source
community. Explicitly managing knowledge can help re-
duce the learning curve for novices which reduces the bar-
Running the Show 40
riers to entry for potential contributors while automatically
keeping the load on the experts down to a minimum in
terms of training others.
6.10 Stepping Down
Over time, either the core members priorities might have
changed or better and more competent contributors joins
the team, the core members should realize the fact, and
step down. This is not an option; this is a necessity. A
necessity to avoid making the project an abandonware.
6.11 Tips for Creating good open
source Software
Eric S. Raymond in his book The Cathedral and the
Bazaar points to 19 lessons learned from various software
development efforts, each describing attributes associated
with good practice in open source software development as
follows:
1. Every good work of software starts by scratching a
developers personal itch.
2. Good programmers know what to write. Great ones
know what to rewrite (and reuse).
3. Plan to throw one [version] away; you will, anyhow.
(Copied from Frederick Brooks The Mythical Man
Month)
Running the Show 41
4. If you have the right attitude, interesting problems
will find you.
5. When you lose interest in a program, your last duty
to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-
hassle route to rapid code improvement and effective
debugging.
7. Release early. Release often. And listen to your cus-
tomers.
8. Given a large enough beta-tester and co-developer
base, almost every problem will be characterized
quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot
better than the other way around.
10. If you treat your beta-testers as if theyre your most
valuable resource, they will respond by becoming
your most valuable resource.
11. The next best thing to having good ideas is recogniz-
ing good ideas from your users. Sometimes the latter
is better.
12. Often, the most striking and innovative solutions
come fromrealizing that your concept of the problem
was wrong.
13. Perfection (in design) is achieved not when there
is nothing more to add, but rather when there is
nothing more to take away. (Attributed to Antoine
de Saint-Exupry)
Running the Show 42
14. Any tool should be useful in the expected way,
but a truly great tool lends itself to uses you never
expected.
15. When writing gateway software of any kind, take
pains to disturb the data stream as little as possible
and never throw away information unless the recip-
ient forces you to!
16. When your language is nowhere near Turing-complete,
syntactic sugar can be your friend.
17. A security system is only as secure as its secret.
Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a
problem that is interesting to you.
19. Provided the development coordinator has a com-
munications medium at least as good as the Internet,
and knows how to lead without coercion, many
heads are inevitably better than one.
Running the Show 43
6.12 Version Control and the git
Workflow
Git Branching Workflow
Running the Show 44
As shown in the picture, a branched workflow needs to
be devised with a distributed version control software,
ensuring a conflict-free software development process, also
maintaining the backward compatibility and strictly fol-
lowing agile development model.
7 Paying Bills
The main issue with open source and free software is that,
it sounds like is a cheap and low cost affair. The fact
is, its NOT. RedHat Inc., an open source based company
is valued at $1.4 billion. This definitely proves that open
source software do have business potential.
At the end of the day, you need to make sure that all
your bills are paid, Even if you are a full time open source
contributor, you need to make sure that. There are gov-
ernment and university grands, fellowships, donations and
other monetary support mechanism for open source soft-
ware, building a business around the open source ecosys-
tem proves to be the most appealing one to be on the sweet
spot,
Working on what you love to do
Contribute back to the society
Make enough money to pay your bills
Let us discuss some business models possible together
with open sourcing the code which does the magic.
Paying Bills 46
7.1 Business Models
Open source on itself is NOTa business model. It is a collab-
orative software development practice. Provided that, open
source do have viable as well as proven business models
built around it over time. We can classify them broadly into
4 categories
Building products on top of open source
Eg: Facebook, Twitter
Delivering services for open source
Eg: wordpress
Selling support for open source
Eg: redhat, mysql, mongodb
Provide consulting for open source
Eg: tons of them
7.2 Entrepreneurship and Open
Source
There are some striking similarities between entrepreneurs
who move ahead and start their own businesses and the
Paying Bills 47
ones who initiate open source projects. Both of them senses
the need for such a piece of missing jigsaw. Both parties are
not in the game just for monetary benefits and enjoys doing
what they do.
Open source software provides a easily accessible plat-
form for the entrepreneurs to head start ahead of the
proprietary software.
A software entrepreneur must consider the possibility
utilizing and contributing to the open source community
as a whole. Consider open sourcing internal tools or con-
tributing the repositories you use very often.
Give enough freedom to the employees to doodle with
interesting projects and encourage contributions. Google
has did this very effectively by giving 20% of the work
time to do what ever they wish to do. It is proven that
these company independent hacking will lead to creative
products and more exciting business opportunities.
7.3 Keeping business along with
development
This is a hard task to do, when you are running a company.
Your preferences changes time to time in a company, and to
keep on developing a particular project needs dedication.
There is always a great way to induct new and budding
developers and making them maintainers for the project.
There are tons of projects unmaintained due to the shift
in the company strategy. Those projects would benefit from
Paying Bills 48
interested people who can contribute and direct the project
to a successful destination.
8 Time Management
Goals and Milestones
Open Source projects, as like other software
projects, require careful planning and well set
goals and milestones.
8.1 Keeping Yourself Motivated
Motivation comes with an expiry date. This makes it nec-
essary for you to keep on inspiring yourselves, by setting
weekly goals, and quick sprints.
One option is to spend an hour a day on it after work.
Progress is slow. But slow but steady is better than nothing.
Planning on how you can make small tasks helps find the
motivation. Its less overwhelming to create a form with
one element than a whole app.
Other options are to work on it during your commute
(if you take mass transit) or during your lunch break.
Time Management 50
8.2 Get a Partner
If you can partner up with someone, it makes the project a
lot easier and more enjoyable (if you find the right person).
See if there is someone at work, or a friend, or even an
online contact who might want to work with you on the
things youre doing.
Partner need not necessarily local, but someone in the
online community can act as a partner. Meanwhile do not
mistake a partner with a mentor. Its completely different
concepts.
8.3 Not too less, Not too more
Make sure that the project is not eating away most of your
time. Or, its not getting enough attention, as it requires.
Just focusing on only one project at a time, escpecially if it
is not a paying and primary job, it is a matter of concern.
So, the ideal way is to have atleast commit every day. This
is a principle which have returned great results, as you can
contribute some of your time everyday, but not too much
to bite of your key focus. Believe me, one commit a day is
not a hard goal to achieve.
8.4 Goal Oriented Time Management
Create goals for every week, which keeps you on the clock
all the time, and keep it more organized. This is really
Time Management 51
interesting if you are working on a long running project.
Please dont try to bite it all once; it will not work. Create
small, easily achievable milestones, which would inturn
motivate you on further progress.
John Bytheway Inch by inch, lifes a cinch. Yard by
yard, lifes hard.
9 Licenses FAQ
Every single line of code written by a pro-
grammer is copyrighted by default.
Yes! If any one wants to share the code with anyone
else, he has to explicitly mention the license agreement.
And this gave rise to all the GPL and BSD and other
licenses.
Licenses FAQ 53
9.1 Available License Types
Comparison of popular Software Licenses
There is an interesting perspective in haaked.com on dif-
ferent types of software licenses.
According to it, there are only 4 types software licenses
available
1. Proprietary - The code is mine! You cant look at it.
You cant reverse engineer it. Mine Mine Mine!
2. GPL - You can do whatever you want with the code,
but if you distribute the code or binaries, you must
make your changes open via the GPL license.
Licenses FAQ 54
3. New BSD - Use at your own risk. Do whatever the
hell you want with the code, just keep the license
intact, credit me, and never sue me if the software
blows your foot off. The MIT license is a notable
alternative to the New BSD and is very very similar.
4. Public Domain - Do whatever you want with the
code. Period. No need to mention me ever again. You
can forget I ever existed.
9.2 What Kind Of license Should I
Choose?
This section is based on an article by Rowan Wilson, which
you can read online at http://oss-watch.ac.uk/resources/licdiff.
There are many free and open source software licenses,
and while they all broadly attempt to facilitate the same
things, they also have some differences. Some of the major
differences can be grouped together into categories, and
this document acts as an introduction to these categories.
Having read this document, you should be able to under-
stand which decisions you should take in order to select a
license for your code.
9.2.1 Staying Mainstream
The Open Source Initiative - a non-profit organisation
formed to educate about open source - maintains a list of
licenses that they see as being popular and widely used
Licenses FAQ 55
or with strong communities. The purpose of the list is
to highlight those licenses which are likely to answer the
needs of many licenses new to open source. The list also
helps to make the task of open source license selection seem
manageable; the full list of more than 60 licenses can be
daunting, and contains many licenses which are in most
ways similar in function to one or more of the popular
and widely used listed licenses.
Using a license that many others use has some advan-
tages. If the terms of the license are challenged, there will
be a larger pool of licensees with an interest in funding a
response to the challenge. Using one of the popular and
widely used licenses also makes it more likely that your
licensees will already be familiar with the terms you are
offering. Equally though, licensees should not feel locked
in to only using a popular and widely used license. Some
of the features we discuss below are only present in the
wider pool of all OSI-approved licenses.
9.2.2 Permissive And Copyleft
All free and open source licenses allow others to make
modified versions of your code, and to make these modified
versions available to others. The license you choose can
make conditions about how this happens - specifically
what licenses can be used on these modified versions.
These conditions can help keep your code free, but they can
also put some people off reusing your code. Such conditions
are sometimes called copyleft conditions, in a play on the
Licenses FAQ 56
word copyright.
Open source licenses that do not seek to control how
modified code is licensed are often referred to as per-
missive licenses. While the original code covered by a
permissive license stays under that permissive license, any
modifications to it can be released under any license that
the modifier chooses, open source or not. This means that
permissively licensed code can form the basis of closed
source products. Some argue that this makes permissive
licenses more free than copyleft licenses, in that people
who modify the code are freer to choose what they do
with it. Others argue that the lack of a requirement that
modifications be open source means that permissive li-
censes are less free. As discussions of ideas of freedom
- and particularly the idea of compulsion to be free -
are essentially philosophical they fall outside the scope
of this document. It is worth noting, however, that there
are differing views within the free and open source world
about what free in the sense of freedom really means.
..
Example
As part of her astrophysics research Anne creates a
standard for recording a specific kind of complex data
object. She also writes code to create and parse files
that adhere to the standard. Anne is keen that the
standard becomes widely used, as minority standards
are far less useful. Therefore she decides that she will
Licenses FAQ 57
..
release the code under a permissive license. Anne
believes that by allowing creators of both closed and
open source projects to use the same code to create
and read the data objects, uptake and efficacy of the
standard will both be helped along.
9.2.3 Strong And Weak Copyleft
Should you choose to include copyleft licensing conditions
on reuse of your code, there is a further choice to be made.
Copyleft licenses are broadly divided into two strengths:
strong and weak. Strong copyleft conditions dictate that
when a piece of software contains some of your code, the
software as a whole must be distributed under your license,
if it is distributed at all. The effect of this will be that
the source code to all additions made to the code will be
available.
Weak copyleft, on the other hand, means that when
software contains some of your code, some parts of the
software must be distributed under your license, if the
software is distributed at all. Other parts may be distributed
under other licenses, even though they form part of a work
which is - as a whole - a modified version of your code. One
effect of this will be that the source code to some additions
made by others to your software may not be available
as open source. Another effect may be that people may
find it easier to productise your code by adding closed
Licenses FAQ 58
components and selling licenses to these closed parts.
To choose a specific weak copyleft license, you must
also decide precisely which parts of your code will retain
your license and what kinds of additions can bear a license
of the modifiers choosing. This division can happen at one
of three levels:
Module level weak copyleft licenses dictate that each
functional sub-section (module) of code within the
software is considered separately. Where a module
contains some of your code, it must bear your license.
Where it does not, the owner of that code gets to
choose their own license for that module.
File level weak copyleft licenses dictate that each col-
lection of code and data that is distinct according to
the computers file system is considered separately.
Where a file contains some of your code, it must bear
your license. Where it does not, the owner of that
code gets to choose their own license.
Library interface level weak copyleft licenses are
generally used where your code is a software li-
brary (a collection of software functionality which
is usable by other programs via an agreed interface).
Modifications of your library must bear your license,
if they are distributed. Programs that use your li-
brary, and are perhaps distributed alongside it, need
not use your license.
Licenses FAQ 59
..
Example
Barry writes a piece of C code that examines websites
over a network connection and generates image file
diagrams of the links between their pages. Barry
wants to release his code under a copyleft license
because he wants to mandate access to the source code
of all modifications of his program that are released.
However, Barry also wants a wide variety of projects
to be able to use his program - partly because he
believes this will encourage the useful modifications
and optimisations of his work that he wants to see.
Barry decides to package his program as a library and
use the library interface level weak copyleft license
the GNU LGPLv2.1 on it, as it seems to him that
this represents a good balance between encouraging
reuse by both closed and open source projects while
mandating the release of source of modifications to
the parts he is interested in - his own code and the
functionality it embodies.
9.3 Jurisdiction
A jurisdiction refers to a specific location or territory and
its system of law. Where a license specifies a jurisdiction,
the licensor and the licensee(s) agree that the terms in the
Licenses FAQ 60
license are to be understood in reference to that jurisdic-
tions law and that legal action resulting - for example -
from breach of the licenses terms will take place in that
jurisdiction.
While jurisdiction is an important issue, it may be
worth noting that traditionally free and open source soft-
ware owners do not tend to seek monetary damages from
those who infringe their licensing terms, but seek instead
to compel the infringer to either abide by the terms or
terminate their use of the code in question. For these
purposes it is often unnecessary to resort to actually taking
an infringer to court, particularly if they have a public
profile and reputation to protect. Often simply requesting
compliance can be effective, and if that fails, publicising the
infringement can help achieve compliance. Not all free and
open source software licenses specify a jurisdiction. In fact
most are silent on the subject. In these cases any jurisdic-
tion can be selected when and if necessary, although it is
quite possible that the person you are trying to take to court
will either ignore you or dispute your choice of location if
it does not suit them. Finally some free and open source
software licenses state that the jurisdiction is either up to
the licensor or automatically that of the licensor (where
they reside or principally do business).
..
Example
Licenses FAQ 61
..
CrabApple University is keen to write a policy on
open source release, as an extremely large endow-
ment specifies this as a pre-condition. Lawyers within
Crabapple decide that a key piece of this policy must
be the anointing of a specific license as the institu-
tions preferred option when licensing out software
as open source. At the first meeting to discuss which
license to choose, it is pointed out that the institu-
tional insurance policy does not cover legal action
abroad. It is therefore decided that an essential feature
of the anointed license must be that it enforces a local
jurisdiction for any legal action resulting from the
release of software it covers.
9.3.1 Patents
Do you or your institution own any software patents? If
you do, and you release some code that embodies them
under a free or open source software license, then you are
very likely to be granting rights to use the relevant patent
(in connection with that code) to anyone who chooses to
use it - even if the license does not explicitly say so. In many
jurisdictions, for example the UK and the US, licensing
someone to take a particular action (like copying or adapt-
ing your code) can also impliedly license them to take all
other steps necessary to take that action. These impliedly
licensed steps would almost certainly include use of your
Licenses FAQ 62
embodied software patent. It should be noted that people
who adapt your code cannot expand its functionality to
capture other software patents of yours - you grant rights
only to the patents embodied in the code you released, not
any subsequent form the code may take. Some free and
open source software licenses say nothing on the subject
of patent grants - although as noted this may not mean
that they grant no patent rights. Some free and open source
software licenses explicitly grant patent rights necessary to
use, adapt and distribute the software.
Your free or open source software license can also in-
clude what is sometimes called a patent retaliation clause.
These sections of a license essentially say that anyone
who brings legal action alleging that the licensed software
embodies one of their software patents will lose the license
you have granted to copy, use, adapt and distribute the
code. Such a clause is intended to dissuade people from
bringing this kind of legal action.
..
Example
Professor Dopaska has created a software-embodied
process for predicting civil unrest that his university
believes is patentable. The professor is keen to release
the software embodiment of this process under the
permissive Apache License, v2, as he wishes to see
the process used ubiquitously to enhance his aca-
demic reputation. Knowledge transfer staff at Profes-
Licenses FAQ 63
..
sor Dopaskas institution are not keen on this idea, as
they wish to obtain the patent and build a spin-out
company around it, and believe that the open source
release will undermine the licensing income of this
venture.
9.3.2 Enhanced Attribution
All free or open source software licenses specify that any-
one who distributes or adapts the software must give credit
to the original authors of the software somewhere in their
distribution. Some free or open source software licenses
go further than this, and specify that the credit must take
a particular form and appear in specific instances, for
example on the softwares user interface every time it is
run. This kind of stipulation is sometimes called enhanced
attribution or badgeware.
..
Example
Edward creates a tool for visualising the frequency of
occurrences of words in documents in an attractive
way. Edward surmises that the tool will probably
be used widely, but is not essential enough to most
users core business to support a paid licensing model.
In truth, what Edward really wants to achieve is
Licenses FAQ 64
..
publicity for the promotional consultancy he runs and
for which the code was written. Edward decides to
release his tool under theCommon Public Attribution
License v1 as this mandates the display of a URL,
a graphic and an attribution phrase every time the
software is run. Edward provides his consultancy
sites URL, logo and strapline along with the software
so that users will help promote his business when they
use and reuse his code.
9.3.3 The Privacy Loophole
If someone uses your code to create an online service or
an in-house solution, perhaps adapting and improving it,
most free and open source software licenses do not specify
that the source to the adapted or improved version must be
released. Most free and open source software licenses make
it a condition of distribution that source code be released. In
general neither making services available over a network,
nor using the code, nor deploying the code within a single
institution is defined as distribution within these licenses.
Some within the free and open source software com-
munity feel that this phenomenon, sometimes called the
ASP (application service provider) loophole or privacy
loophole needs to be fixed. Their argument is that fairness
dictates that all those who benefit from the code must
contribute their work back to the world, even if they are
Licenses FAQ 65
not, strictly speaking, distributing the code.To address this
issue, some free or open source software licenses make
release of the source code a condition not only for dis-
tribution but also for internal deployment and/or making
services available over a network using the software. These
kinds of conditions are therefore particularly suited to code
which is likely to be used in-house or as a basis for a
networked service.
..
Example
Fareeda wants to build a business providing an easy
way for users to build complex slide show music
videos from their photographs on social networking
sites. She finds a piece of open source software under
the GNU Affero GPL v3 which provides a convenient
way to handle the requirement that her site must
interface with many external sites. Looking into the
license, Fareeda discovers that its terms mandate that
- if she modifies the code it covers and uses it as
the basis of a service provided over a network as she
intends - she must also make the source code to her
modifications available to service users. Fareeda must
now decide if her business model will be unaffected,
aided or undermined by this potential responsibility.
Licenses FAQ 66
9.3.4 No Promotion
Some free and open source software licenses explicitly
forbid the use of the authors names to promote a product
or service based upon the authors code.
..
Example
As part of a publicly-funded project Gerhentz Uni-
versity creates code which automatically adapts user
interfaces to arbitrary display sizes. The institution
is keen that the public funding leads to the maxi-
mum public benefit both in open and closed source
software, and so wishes to release the code under a
permissive open source license. However Gerhentz
does not wish to be seen to be endorsing products that
contain their code, as they feel that this may poten-
tially damage the institutions reputation. Therefore it
is decided that the BSD License will provide both the
wide reusability and block on promotional use that
they seek.
This chapter has presented some of the key differences
between the various free and open source licenses, in order
to help you consider what kind of license you might want
to apply to your own code. Examples are provided to flesh
out the kind of considerations that might feature in your
own selection process.
Licenses FAQ 67
You should note, however, that there is not a license for
every possible combination of features, and so it may well
be necessary to compromise on one or more category of
features in order to actually choose a pre-existent license.
To achieve this it can be helpful to rate the features you
desire in order of importance.
There are online portals available for easily understand
more about the open source licensing options like tldrle-
gal.com or choosealicense.com
https://tldrlegal.com/
http://choosealicense.com
10 Your Fortune Cookie
What is it, in just a few years, that made the world to
change its attitude towards programming? I believe its the
power of open source. Over 70% of servers run on open
source(Apache or nginx servers), over 50% of Fortune 500
has jQuery in it. Bootstrap (a css framework, originated
from Twitter, Inc.) with millions downloads. This proves
just one thing. No need to flee earth. We still got goodness
in it.
The popularity of all the above projects are for a few
reasons.
They solved a genuine problem everybody had or a
solution everyone wanted
The solution was elegant enough
Community was open enough for suggestions and
corrections from time to time
Development was not stalled at any point of time
Monetary benefits was not on the priority list.
Are you interested in contributing to back to the hu-
manity as a creative person? These are some simple steps
for you.
Have an open mind. Be receptive.
Your Fortune Cookie 69
Be willing to learn new things, be fond of it.
Be tireless and be shameless.
Try to find problems in the system rather than fitting
in, adjusting and getting things done.
Finding solution for those problems in an innovative
method. Try mix and match different solutions and
implementations for the solutions. No solution is
new; its just a different configuration of previously
existed solutions. s
Happy Contributing!