Help! I want to help!

• «  OT @ Open Source Think Tank 2008
• Zebra is now Kauri  »

Yesterday, I gave a (very short) presentation to an audience of open source users in the local government, i.e. IT people within the Flemish municipalities. The theme was a war zone report from the trenches, as we were, as usual, amongst many consultants and integrators, the only genuine producer of open source software. Given the scale and complexity of Daisy these days, and the level of technicality of the audience, I decided not to talk much about Daisy or the economical model we created around it, but rather give them some tips as to how they can contribute to an open source project without being a developer. I figured I might as well share that list over here.

• Invest in people and in knowledge. Tell your own staff to read up on open source products, to test them, to evaluate competing products against each other. That way, you'll grow knowledge in house to better define your requirements, and to ask your supplier smarter questions. You'll save time and also produce better RFPs in the longer run.
• Participate in beta programs, install candidate releases, upgrade early and as often as possible. You'll provide your open source project with test reports they can only dream of. Open source projects typically don't have a huge testing staff nor infrastructure: you could compensate for that.
• Question, answer, document: participate on the project mailing list, don't ask direct questions to the developers. By participating, your peers will know someone else is out there, with the same questions or issues, and he or she will feel reassured for not being alone on an island. And don't forget to add the juicy bits of the conversation to the project wiki afterwards.
• Be that word of mouth. Talk about the projects you're using: you are our best marketeer.
• Don't forget open source is like clay: you can make it fit with your environment if you keep your fingers slightly wet. Don't assume an open source project is a static block of granite, but think how you can make it fit with your requirements. Share that process with the community: you'll make the core developers think since you'll come up with use cases from the real world.
• Acquire services from integrators and consultants who give back. You'll support the project (indirectly) that way, and yourself as well: you won't stay dependent on your suppliers because they keep their patches for themselves, locking you into their service terms. Sadly, only maybe 20% of the consultants or integrators actually give back and share with the project they are making money of. So beware!
• Think how you could split costs or combine budgets: talk with your user peers, discuss about common needs and come up with a joint budget for implementation. The use cases will be more generically useful, they'll follow shared concepts, and the developers get more beef to play with.
• Loose your shame, drop language issues: many people in open source communities use English as their second language. Nobody will laugh at typos or non-Shakespearian English, as long as you ask politely and provide proper context. Don't think the other end has a crystal ball pointed at your problem: solutions will only come with properly clued-in people.

That was my short list of the top of my head. I'm sure there's points in here which need expansion, so come up with those comments. Especially now that our commenting system actually works. ;-)