Six things to know about successful open-source software

In the community of media and journalism innovators, it is commonly accepted that releasing software with an open-source license is the best way to maximize the chance that others will use your code. Yet, by any measure, the vast majority of open-source software goes nowhere.

That's why we've spent some time at Knight Lab trying to understand the dynamics of software adoption — especially the factors that cause open-source software to be widely adopted. After all, our mission is to develop software for journalists, publishers and media consumers -- software that gets used.

In researching the topic, I discovered that two faculty members at the University of Massachusetts literally wrote the book on this topic. In their book, "Internet Success: A Study of Open-Source Software Commons," Charles Schweik and Robert English studied more than 174,000 open-source projects shared on SourceForge, one of the largest and oldest (founded in 1999) repositories for open-source code.

"From 1998 to 2005, there was a lot of hype about high-profile success stories like Linux or Apache, that were really anomalies," Schweik said.  "We were trying to get a better handle on the broader population of open-source projects, and at the time Sourceforge was arguably the dominant open-source hosting site."

I'll summarize their key findings below, but first I think it is important to understand a little about how they approached their research.

The researchers based their work on an analyisis projects hosted on SourceForge as of 2009. They classified projects based on what "stage" the software had reached as of that time:

  • Initiation stage — the period of time before the first public code release
  • Growth stage — the period after the first release until work on the software appeared to have stopped.

A successful product, as defined by Schweik and English, achieves at least three software releases and has value for "at least a few users." As evidence of user value, they looked at project attributes such as the number of downloads and installations, the presence of continued development activity, posts to project discussion boards or email lists and the addition of one or more developers.

Schweik and English supplemented their analysis of the SourceForge data with a survey of 1,400 open-source developers. This enabled them to ask questions about a subset of open-source projects that could not be answered just by looking at SourceForge data. Using this data they were able to identify characteristics of open-source projects that correlate statistically to greater likelihood of success.

Here's a summary of what they found:

1. Most open-source projects are not successful

Among the 174,333 projects they reviewed, Schweik and English found they could assess success or abandonment for 145,475. Of that total, only one in six -- 17 percent -- were successful. Almost half the projects (46 percent) were abandoned in the initiation stage -- before the first software release. More than a third (37 percent) were abandoned after the initial release.

