Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.
How to tell if your open source project will fail | Opensource.com
How to tell if your open source project will fail
Get the newsletter
The new community get-it-done handbook, "The Open Source Way," doesn't seek to be controversial, but with information that's distilled, brief, and to the point, contention is unavoidable. Especially where the book takes a hardline stance on how to act and not act; a stance that is derived from the years of experience of the contributors involved.
One chapter has been the most discussed--and debated--so far. It's sourced from a blog post by Tom 'spot' Callaway, Fedora Engineering Manager and one of the more prolific packagers in Fedora Project history. As you can see from this excerpt, spot takes a hardline stance about how open source projects should be structured so that other contributors can interact with them in a meaningful way:
Your code is a fork of another project [ +10 points of FAIL ]
Your primary developers were not involved with the parent project [ +50 points of FAIL ]
Until open sourcing it, your code was proprietary for:
1-2 years [ +10 points of FAIL ]
3-5 years [ +20 points of FAIL ]
6-10 years [ +30 points of FAIL ]
10+ years [ +50 points of FAIL ]
(Read more: How to tell if a FLOSS project is doomed to fail.)
While much of the current version covers software-specific metrics, we'd love to see some of the other pitfalls--such as those found in "Communication," "History," and "Licensing"--form a new section of the chapter, or a whole new chapter, that translates, elaborates, and interprets them for those pursuing the open source way in projects beyond software development.
Fortunately, because both opensource.com and theopensourceway.org use the CC BY SA licensing, we can move content between them seamlessly. Contributing to the book is as easy as leaving a good comment.
To start, I propose that when you step outside of the world of software, every open endeavor does not need a mailing list. In fact, I think email listserves often lead to excessive iterations and input from the "Devil's advocate," who typically has more interest in debate for its own sake than actually making a useful contribution.
And when it comes to history, I'd suggest that the length of time something has existed matters far less than who supports the idea of opening it up. If a passion for transparency and outside input does not permeate the organization, the open initiative is going to fail. It will either crumble from within or be crushed from outside pressures.
But perhaps my red flags for a doomed undertaking in openness aren't the same as yours. So I ask you, my fellow devotees to radical transparency: How can you tell that an open source endeavor is doomed to fail?