I want to point out a post Alex Finger (OGP) wrote over the weekend.

It has been said that you can divide open source people up into three groups: Those who write open source code, those who pay for open source code and “free riders”. I think that is total crap, and Alex is one of the reasons why.

Alex doesn’t write much code, yet he has been a great contributor to OpenNMS over the years. His career is in IT management (as in managing people and solutions), and he’ll soon take a new position as a CIO. What he brings to the table is a view on open source from upper management.

It is no secret that OpenNMS is usually introduced into an organization from the bottom up (usually, but not always). We don’t have any full time sales people and most of our leads come from people who have already downloaded and installed the software. I don’t see anything wrong with that, but sometimes it is nice to be able to talk to the top people in charge, especially when you want a check written. In order to be successful when talking with those at the top of a management structure, it helps to understand them, as they process information much differently than the technical people I’m used to.

To me an open source community is a lot more than just who writes code. Everyone who uses the software can contribute. But until this weekend I did not have a good model for understanding the process of how one becomes a member of that community.

Alex has come up with something he is calling “the DUFLTCC Cycle”. It’s an acronym that stands for Download, Use, Fail, Learn, Teach, Change, Commit.

Check out his post for the full details. I especially like the “Fail” step. A lot of open source software requires a steeper learning curve than commercial off the shelf products, and usually everyone gets stuck at some point. It’s those that use those failures as a learning experience that, should they overcome them, tend to become some of the more vociferous proponents of the project.

I often paraphrase The Matrix when discussing my open source experience in that it is one thing to know the path and another thing to walk the path. Once you walk the path the use of open source seems to be a no-brainer. But how do you get that across to people who have never even seen the path in the first place? It’s ideas like Alex’s that help, and work like this is as important as any code in a community like ours.