On Sat, Jul 30, 2016 at 4:45 PM, stepharo <
[hidden email]> wrote:
> Excellent.
>
> I have the proof that I was right. This is about 2 years that I'm
> trying to convince my employer
> to revisit the contract we got with synectique for VerveineJ.
>
> I told them that if I would be other people I would simply
> redevelop a new fact extractor to replace VerveineJ.
>
> But they did not listen and we lost all the efforts around
> VerveineJ and probably around 45 K euros for Synectique
> and also the traction and associated PR. Super cool.
>
> In the past we lost the possibility to create something around
> TimeTravel (because it was perceived as competitive advantage).
>
> This is a lesson I would have like to avoid to learn but some people do not
> get for real what is open-source.
>
> So this is great to see some movements around C# too.
>
> We are working on a C++/C extractor not based on ScrML (it means that he has
> symbol resolution) and CDT is a beast (C++ too).
>
> I hope that we will be able to open-source it.
>
> Stef
Take some arguments from Eric Raymond's "The Magic Cauldron," a
seminal writing on the economics of open source. I've posted this
before but maybe TL;DR, so I pull a few bits here for easy reference.
# Reasons for Closing Source [1]
"The real question is whether [opening source] gains from spreading
the development load exceeds [the] loss due to increased competition
from the free rider. Many people tend to reason poorly about this
tradeoff through (a) ignoring the functional advantage of recruiting
more development help. (b) not treating the development costs as sunk,
and By hypothesis, you had to pay th development costs anyway, so
counting them as a cost of open-sourcing (if you choose to do) is
mistaken."
# What Are the Payoffs? [2]
"open-source infrastructure creates trust and symmetry effects that,
over time, will tend to attract more customers and to out-compete
closed-source infrastructure [for example TCP/IP and Linux]; and it is
often better to have a smaller piece of such a rapidly-expanding
market than a bigger piece of a closed and stagnant one."
# Why Sale Value is Problematic [3]
"Licenses that include restrictions on and fees for `commercial' use
or sale (the most common form of attempt to recapture direct sale
value, and not at first blush an unreasonable one) have serious
chilling effects. [They] exact an overhead for conformance tracking
and (as the number of packages people deal with rises) a combinatorial
explosion of perceived uncertainty and potential legal risk."
# Indirect Sale-Value Models - Give Away the Recipe, Open A Restaurant [4]
"When the Digital Creations people went looking for venture capital,
the VC they brought in carefully evaluated their prospective market
niche, their people, and their tools. He then recommended that Digital
Creations take Zope to open source."
"By traditional software-industry standards, this looks like an
absolutely crazy move. Conventional business-school wisdom has it that
core intellectual property like Zope is a company's crown jewels,
never under any circumstances to be given away. But the VC had two
related insights. One is that Zope's true core asset is actually the
brains and skills of its people. The second is that Zope is likely to
generate more value as a market-builder than as a secret tool."
"To see this, compare two scenarios. In the conventional one, Zope
remains Digital Creations's secret weapon. Let's stipulate that it's a
very effective one. As a result, the firm will able to deliver
superior quality on short schedules -- but **nobody knows that**. It
will be easy to satisfy customers, but harder to build a customer base
to begin with. The VC, instead, saw that open-sourcing Zope could be
critical **advertising** for Digital Creations's **real** asset -- its
people. He expected that customers evaluating Zope would consider it
**more efficient** to hire the experts than to develop in-house Zope
expertise."
"One of the Zope principals has since confirmed very publicly that
their open-source strategy has 'opened many doors we wouldn't have got
in otherwise'. Potential customers do indeed respond to the logic of
the situation."
# And some philosophical musing of my own...
A large downside for a closed source vendor is the increased friction
against people trying out the software and growing its market.
Against concern of losing competitive advantage from exposing the
secret sauce, careful consideration needs to be given to exactly who
is the competition who are going to steal your clients.
For example a tool "to extract information from the source code of
LanguageX and export it for the Moose platform." As closed source,
other Moose experts are treated as the competition, but I wonder how
many players are there, compared to the non-Moose technologies doing
something similar. As open source, the reduced friction to importing
LanguageX into Moose might grow the demand for Moose experts more than
free-riders dig cut into that market.
cheers -ben
[1]
http://www.catb.org/esr/writings/magic-cauldron/magic-cauldron-6.html[2]
http://www.catb.org/esr/writings/magic-cauldron/magic-cauldron-10.html#ss10.1[3]
http://www.catb.org/esr/writings/magic-cauldron/magic-cauldron-8.html[4]
http://www.catb.org/esr/writings/magic-cauldron/magic-cauldron-9.html_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Locked
Spring.Core.dll.f3.mse.zip (934K) 
