RE: Open Source Developer Exchange (Economics)

Hello,

First time poster..

> From: Ron Lancaster [mailto:[email protected]]
>
> Proprietary software works because a company is willing to take a risk
> that they have a product consumers will pay for. They incur all expenses
> for creating that product. They then sell that product
> "feature-complete" for a proportional fee of the total cost of
> development to consumers. They do so by creating an artificial supply
> restriction (you have to have a license to use their product).
>

You have restricted the thinking here to software as a packaged commodity,
there is more to the software industry.

> Open software works because developers (or companies) are willing to
> donate expertise to the product. Thus the cost and consequently risk are
> low for the startup. This cost is further reduced by facilities such as
> SourceForge. In exchange for this, they are free to operate the startup
> as they want (including not producing any user documentation or support
> if they feel like it). And, they are free to only work on the features
> they want to (they don't have consumers or business leaders telling them
> what to do).

You might be hard-pressed to find sponsors that will simply hand over (a
significant amount of) money to a project that they have zero control
over.  What is to say that the end product will not benefit a competitor,
and not the  original sponsor? There are rare cases though where
developers are sponsored  full time for their hacking efforts.

The alternative it to allow the sponsor to dictate the project scope, but
in traditional Open Source development the developers dictate features,
scope  and (most importantly) deadlines (if any). Introduce a controlling
sponsor into  the situation and the developer is then locked into an
agreement and obliged  to return deliverables in exchange for financial
compensation.

This is a problem that SourceXchange had, the relationship with the
sponsor of the project and both sides meeting their obligations. For the
developer, they have a commitment to meet milestones and produce working
software, for the sponsor, they have an obligation to pay for the
development at each milestone. This is not the  traditional Open Source
development methodology, the only Open Source part of this  procedure is
the license that the end code is released under.

You can read more about this problem with SourceXchange at sohodojo:

<http://sohodojo.com/techsig/sxc24-postmortem.html>

> Finally, I believe there is at least a fourth business model. That is to
> allow projects to be funded by consumers with the results to be shared
> by everyone. Thus cosource, and sourcexchange, and others? In these
> models, the risk to the developer is kept low (the only real risk is
> that the consumer will default on payment). However, the risk to the
> consumer is high (the developer may not finish, might not do a good job,
> might take longer than expected, the consumer's interest may change by
> the time it is finished, etc.) To date, it appears that these models
> ignored the risk to the consumer and focused on the risk for the
> developer. In other words, it appears that they ignored the fact that
> reducing the risk to the consumer is what makes the first three business
> models successful.
>
> So what does this fourth model have to do?
> *	The consumer must be protected from most forms of risk. That is
> they need to know accurately three things: the work to be performed,
> cost, quality, and schedule.
> *	The developer's risk must be kept fairly low (otherwise they
> might be better off adopting proprietary licensing). This side is easier
> (in comparison) as they need only to be assured of payment if they
> deliver the work as described, at the cost, quality, and schedule
> described.

Sounds like the way most consultancies conduct software development
business  (from Accenture and IBM down) except that the product is then
given to the  commons to be shared. Typically these projects are very
contract-heavy, with strict delivery times and built in penalties if the
development company does not deliver. In this case, risk is measured
according to who you are dealing  with and the conditions around the
project. It is more difficult for Open Source  developers to attain a
reputation on which these companies can see the risk involved in  dealing
with them. The only way around this is for the exchange itself to
guarantee  the risk associated with using its community of freelance
developers, risky and  legally complex in itself.

It is also difficult to build the exchange so that it can scale well. It
seemed that  there was a lot of politics in the sourceXchange project
mentioned in the sohodojo article. Trying to resolve such disputes in the
tradition way does not work for a marketplace as a middle man, since they
can not scale such methods of conflict resolution.

> However, this only answers what to do to make the consumer comfortable
> with using the exchange, not with why they would use it. Why they would
> use it is because a feature has been deemed worthwhile and it is only
> obtainable through this exchange (ransom uses this model).

The main advantage for a client is that they use the exchange as a labor
pool for outsourcing projects. With the Internet, this outsourcing can go
to anywhere in the world which has the potential of reducing costs again.

> The advantages to the consumer is that their risk is greatly reduced.
> The exchange verifies the work to be performed, publicly identifies the
> cost, provides a way for consumers to share the burden of cost, verifies
> the quality of the final product, and reduces the cost of the project in
> the form of penalties if the schedule is not met.

Difficult to accomplish without manual intervention from the exchange (see
above point on scalability). If you can break those barriers down and
simplify it with a  web application, then you are onto a winner.

Establishing a marketplace is a tough procedure. You can build a big
exchange and  wait for people to flow in, or you can start small and
develop the exchange based on feedback from the startup projects. The
first method involves large costs and risks, what if your exchange is
built wrong? The second option allows you to learn from the first projects
and then start taking each part of the project cycle and implementing  it
with software so that it can grow. With enough of a project sample rate,
you should then have developed an exchange that is 'one size fits all'.
The London stock exchange grew out of a  coffee shop in East London where
business men would come in, sit, drink coffee and trade.

Kind regards,

Nik Cubrilovic
[email protected] | www.nik.com.au