If you have the chops, your open source software project should lead and inform your commercial product. Red Hat and Ubuntu have done this brilliantly. Fedora precedes RHEL. Feisty goes before supported Gutsy. Both companies have rabid communities who gobble new code and contribute back fixes and improvements. The developer communities are happy to get cool new stuff. The commercial guys get better fit and finish. The early users are often the production guys as well, so they value early experience and use it to influence the production code. It’s a quality loop and better for everybody.Success with this strategy is twofold. First, you need rank technical competence. The user community wants a deep conversation with you about your project. If you can’t meet them as equals you won’t get the product right. A working open source community is manna from heaven for a software company, but it has to be a conversation between technical peers.Second, you need the community involved in the project from inception and they need to influence the project. Unilateral releases create adversarial relationships. Having users on the development team is one of the pillars of open source. When you engage early, you get “how can we get this cool thing to work” instead of a face-off. That’s a great place to be. As an aside, community involvement is one of the things GroundWork does particularly well. Look at GroundWork Connect, the new community support portal, announced just this week. The idea is that users provide feedback, the community pitches in, and there’s plenty of discussion. It’s in early stages still, but it’s a good start.It’s EASY to make money with Open Source. You simply provide great technology, superior service, innovative documentation, good prices, honest sales and insanely great follow-up. The companies that get this are tomorrow’s open source success stories. How many can you name? Technology Industry