[Mono-list] Xamarin 2.0 concern

Wed Feb 27 19:09:21 UTC 2013

How do you pronounce "xamarin?"
I see the importance of giving up the mono trademark, as you said, difficult to defend, etc.  But it's a bummer, because it was such an easy name to remember and say.  Like java.

Xamarin...  Not very attractive as a word.  Nor very memorable.  But ... Que sera sera.   ;-)

Still, how to pronounce it?   Samarin?  Zamarin?  Ex-amarin?

From: mono-list-bounces at lists.ximian.com [mailto:mono-list-bounces at lists.ximian.com] On Behalf Of Miguel de Icaza
Sent: Monday, February 25, 2013 2:10 PM
To: Dimitar Dobrev
Cc: mono-list at lists.ximian.com
Subject: Re: [Mono-list] Xamarin 2.0 concern

Hello Dimitar,

   That is, the name "Mono" is now completely phased out of the Xamarin
product line. At  the Xamarin Studio page <http://xamarin.com/studio>  ,
MonoDevelop, upon which the Studio is based, is not mentioned once! Are you
ashamed of MonoDevelop after you've been offering it to customers for years?
At the  Xamarin main page <http://xamarin.com/>   Mono is mentioned only
once at the very bottom, under the "Community" section - is Mono no longer
part of Xamarin itself?

The Mono runtime powers what we do.

That said, there are a few things that matter to a company like Xamarin.   We need a brand that can be protected (for example, to avoid someone misrepresenting the products).

The choice to use "Mono" as a name in the Ximian days predates a lot of the sophisticated thinking that goes into this.   I for one, liked the name, and forced it despite marketing objections and trademark objections.

But "Mono" itself is a bad trademark, it is hard to defend, since it is a very common word.

The second problem is that the owner for the trademark is Novell.   So while we have the rights to use the name, if some sketchy third party in the started to sell something called "MonoTouch" which was some scam, it would be hard for us to enforce compliance without a lot of overhead rom Novell.

We do not need that overhead.

   I think this is not the beginning but rather the end of a process that
started with the renaming of MonoMac to Xamarin.Mac (and please don't tell
me "MonoMac is our community-supported version" because I haven't heard
about it since).

Not sure what that means, we are keeping the core between Xamarin.Mac and MonoMac shared.   Our commits speak for themselves:

MonoMac:
 79 files changed, 1621 insertions(+), 6233 deletions(-)
 82 commits

MacCore:
 138 files changed, 6104 insertions(+), 1074 deletions(-)
 108 commits

And of course Mono, which from January alone:
 2497 files changed, 108854 insertions(+), 237100 deletions(-)
373 commits

The above does not even count MonoDevelop.

We could have kept all those improvements proprietary, but instead we decided to keep the core maintained, and useful, and merely add new value or extensions to Xamarin.Mac, while keeping bug fixes and core features working on par.

Then was the renaming of YOUR MonoSpace conference to
MonkeySpace and the explanation was really ridiculous - "bigger scope...
open source .NET development in general" (Miguel de Icaza at that very same
"Monkey"Space conference).

This merely shows a misunderstanding about the history of MonoSpace.

No member of the Mono core team, of Novell or Ximian *ever* organized MonoSpace.    MonoSpace was an *independently* organized event from Scott Bellware.   He later gave permission to the bearers of the flame (those members in the Mono community that wanted to keep a conference going) to use the name.

The only events Novell organized, or I organized were called "Mono Summits", and they were quite small in comparison.   I just never had the bandwidth, time or resources to do these myself.   Running the Mono project just took too much time.

That said, I provided feedback to the organizers of MonoSpace, and actively campaigned to make the conference go beyond Mono's implementation of the .NET framework, and to make it more about the ecosystem of open source software for .NET and Mono.   The results are in, and we know that growing the scope of the conference to go beyond a single implementation is much healthier, and much better for everyone.

What bigger scope? .NET runs only on Windows, be
it desktop or phone, while Mono runs on tens of platforms, including
Windows. Yes, I do understand it's about "the scope of the community" but
how broader is that community since the only significant piece of .NET
missing in Mono is WPF?

It is right for the community to think about Mono and .NET as two major implementations of a great standard, and we should both (a) build bridges with pure .NET developers and (b) take steps necessary to grow our community.   Windows .NET developers and Mono developers both share an interest: more .NET software, more .NET expertise, more .NET open source, more .NET adoption.

It is very simple math: there is a bigger number of developers in the combined .NET and Mono that share 90% of the DNA, than a pure Mono space.

And for that matter, Mono is purely a runtime.    There are a lot of more interesting things happening *above* the Mono runtime, than with Mono itself nowadays.   So a conference should really needs to be above the CLR/CLI level.

Also, your math is wrong.  As "only" Windows is really a very large segment of the world computers.

2.  "Microsoft Joins Xamarin Evolve 2013 as Sole Platinum Sponsor"
<http://blog.xamarin.com/microsoft-joins-xamarin-evolve-2013-as-sole-platinum-sponsor/>
- I believe Microsoft have proven time and time again that they are enemies
of Mono in particular and of open source in general. I do not want to quote
a large part of the web on that but let me say a few words just about Mono.

It does not matter what you can dig out from years ago.   It matters what they are now.

Years ago they also opposed Linux, now they host Linux on Azure.
Years ago they opposed open source, now they have an entire division working on it.
Years ago they did not open source anything, now they open source a lot of code (both .NET and other).
Years ago, they did not contribute to the Linux kernel, now they do.
Years ago, they would never support Java, now they do.

And I can list another hundred of those.

   Miguel, you may remember you said "Microsoft as a company are not
open-source-friendly" yourself at FOSDEM at the beginning of 2011. You may
also remember how you at the same conference you told the story how you
showed your C# REPL to Microsoft just before PDC 2008 and once they saw
that, they changed their program and rushed their C# REPL with the only
intent of showing it before you did.

That is not what I said.

I know that they knew about our plans early on, and that they wished they had released it earlier.   Because someone showed me the email during a meeting.

But I have *no way* of knowing if their announcement of the REPL at PDC was planned or not.   And I do not care, nor does it matter to me.

The proof that they didn't have a
working product back then (while you did) lies in the simple fact that now,
5 (five!) years later Microsoft still do not have a working version (Roslyn
is still a CTP and nobody knows when it's going to be released).

So software is delayed, big deal.   You would be a happier individual if you did not stress over software projects being delayed, or if you just accepted that some days you are going to get some rain, some other days sun.

Roslyn is much more ambitious than just a new compiler.   They are providing an API, and designing and implement both a compiler, and a reusable API is probably an order of magnitude harder.   As anyone working on NRefactory/Mono, we know that our solution is not as elegant as Roslyn.   We come from two different ends: organic growth and adaptation, vs planned design.   Different approaches, different results.

Miguel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20130227/dd5fd124/attachment-0001.html>