These questions frame several broad issues that are still being played out in the marketplace.
I'll answer your first question in two ways. First, the most common way to compete is with a "from the source" advantage. Companies formed around a particular open source project are usually founded by the core developers (like MySQL and SugarCRM) and can claim that their services are therefore more expert.
Consulting firms offering services for a range of open source technologies (like my employer, Virtuas) frequently employ project committers and known experts (who answer questions on Techtarget, for example). By the way, Red Hat is something of a special case, since they compete by making an end-run around the GPL through the enforcement of their trademarks. Some would argue that Red Hat's model is quasi-open source.
For those companies that have formed around a single open source project, the critical issues for growth will be the maintenance and nurturing of the community and promotion of the brand. It's the brand that helps to assure their expert place in the market.
How do proprietary firms compete with open source upstarts? This is a big question in the industry right now, and there are many discussions about what to do about threats from new open source competitors. Some companies are deciding that they must join the trend and open source part of their code. Others have decided to stay with their existing model. But all are likely to feel price pressure from open source competition as soon as the newcomers reach a certain level of mainstream acceptance.
Open source has an advantage when projects and business models creep into the world of dominant proprietary software companies. The overall effect of the open source model, from a licensing, rights and responsibilities perspective, is to put price pressure on entire software categories. Why else is Oracle lowering prices and even offering a free version? It's from the price pressure generated by rivals MySQL and PostgreSQL. And with open source, the rule of source code availability means that anytime an open source vendor (like Red Hat) raises prices too high for a portion of the market to bear, then a third party (like the non-commercial CentOS) will have an incentive to take the code and produce a lower cost option (in this case, free).
Let me first explain "interface with communities of practice to exploit network externalities" for those less familiar with this language. "Interfacing with communities of practice" essentially means getting your technology into the hands of the people using and advising on that type of technology. And "network externalities" refers to the effect on the benefits a consumer receives from a product when the number of other users are taken into account.
The classic example to explain network externalities (also called "network effects") is that of fax machines. If you're the only one with a fax machine, it's not very useful. But once everyone has a fax machine, the usefulness (benefit to the consumer) changes. This example is a positive network effect, but network effects can be negative, too. Once the latest fashion trend shows up in the children's department of Old Navy, for example, the original wearer just doesn't look as cool in the clothes anymore. So now to the question... how can open source firms interface with communities of practice to exploit network externalities? In other words, how can open source firms get their software into the hands of the people on the ground that typically deal with that particular type of software, and how can they try to create a snowball effect of popularity?
The answer lies in connecting to your potential user base in a real and meaningful way. Make it as easy as possible to acquire and use the software. Doccument the hell out of it. Offer training options. Be friendly and responsive to any press inquiries. And develop a reputation for providing friendly help to newcomers. A snotty, elitist attitude will keep the software exactly in snotty, elitist hands, not exactly triggering a snowball effect of adoption.
Finally, what strategies do they adopt to lock in developers? Locking in developers in this new world of open source means something a bit different from what it used to. Developers are becoming more wary of lock-in, and are employing their own strategies to avoid it, such as using platform-neutral languages and writing only to standards. Proprietary add-ons are the most common way to maintain the tradition of developer lock-in, but in this wider world of choice brought on by the open source phenomenon, you may be passed by for a more open alternative. The best way to keep developers stuck to your code is to strive to be exactly what they need, and work to make the whole organization as responsive as possible.
This was first published in February 2006