RE: Open Source Developer Exchange (Economics)

Hello,

> 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 that can be taken into consideration.

> 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 into 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, drink coffee
and trade.

Nik