Open Business Models: 2007-05-08 Blog

Business and Open source

This Editorial from mark Hinkle on Enterprise Open Source Magazine, this essay from William Hurley and also a recent story in Slashdot, provide some interesting food for thought about the convergence of OpenSource software and traditional business.

The Editorial by Hinkle points out the growing trend among large corporations in employing OpenSource software as the basis of their products and services.

Hurley talks about how a lot of the businesses active in the OpenSource realm are taking from the communities, without really giving back:

Let’s use the monitoring segment of systems management as an example. Several “open source contributors” simply download code from popular projects and then “build” their software, service, or company on top of it. These contributors often refer to “improvements” they’ve made. Where are these improvements? Why weren’t they contributed to the community from which they took the code? Open source should be about working together for common benefit.

Nagios is one of the most popular monitoring projects in open source, and one of the most abused. There are countless projects, products, and services predicated on the Nagios code base—some symbiotic, others non-contributing parasites. What separates legitimate use from outright exploitation? Where would you draw the line? Should violators be black-listed by the community?

To me, open means that everyone can participate on a level playing field. As a community we have to take the good with the bad, but I cringe when I see a project taking more than its fair share of punishment. How will the community address this problem? Should there be a rating system? A sort of mooch-o-meter to rank companies and projects that use open source? Would that subjective hierarchy help or hurt the community? How would it be regulated?

The community has to answer some of these questions if open source is to continue to flourish. Everyone who leads, participates in, or utilizes an open source project should realize they have a personal interest in protecting it from abuse. Keeping the pirates honest will take effort, but the repercussions of apathy will affect us all in the future. Besides, tales of the pirate hunters are often more exciting than the tales of the pirates themselves.

The Slashdot article has some interesting comments about some of the companies that do give back to the OpenSource community, such as IBM, and Ubuntu, how they accomplish their programs in a business environment. Importantly, comments in the Slashdot article also discuss how many existing and long established OpenSource projects have been influenced, positively and negatively, but the introduction of MoneyIncentives?, SoftwareBounty? programs, and large amounts of funding.

Some key points and debates from the Slashdot article comments:

Centralized vs. P2P in the face of complexity?

• The issue isn’t about whether too much money or commercialization is killing open source software (culture/roots/projects). It seems to me that the root cause has to do with the nature of the widely publicized open source projects. As open operating systems (Linux, NetBSD?, etc.) and applications (Mozilla/Firefox, OpenOffice?, etc.) grow in complexity, they outstrip the abilities of ad hoc, grass roots “open source” organizations to develop and maintain them. Simply put any serious, valuable, widely-used open source project today is very likely a large and complicated one. Open Source has outgrown its own infrastructure and the only one available that can pick up the projects and move them forward are those operated by commercial organizations with the resources to throw at these hard problems.

vs.

• As projects become larger and more complex, they outstrip the ability of anything but a decentralised network of programmers. The resources of a traditional centralised software company, even the biggest in the business, is nothing compared to what decentralised networks of programmers have. The linux kernel team being one excellent example. And commercial software houses – many of them – are definitely involved, but the model is still distributed. No single company could handle that task – a widely distributed team from all around the world, with both commercial and noncommercial interests contributing, can and does. Projects that attempt to decentralise their development while still retaining a monolithic structure internally may find that doesnt work so well, of course. For this to work the project must follow the ‘unix way’ and have many more-or-less self contained modules that work together, rather than building monolithic do-everthing apps. Not everyone seems to grok that yet, but give it time.

How money affects Innovation vs. Refinement

• Gnome is a big project. There is a lot of code, and a lot of it is showing its age. If Gnome was an all volunteer effort, there would be a lot more focus on exciting new technologies, and less focus on fixing bugs and cleaning up old code. In a sense, this is how I see KDE. KDE is pushed forward by developing new projects and applications, but to a certain degree suffers from the fact that things are constantly being reinvented rather than refined. The hard work that has gone into Gnome by commercialization has helped reduced bugs in the code, kept it up to date, and continues to push the project forward.

Open Business Models and Open Source Software

One of the primary reasons we see these issues arising, is because the BusinessModel? of the companies creating software and services based on OpenSource software is often not and OpenBusinessModel.

OpenSource software will tend to work better with OpenBusinessModel organization.

Why? Because OpenBusinessModel organization is designed to reciprocate equal value back to contributors, whether they be individuals, or traditional business entities.

OpenBusinessModel organization optimizes OpenValueNetwork exchanges. Participants actively create a KnolwedgeCommons? as part of the business process. The divisions between all participants in the ValueChain, and BusinessCycle? are lowered, so that feedback and knowledge can flow throughout the system. Some of this is accomplished by the Lincense (example: ObmLicense). Some of this accomplished via a contract, or agreement, that sorts out the license and reciprocation details. People can still participate without contracts or agreements. However, there is incentive of course to be rewarded for working under an agreement that rewards for the exact same contribution.

How is this accomplished:

• Focus on the problems taht need to be solved, and not on the amount of money that needs to be made.
• Avoid creating un-needed monolithic organizations that suck up resources. Instead, try to make every participant and actor an equal partner in the venture, based on a fair value for their contribution. Make tracking of contributions open and accountable when when possible.
• Give feedback and input from developers, users, and funders (or funder/users) equal ground.
• Show the licenses that will be employed, and the agreements made whenver possible.
• Turn “competitors” into co-collaborators by creating reciprocating connections between KnowledgeCommons. The only “competitors” this will not work with are those who refuse to share the knowledge they have built up in their usage and employment