What your organization does wrong when practicing the open source way
(Short URL: http://bit.ly/TOSWDoneWrong)
If you belong to an organization, such as a business, you may apply the open source way to how you do business. How you plan long-term strategy and how you execute short-term tactics. This is one way that the open source way is as set of principles applied to differing disciplines.
For more of an overview on applying the open source way to business practices, read Business the open source way.
In this chapter, various common mistakes are discussed. Red Hat shares some examples, do you have any others from your team or other organizations that apply?
Burns projects and loses momentum in technology leadership by ignoring community fundamentals
One of the challenges of doing business the open source way is the balance of experience and expectations in your employees and shareholders. Accurately practicing the principles of open source requires diligence and patience. Sometimes other instincts and requirements cross the pathway of essential community principles.
Putting your community principles first in action and in risk analysis is essential to accurate practice of the open source way.
Ironically, even the best organizations are not always the best at what they do. Sometimes we break every rule in The Open Source Way.
Breaks fundamental rules of community
In fact, every rule is being broken right now, somewhere inside of our favorite organizations.
Somewhere project team members are designing in the hallway instead of on a mailing list.
A team leader is wondering if they really need to go through the trouble of getting community input on their work.
Someone in a sales organization is failing to show customers the value of being involved in the design and development of the software core to running the customer's business.
For example, there is a common practice of having two mailing lists for open projects. One is an internal list that too often gets used for development discussions before bringing them in to the open. The other is the public discussion and development list.
Similarly, when dealing with ISV partners, the partner team makes tools, content, and collaborates all on a back-channel.
The problem is, community members either know or can feel there is work happening before conversations get to the public list.
As an example of the value of including community considerations in any work, often it takes longer to document a procedure for a task than it does to complete the task.
If this is a procedure you do only one time, then there's no real problem if you fail to document it. However, if it's something that your community members are likely to need to do themselves, take the time. It will mean the knowledge of the process is shared among many, and refinements can be made. Doing so also avoids the danger of losing undocumented knowledge if a community member moves on to other things.
The Fedora Design team has found over time that the initial larger time investment in creating "Design Team Bounties" has paid off in recruiting new team members and increasing capacity, even where the design work involved would have taken less time to complete than the work of setting up and running the bounty.
Fails to learn from mistakes
Our ability to institutionally learn from past mistakes can be hobbled. This is particularly challenging when the open source way is not ingrained in all aspects of your business; this is rather common, keeping open source as a development methodology but otherwise running the business in a traditional fashion.
The Open Source Way is one part of fixing this. We need roadmaps even when we think we know all the routes by heart.
As with many of these "does it right, does it wrong" items, there is an irony at work here. You may have learned serious lessons from past mistakes, yet still see many of the same ones repeated continuously.
You find this when the organization is not listening to the memory keepers, who attempt to speak up and note this has been tried before.
For example, trying to solve problems with closed, proprietary software because of a desire to get something running quickly. Experience shows that, just as we try to teach our customers, over the medium to long term, that decision is going to cost more than engaging with an open solution from the start.
Misses the opportunity to adopt and grow key or future open source technology for your own IT
Even open source businesses have a history that is riddled with decisions to use a piece of proprietary technology for internal or external purposes. In some cases there was no open source choice to adopt and the cost of starting from the beginning was considered prohibitive.
There are, however, as many cases where the open source software could have been adopted and fixed up to the needed enterprise standard by using the open source methodology.
Does not include community strategy in all new projects
Even a project that is only for internal focus and consumption can benefit from considering and including its community.
In other words, we can adopt open source methodologies for everything from our internal communication to brand marketing.
At the Google headquarters, there are brief articles posted on the bathroom walls, along with encouraging signs. The articles are short and technical, detailing how to use and test a particular piece of Google technology. The other signs and branding encourage Googlers to beta test their own software. This is sometimes called eating your own dog food, that is, using the products and methods yourself that you sell and encourage your customer communities to use.
Separates community from business
Like many other companies, your business distinguishes clearly between the worlds of "development" where you support and work with communities, and "business", where you have adopted hierarchical controlled structures.
This mirrors a traditional business approach, where interacting with communities members is analagous with customer service, a sub-branch without real power to change the rest of the business.
Sometimes from a historical evolution, this separation is comprehensible. Unfortunately, we can't always explain these histories so they make sense in the modern context where open community organizations act in a more integrated manner.
A key community growth initiative that will benefit the bottom line is to make growing various types of communities (customers, sales, partners, etc.) a top-level strategic goal. Agree that you need to include community interaction as part of the feedback loop that improves your business and processes.
Think of every way that "customer" and "customer service" have integrated with various parts of successful customer-focused businesses. Then substititue "community" and "community enablement".
There are examples out there, where companies successfully integrate community principles into their business and gain benefits from their customer and partner contributions as they do from development.
A good exercise is the comparison of community integration on the web sites between Red Hat and JBoss on one hand and Oracle, SAP, Novell, and IBM on the other hand. You can see the strength of the stand-alone community, but in the former you don't see obvious community offered for customers and partners. In the larger, traditional, proprietary companies, they have put forth the face of having learned they need to be a leading member in the community of their customers and partners.
A similar exercise can be done with smaller pure and mixed open source ISVs. The community is forefront and listening to/interacting with users is a key to their growth.
Ironically, applying the open source way via community principles is sometimes more evident in companies that do not practice open source development. Twitter, for example, builds on open technologies, has a rapid and iterative approach to incorporating user ideas, and otherwise shows a high level of listening to and learning from end-users that is similar to how open source listens to end-users.
Only part way to free and open leaves you in limbo
If you only go part of the way with making your efforts fully free and open source software and content licensed, you gain none of the supposed benefits of closed and proprietary source while losing much of the benefits of the free and open model.
This is easy enough to implement. Choose not to be afraid of a full commitment to following the open source way. In your licensing choices, make sure your license is one known not to restrict essential freedoms. You can refer to the Fedora licensing list for information on good licenses to use and bad licenses to avoid.