Hi Doru, you are welcome. I have seen and already started to test your new Java implementation -great work. So I can drop my own effort to implement that and to integrate with IKVM (to run it inside my tool ;-). But probably I also find some time to support you with the java implementation because I work in the java as well as in the .NET "domain" ;-) Cheers Thomas ----- Am 26. Jul 2016 um 23:46 schrieb Tudor Girba <tudor(a)tudorgirba.com>om>:

Hi Alexandre, yes it does generate MSE files which can be imported into MOOSE: please find attached an example of the Spring.core assembly. BTW: as you still using MOOSE for astro photo (AstroCloud)? I am just curious because I am also shooting astro photos ;-) Cheers Thomas ----- Am 26. Jul 2016 um 23:55 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>om>:

Thank you for your work Thomas. I add a link on the README file of MOOSE git repository: https://github.com/moosetechnology/Moose On Tue, Jul 26, 2016 at 11:36 PM, Thomas Haug <thomas.haug(a)mathema.de> wrote: -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Hi Serge, you are welcome. Thank you for mentioning my work in the readme. Cheers Thomas ----- Am 27. Jul 2016 um 10:16 schrieb Serge Stinckwich <serge.stinckwich(a)gmail.com>om>:

Hi Alexandre nice diagram :-) thank you for sharing the Email Cheers Thomas ----- Am 27. Jul 2016 um 18:14 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>om>: >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev

On Sat, Jul 30, 2016 at 4:45 PM, stepharo <stepharo(a)free.fr> wrote: 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… [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