Fair question. And it gives me a good place to start what I hope will be a more regular discussion of such topics here, rather than the headline-driven reactions that have characterized this blog heretofore.
So, without any further ado, here are five tips on how to work with your open source community!
- First and foremost, always err on the side of transparency. Even if your business model, like xTuple's, involves selling commercially-licensed products, you'll still pay a heavy price if you're perceived as trying to hide stuff. Forum discussions, bug trackers, and the like should all be completely public. Your source control for the free product (SVN, Git, CVS) should be publicly accessible, and you should also have as much documentation publicly available as possible.
- Related concept - publish your pricing. Especially if you're coming from a proprietary world like ERP, where the whole game in the sales cycle was NOT to reveal the pricing -- until the hook was so far in the prospect's gills that they couldn't shake free. It turns out that people want to understand how you're going to make money, and survive as a business; while there will always be people looking for a completely free lunch, most serious business customers will eventually want to strike a fair economic balance with you. (Note: that might well entail some kind of non-monetary exchange, such as code contributions, translation/localization, or just community support. But that has an economic value to your company too).
- On to the development process... by all means, engage with potential contributors as early in the process as possible. One of the saddest things to happen in open source - and I daresay it's happened to most any project of any size - is when a contributor comes in out of the blue, and dumps a pile of code in your lap that you can't use. Shame on them, I guess, for toiling in obscurity without learning the rules of the road - but more shame on you, probably, for not leaving the right trail of bread crumbs for them to follow. In xTuple's case, discussions of new features typically start in the forums (here's a good example having to do with Fixed Asset management), then - if it's a significant enough development effort, it will likely require some sort of specification. For smaller efforts, a detailed description in the issue tracker might be enough (here's a good example of a contributor's work on an integrated spell checker.)
- The spell checker example above also illustrates the next tip: Keep communicating! Once you've got an initial idea of how to get started, active two-way communication between the developer and the rest of the community is crucial. Both in the proactive sense of not conflicting with other people's work, but also in the reactive - back and forth discussion over the planned approach, and of course the results of actual testing. This generally happens in the form of additional notes and comments - either in the bug tracker, forum topic, or even comments on a published document like a spec.
- Understand the project's timelines, as well as standards and processes for QA testing. and documentation. Some projects (often corporate-sponsored ones) are more focused on meeting particular release date goals, others (such as the outstanding PostgreSQL database) take more of a "when it's ready, it's ready" approach. In the case of xTuple, we do try to keep to the general outlines of our published roadmap, and have apportioned dedicated company resources not just to coding, but also working with community volunteers, and managing a rigorous QA and documentation process.