2. Successful projects have some common characteristics:

  • A "relatively clearly defined vision and a mechanism to communicate the vision early in the project's life"
  • A clearly defined set of users who have a need that can be met by the software
  • Well-articulated and clear goals established by the project's leaders
  • Good project communication -- a quality website, good documentation, a bug-tracking system and a communication system such as an email list or forum.
  • Once a project has achieved its initial release, a software architecture that is modular -- so future development tasks can be carved out at different levels of complexity for other developers to work on. (Modular architecture alone isn't enough -- many abandoned projects were also modular, Schweik said.)

Most of these characteristics come down to effective leadership, Schweik told me in an interview. "There is someone who was more diligent, who was trying both to describe their project to the world and to provide a clear vision of where the project was going, and articulating those goals," Schweik said.

3. Open-source projects flourish when developers are also users of the software

"What we found across the board was the motivation of a user-centered need," Schweik said. "I need this software, so I want to work on it."

This is consistent with evaluations done by the Knight Foundation for software projects funded under the Knight News Challenge in 2007-08 and 2009. Successful projects, such as DocumentCloud and Ushahidi, had developers who had reason to use the software after its initial release.

4. The global Internet has made it easier to find software collaborators

While open-source projects can be successful without building a large community of code collaborators, Schweik and English were surprised to discover where additional developers were coming from. When a project added a developer to the team, 58 percent of those developers came from a different continent than the original lead developer -- most commonly, Europe. Schweik said that for many successful projects, developers from multiple continents had never met in person.

The Internet has enabled "intellectual matchmaking," Schweik said. "By having a hub where people go looking for things, it's allowing people with a passion and interest to go connect with each other, and it's driven by this user-centered need."

Adding one or more developers was an indicator of software success, the research found.  The addition of even one developer was meaningful, since most open-source projects are relatively small, Schweik said.

5. Some characteristics thought to be important in the spread of open-source software turn out not to matter

Schweik and English looked at many different characteristics that researchers had suggested could be important for open-source software success. Here are some of the characteristics they found do not matter:

  • which operating system (Apple, Windows, Unix) the code was written for
  • how many developers were involved
  • whether the project has a formalized system of governance (Schweik suggested this doesn't matter much because most open-source projects are so small)
  • which type of open-source license was used
  • whether the project has a source of funding

"In our research, 75 percent of the open-source projects had no funding of any kind," Schweik said. "Investment doesn't appear to drive open-source projects. Rather, the need for the software drives development."

That's not to say funding is unimportant -- "projects that are funded have higher success rates," Schweik said.  But he said it may well be that good projects attract funding, rather than the other way around.

6. Success doesn't have to mean large-scale adoption

Much of the attention to open-source software has gone to massive projects such as Linux, which has had more than 1,000 code contributors and is used throughout the technology industry and businesses large and small. But a project can also be successful, Schweik said, if it meets the ongoing needs of a small number of users.

"A clearly identifiable need, even without a big user base, can be successful," Schweik said.

* * *

I asked Schweik to put himself in the position of a funder, such as the Knight Foundation, that wants to invest in making open-source projects successful. What criteria should such a funder use to determine which projects to support financially?

For projects in the initiation stage (no software has yet been released), Schweik said, a funder should look for:

  • how well-defined the vision for the project is;
  • whether the project's developers have a track record of contributing productively to open-source projects or "leading through doing";
  • how professional and up to date the project's web presence is;
  • evidence that the project leaders have thought about a marketing plan;
  • evidence that the people involved in starting the project have a need for it that will extend beyond the first release.

For projects in the growth stage (after the first code release), Schweik said, a funder should consider:

  • whether the project has a well-defined set of users;
  • whether there is a natural constituency of developers interested in continuing to use the software;
  • whether the developers have prior open-source experience;
  • as with the initiation stage, whether the people leading the project have demonstrated leadership by articulating a clear vision, having a professional web presence and maintaining an active bug-tracking system or other communication platform for interacting with the user community.

About the author

Rich Gordon

Professor and Director of Digital Innovation

Journalism/tech intersection, my passion for 25 years, data journalism, Miami Herald web director, now hacker journalism.

Latest Posts

  • Building a Community for VR and AR Storytelling

    In 2016 we founded the Device Lab to provide a hub for the exploration of AR/VR storytelling on campus. In addition to providing access to these technologies for Medill and the wider Northwestern community, we’ve also pursued a wide variety of research and experimental content development projects. We’ve built WebVR timelines of feminist history and looked into the inner workings of ambisonic audio. We’ve built virtual coral reefs and prototyped an AR experience setting interviews...

    Continue Reading

  • A Brief Introduction to NewsgamesCan video games be used to tell the news?

    When the Financial Times released The Uber Game in 2017, the game immediately gained widespread popularity with more than 360,000 visits, rising up the ranks as the paper’s most popular interactive piece of the year. David Blood, the game’s lead developer, said that the average time spent on the page was about 20 minutes, which was substantially longer than what most Financial Times interactives tend to receive, according to Blood. The Uber Game was so successful that the Financial...

    Continue Reading

  • With the 25th CAR Conference upon us, let’s recall the first oneWhen the Web was young, data journalism pioneers gathered in Raleigh

    For a few days in October 1993, if you were interested in journalism and technology, Raleigh, North Carolina was the place you had to be. The first Computer-Assisted Reporting Conference offered by Investigative Reporters & Editors brought more than 400 journalists to Raleigh for 3½ days of panels, demos and hands-on lessons in how to use computers to find stories in data. That seminal event will be commemorated this week at the 25th CAR Conference, which...

    Continue Reading

  • Prototyping Augmented Reality

    Something that really frustrates me is that, while I’m excited about the potential AR has for storytelling, I don’t feel like I have really great AR experiences that I can point people to. We know that AR is great for taking a selfie with a Pikachu and it’s pretty good at measuring spaces (as long as your room is really well lit and your phone is fully charged) but beyond that, we’re really still figuring...

    Continue Reading

  • Capturing the Soundfield: Recording Ambisonics for VR

    When building experiences in virtual reality we’re confronted with the challenge of mimicking how sounds hit us in the real world from all directions. One useful tool for us to attempt this mimicry is called a soundfield microphone. We tested one of these microphones to explore how audio plays into building immersive experiences for virtual reality. Approaching ambisonics with the soundfield microphone has become popular in development for VR particularly for 360 videos. With it,...

    Continue Reading

  • Audience Engagement and Onboarding with Hearken Auditing the News Resurrecting History for VR Civic Engagement with City Bureau Automated Fact Checking Conversational Interface for News Creative Co-Author Crowdsourcing for Journalism Environmental Reporting with Sensors Augmented Reality Visualizations Exploring Data Visualization in VR Fact Flow Storytelling with GIFs Historical Census Data Information Spaces in AR/VR Contrasting Forms Of Interactive 3D Storytelling Interactive Audio Juxtapose Legislator Tracker Storytelling with Augmented Reality Music Magazine Navigating Virtual Reality Open Data Reporter Oscillations Personalize My Story Photo Bingo Photojournalism in 3D for VR and Beyond Podcast Discoverability Privacy Mirror Projection Mapping ProPublica Illinois Rethinking Election Coverage SensorGrid API and Dashboard Sidebar Smarter News Exploring Software Defined Radio Story for You Storyline: Charts that tell stories. Storytelling Layers on 360 Video Talking to Data Visual Recipes Watch Me Work Writing and Designing for Chatbots
  • Prototyping Spatial Audio for Movement Art

    One of Oscillations’ technical goals for this quarter’s Knight Lab Studio class was an exploration of spatial audio. Spatial audio is sound that exists in three dimensions. It is a perfect complement to 360 video, because sound sources can be localized to certain parts of the video. Oscillations is especially interested in using spatial audio to enhance the neuroscientific principles of audiovisual synchrony that they aim to emphasize in their productions. Existing work in spatial......

    Continue Reading

Storytelling Tools

We build easy-to-use tools that can help you tell better stories.

View More