The document discusses factors that contribute to the success of open source software projects based on research of 174,000 projects. Key factors included having a clearly defined vision and audience, modular design, and communication tools like websites and mailing lists. The research found that adding developers from other continents and enabling users to also be developers were surprising indicators of success. Project licensing and governance models mattered less. Overall, the research provided a framework for evaluating open source project success based on user adoption and continued development.

1. How can we get the widest impact
out of software projects?
NICAR 2013
Rich Gordon

2. The problem:
much code is never re-used
Dan Schultz
We keep
reinventing the
wheel.
“Wouldn't it be
nice if all these
new wheels could Alberto Ibarguen
be used again and "We want to see actual
improved upon use with actual readers
over time?” in actual communities
with sustainability."
© Rich Gordon | Knight Lab, Northwestern University 2013

3. How can we measure
the success of a software project?
• Key question: Do end users make use of it?
• Metrics:
– Downloads
– Installations
– Continued development activity
– Posts to project discussion boards/email lists
– Addition of one or more developers
– Releases beyond initial version
– Buzz /attention / high-profile successes
© Rich Gordon | Knight Lab, Northwestern University 2013

4. They wrote the book
on open-source success
• Studied 174,000 projects shared on Charles
SourceForge Schweik
• Surveyed 1,400 open source developers
• Success = 3+ releases, value for “at least Robert
English
a few users”
Open source projects: Success vs. abandonment
Could assess success vs. abandonment 83,694
Abandoned: initiation stage (pre-1st release) 37,320 44.6%
Abandoned: growth stage 30,592 36.6%
Success 15,782 18.9%
© Rich Gordon | Knight Lab, Northwestern University 2013

5. The framework
for evaluating success
© Rich Gordon | Knight Lab, Northwestern University 2013

6. What matters:
Schweik / English research
• Clearly defined vision
Charles
• Clearly defined audience Schweik
• Well-articulated and clear goals
• Modular software design Robert
English
• Tasks of various sizes are available
for developers to work on
© Rich Gordon | Knight Lab, Northwestern University 2013

7. What matters:
Schweik / English research
• Good project communication
– A good website Charles
Schweik
– Bug-tracking system
– Email list, forum or other communication
system Robert
English
– Documentation
• Developers are users, too:
“Developers participate because they
themselves are users of the software
or because the organization they work
for depends on it.”
© Rich Gordon | Knight Lab, Northwestern University 2013

8. The biggest surprise:
Schweik / English research
• When a project added a developer …
Charles
58% of the added developers were on Schweik
a different continent than the lead
developer
Robert
• The Internet has enabled “intellectual English
matchmaking”
• “Regardless of where a programmer
lives in the world, people can find
software projects” related to their
needs.
© Rich Gordon | Knight Lab, Northwestern University 2013

9. What doesn’t matter:
Schweik / English research
• Which operating system the code
Charles
was written for Schweik
• How many developers were
involved Robert
English
• Formalized governance system
– Most open-source projects are small (not
like Linux)
• Which open-source license was
used
© Rich Gordon | Knight Lab, Northwestern University 2013

10. Different forms
of open-source licenses
“Copyleft” licenses “Non-copyleft” licenses
(open-source restrictions are passed on with the code) (restrictions not passed on)
Athero Public
GPL GPL LGPL MPL Apache BSD/MIT domain
GPL applies Copyleft applies Copyleft applies File-level copyleft; “Do what you like,
even if you to entire application; to software “library”; common for don’t sue us; “Do what you like,
interact with if application the problem, browser software. if you contribute don’t sue us”
the code remotely contains GPL code especially If you incorporate code patented code
(and don’t you must release for JS projects, is into a new file, you can to the project,
incorporate in source code defining what a keep those changes we can use it,
your code) (not just binaries) “library” is to yourself too
under GPL
As you move toward the left of this graph, the restrictions on commercial use become tighter; toward the
right, limitations are removed until you get to “public domain’ – code anyone can use without restriction
© Rich Gordon | Knight Lab, Northwestern University 2013