How to tell if your open source project will fail

No readers like this yet.
A community building a barn

Opensource.com

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:

History

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

Tags
User profile image.
Rebecca Fernandez is a Principal Program Manager at Red Hat, leading projects to help the company scale its open culture. She's an Open Organization Ambassador, contributed to The Open Organization book, and maintains the Open Decision Framework. She is interested in the intersection of open source principles and practices, and how they can transform organizations for the better.

6 Comments

Your project is going to fail if you're not passionate about it. If you don't believe in what it does, or at least the project is a requirement / stepping stone to help you do something you believe passionately in, I don't think it's going to do so well.

How to tell if your project will fail:
<ul>
<li>You have a deadline.</li>
<li>Your developers are not allowed to talk with the users.</li>
<li>The users involved in the project are only the best performers.</li>
<li>Your accountants insist that they are better at creating your schedule than your developers.</li>
<li>You don't have a project manager who "owns" the project.</li>
<li>You don't have an executive manager who will do what every it takes to make sure the project succeeds.</li>
</ul>

Of course those things are not the reasons why open source projects thrive or fail. But they are fairly good indicators for the real reasons. For instance, good communications between the committers and the other developers and users are very important. Here are some "metrics" to indicate how serious the people in charge of the project are about keeping that communication open. Something you can actually point to that's not just hand-waving. Wouldn't hurt to get a little more official about the list and then see how major projects score.

Your project will fail if you have no passionate Developers. If you "only" have one or two Core-Developers and no Backup for them in Case-of-Emergency. [+20 points of fail]

Think also of Contributors. A Contributor who promote your project in a passionate way is also a Developer. [+10 points of fail]

People who say "Thats MY project. I say what is to be made and no ther opinions will be get into it." will fail. Its all about the fans - the community. [+20 points of fail]

You ask around for new faces for Contributors and Developers and no one (or better no qualified one) came in - Time to rethink? = 0. [+10 points of fail]

The source was written
* 1-2 years ago without review it and only made cosmetic changes [+10 points of fail]
* 3-4 years ago without review it and only made cosmetic changes [+90 points of fail]

people are flowing around, doing things for the project with no knowledge if it leads to a common goal. [+5 points of fail, because startups are to often commercial...]

Your project is a fork of a project with an unhappy community - -10 FAIL points.

Your project is a grudge fork of a project with a happy community - +50 FAIL points.

I found this web site about ms project managament
http://www.msprojectegitimi.com

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.