Contribute or Die?

In the past years, I participated to plenty of meetings, conferences or research sessions covering technical or even non-technical aspects of information security or information technology. When looking back and trying to understand what I have done right or wrong and especially, what's the successful recipe in any information technology project. I tend to find a common point in any successful (or at least partially successful) project : making concrete proposals and build them at the very early stage of the project.

A lot of projects have the tendency to become the meeting nightmare with no concrete proposal but just a thousand of endless critiques of the past, present and future. Even worst, those projects are often linked to those "best practices" in project management with an abuse of the broken Waterfall model. After 3 or 4 months of endless discussion, there is no single prototype or software experiment just a pile of documents making happy any committee but also many angry software engineers.

If you are looking at successful (free and non-free) software projects or favourable standardization processes, it's always coming from real and practical contribution. Just look at the IETF practices compared to the "design by committee" methodology, practical approaches are usually winning. Why? because you can see the pitfalls directly and reorient the project or the software development very early.

There is no miracle or silver bullet approaches for having successful project but the only way to make a project better is to make errors as early as possible. It's difficult or near impossible to see all errors in those projects until you'll get your hand dirty. This is the basis of trial-and-error, you have to try to see if this is an error or not. If you don't try, you are just lowering your chance to hit errors and improve your project, software or even yourself.

So if you are contributing, you'll make error but this is much more grateful than sitting on a chair and whining about a project sheet not updated or having endless discussion. There is an interesting lightning talk at YAPC::EU in 2008 : "You aren't good enough" explaining why you should contribute to CPAN. I think this is another way to express the same idea : "contribute, make code, prototype and experiment" even if this is broken, someone else could fix it or start another prototype based on your broken one. We have to contribute if we want to stay alive…

Tags: contribute startup innovation