Sometimes our best intentions give way to our worst, for a wide variety of reasons. This is as true of corporate amalgamations of individuals as it is of those individuals on their own, and it's as true for open-source companies as it is for proprietary companies.
Community is the tonic that keeps corporate aspirations in line, just as community helps to keep individuals walking the straight and narrow of societal norms. As The Economist recently highlighted, new research suggests that "having a crowd around often makes things better."
In other words, while we normally point to crowds as motivations for mob violence and such, it may be that crowds more often have a pacifying than an inflammatory effect on explosive situations.
For open-source companies increasingly experimenting with models that flavor open-source code with proprietary complements, it's imperative that we guard against backsliding into the lock-in of the past proprietary decades. The way to ensure this is to spend as much time cultivating community as we do devising commercial add-ons to our otherwise open-source products.
There's safety in community. Safety from the company's best intentions getting clouded by its worst. Safety for customers.
I've written before that I think a transparent distinction and delivery of an open-source core and proprietary add-ons can be beneficial to one's community. Most open-source businesses will find it hard to scale on a support-only revenue diet and given that big customers want their vendors to scale to reduce their investment risk, a conflict erupts that is much easier to manage with a hybrid approach.
But community is critical to ensuring the company doesn't devote so much of its development resources to the proprietary bits that the core gets forgotten or, that if it does, the community can thrive in the company's absence. A crowd can help avert violence. In open source, it can also help prevent good intentions going bad.
Follow me on Twitter at mjasay.