Re: Open Source Developer (Economics) - Summary of responses

Hallo Gentleman,

Sincerely thank you to everybody that responded to my initial letter to the
FSB. I have broadly categorised and summarised the responses as per my
interpretation:

Relative Skill and Acumen:
Nobody was concerned about the ability to write the code but almost all were
concerned about "knowing" what to code. A lack of business or specific
industry knowledge meant that a solution to obtain the knowledge is firstly
required - i.e either pay the accountant to supply the knowledge or find the
accountant that will work for free over the weekend to help OSS (not very
likely). Secondly the level of knowledge overlap between programmer and user
is also noted as it has an impact on finding the easy and quick solution as
opposed to the complex user requirement without the programmer and the user
understanding eachother's worlds.

The penetration strategy followed by OSS was along the path of least
resistance - the problems were technical and decisions could be made on
developer level as opposed to management committees, line managers or tight
specifications. Large-scale business problems needed input on design
decisions from people who understood or had sufficient institutional
knowledge of the industry to make design decisions. Milestone dates where
inspirational rather than hit or burn targets. Out of this strategy highly
stable and reliable software was born and it zoomed in on mission critical
components where the opposition was behind on its development because its
strategy was to increase number of users hence focus on desk tops and not
servers. The quality and flexibility of software developed in this culture
of participative collaboration is fact and is becoming more known outside
the close-knit community that incubated it and brought it to maturity.

Accountability:
The "sue-factor" - some of the members on the mailing list indicated that
large-scale projects have a serious impact on companies and if the project
"goes south", who will be accountable for such losses that may be incurred.
It also appeared that there is a credibility aspect to consider amongst the
typical managerial buyers - it is safer to go with the big names because the
size of their balance sheet makes it too risky to either let the project go
south or they can throw money at a project if the customer intends to sue
for damages. It was also clear from some members that delivery is a crucial
aspect - if OSS developers intend to make business from their efforts then
they need to adjust from relatively loose inspirational driven deadlines to
very serious high impact deadlines set by the paying customer.
Discussion:- Open Forum Europe recently published a report where it was
indicated that the lack of accountability was one of the main reasons why
CTO's and CFO's in government and large corporate institutions tend not to
consider OSS as a solution to their customised IT needs yet more that 30%
indicated that they would be keen to consider OSS solutions.

Funding:
Another frequently mentioned obstacle was access to funds to develop
business software - i.e pay the accountant and hopefully the developer also
to develop the products. Discussion:-  If product development is not the
focus but rather solution development for a particular need then consulting
fees could be billed. CTO's and CFO's buy solutions that make their business
operate and preferably that will increase their headline earnings and or
reduce the expenses. They pay volumes of funds to multinationals like
SIEBEL, SAP, Oracle - to name a few - to customise their own proprietary
software just to operate in their companies - why? Effective market
positioning of the supplier causes the customer to believe in the supplier's
advocacy of its solution. The solution provider market is a relationship
market where the properly met needs of one customer are the key to future
business - it is mostly a market of one. As the proprietary software
companies mentioned earlier so to it is possible for OSS to repeatedly
re-sell the same solution with some customisation into the same industry -
e.g. Asset management software developed under OSS for a bank client,
largely the same algorithms and objects are used in the entire banking
industry on a global basis but may need customisation to integrate with the
legacy software of each bank that acquires the package. But yet again the
focus will be on the relationship with the new customer and not making the
customer conform to the software's requirements of the previous customer. It
is traditionally less expensive to go through software change than massive
organisational change - true sometimes the acquisition of new software does
require some organisational change as well. The marketing adage says "share
of voice = share of market" - therefore funding is a combination of
developing a business solution financed by a customer and marketing a
similar solution to similar customers.

Summary:
Most if not all the responses were positive and agreed that there is a
demand for OSS in business critical software solutions. There was a sense of
keenness to address the potential market but the disparate and multifaceted
obstacles based on the history of OSS calls for a complex if not too complex
solution for any one party in the community to address. Whichever solution
comes about will need the participation and collaboration of the OSS
community like in the days of Linus, Eric et al. Like Linus said - the goal
is World Domination  - and with approximately 30% (excluding Apache) of the
server market captured critical mass has been achieved. Critical mass
however means that to sustain the momentum the next wave of market
penetration needs to commence.