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

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 [...]