(This guest post by Mårten Mickos, CEO of Eucalyptus Systems, previously CEO of MySQL AB, has originally appeared @ opensource.com)
An open source company is naturally a company that produces open source code for others to consume. But how does the notion of producing software code in the open affect company culture?
I believe that an organization cannot produce open source code if it is not generally open itself. By this I mean having culture of transparency and of openly sharing information and ideas. The same basic environment that is often found in open source development–a sense of open community, where everyone is welcome to share their opinions and ideas–is often present in open source companies as well.
But a company is different from an open source community in a key way: in every commercial entity, there is information that cannot or should not be shared with everyone. How does an organization hold a balance between being culturally open and maintaining the level of professional discretion required by its customers, its board of directors and others? How do employees know when to act open and when to keep closed?
During my eight-year tenure as CEO of MySQL, we believed that openness, both in our product and our company culture, would lead to greatness. As a result, there was a daily vibration around the topics of open and closed. For example, it was vital to keep information we received from customers confidential, but it was also important to make every new piece of the server code open. Knowing what should remain undisclosed and what could be openly shared was a skill that we wanted every employee to master. This kind of deliberation is less of a factor in a traditional corporate environment, in which the default environment is generally closed. At MySQL, each employee had to be empowered and enlightened to know when to be open and when not to.
Within this balancing act of open and closed, we followed a principle of being open as much as we could. That’s a good and beautiful principle, but knowing exactly how to apply it requires fine-tuned judgment. As noted, we kept customer information and minutes from board meetings confidential. We did not share personal information such as salaries and performance evaluations. But we really tried to make everything else open: bug database, work lists, design documents, and so on. We also tried to keep business information open. We were open about our business model, our partners and our downloads. And we agreed that in our public communication, we should disclose as much information as possible.
Internally we tried to be open, too. We informed everyone of board resolutions. We discussed difficult strategic choices on company-wide conference calls and in broad management meetings. We encouraged everyone to have an opinion of everything. This radical openness did not come free of charge, however. MySQL AB was known as a company whose staff could debate topics endlessly. Some of our employees and managers were frustrated with the long decision-making cycles. Sometimes openness became the priority rather than a means to an end.
But in retrospect, it is difficult to regret the way we operated. Although the principle of openness may have at times taken a toll on our productivity, it also helped foster employees who were brilliant spokespersons for the company and brilliant decision makers on their own, all the while being amazingly passionate about their jobs and the mission of MySQL.
Today, three years after MySQL was acquired by Sun, I can still easily detect the MySQL spirit in my past colleagues when I meet them here and there. There is an assumption that information will be shared. There is a conviction that debate is useful. What we all know is that inclusiveness and openness of open source communities, when injected into a company culture, can create something special.
(Cross-posted @ opensource.com)
