In 1991 or 1992, I wrote a curses-based file manager for Unix, a clone of the DOS Norton Commander.

Unlike the Norton Commander, curses, xterms and Linux did not support the mouse. So I called my file manager "The MouseLess Commander".

Linux at that time was a cauldron of hot ideas. And Alessandro Rubini created a library for console applications to get mouse support on Linux. We worked to add mouse support to the MouseLess Commander and by the end of this exercise we renamed the file manager to "The MouseLess Commander With Mouse Support".

Somehow I was talked into changing the name of the Mouseless Commander with Mouse Support. Since I was pretty bad at naming, we organized a vote on the mailing list and eventually the current name "Midnight Commander" was picked.

I miss the previous name.

Richard Stallman does not seem to have anything better to do than launch personal attacks against me. In his last piece he has decided to call me a Microsoft apologist because I do not participate in his witch hunt.

I merely happen to have a different perspective on Microsoft than he has. I know that there are great people working for the company, and I know many people inside Microsoft that are steering the company towards being a community citizen. I have blogged about this for the last few years.

At the end of the day, we both want to see free software succeed. But Richard, instead of opening new fronts to promote his causes, attacks his own allies for not being replicas of himself. To him, ridiculous statements like Linus "does not believe in Freedom" are somewhat normal [1].

A Matter of Perspective

A few years ago, I had the chance to listen to Benjamin Zander in person talk about his world of possibilities. His book "The Art of Possibility" had a profound effect on me.

Benjamin tells this story in the book:

Two shoe salesmen were sent to Africa in the early 1900's to scout the territory.

One telegraphed back: "Situation hopeless. Stop. No one wears shoes."

The other telegraphed: "Business opportunity. Stop. They have no shoes."

Since we only have a limited time on earth, I have decided to spend my time on earth as much as I can trying to be like the second salesman. Looking at opportunities where others see hopelessness.

This is why I love my work, because I work with friends that have consistently beat the odds and we have consistently proved our critics wrong. Because everyone that I work with wants to change the world and nobody I work with is dominated by fear.

Far too many times, fear has prevented people from coming up with creative solutions. I rather work on constructive solutions to problems than moan and complain.

Fear mongering is a vibrant industry, it is the easy way out for those that can not lead with the example. Create a bogeyman, make things up, lie, or tell half-truths, and demonize and you got a recipe to energize your base.

Richard's Fear Mongering

The documentary "The Power of Nightmares" is a fascinating view at the industry of selling "safety" to the scared population and how leaders like to scare people to push their own agendas. Richard's fear mongering is no different.

Richard Stallman frequently conjures bogeymen to rally his base. Sometimes it is Microsoft, sometimes he makes up facts and sometimes he even attacks his own community [2]. His language is filled with simple, George W Bush-eque terms like Good vs Evil, Us vs Them.

The creation of the CodePlex foundation was an internal effort of people that believe in open source at Microsoft. They have been working from within the company to change it. Working at CodePlex is a great way of helping steer Microsoft in the right direction.

But to Richard, this simply does not compute.

To Richard, the state of the world is hopeless. I on the other hand see possibility and opportunity.

Not only you attract more bees with honey than with vinegar, there are lots of shoes to sell.

[1] Plenty of attacks on other open source/free sofftware advocates/developers are readily googable.

[2] the "open source" vs "free software" non-issue and the "Linux" vs "GNU/Linux" wars of the 90's that haunt us to this day.

Comments

I am now closing the comments for this post. Feel free to move this to the Slashdot forum.

I will be presenting at StackOverflow DevDays in Boston, on October 7th at 4.20pm.

As usual, I will be talking about Mono. But since Mono is an giant universe, I would like to know what the audience would like to hear about.

Please fill in my small survey to provide feedback.

See you there!

At the ECMA meeting in January of 2003 Anders was presenting C# 2.0:

Todd Proebsting had just developed iterators for C# and was presenting, it was inspired by his previous work on Icon's iterators. Sam Ruby (from IBM), Thomas Plum (from Plum Hall) and Todd:

Anonymous methods, the foundation for lambdas in C#, used a beautiful code generation technique. Anders who has a beautiful hand writing was explaining the design to the committee:

Jim Hogg presented the design for generics in the ECMA CIL. Here he is discussing with Arch (at the time with Intel, and the guy behind ECMA's System.Parallelization), Jon Jagger and Emmanuel Stapf (ISE Eiffel):

Joel Marcey, then at Intel and Jim Miller:

Todd and Chris Fraser. I was fanboying them. Mono's original JIT design was based on a lot of his work. At dinner Chris recommened Csikszentmihalyi's book on Flow, which I loved:

Here is a rough draft of the comment policy for my blog.

When you come to my blog to comment, you are a guest in my blog and your opinions are hosted there in the same way that you would be hosted if you showed up at my place to chat.

So standard rules of social engagement are required. If you are unable to operate under regular social situations and you feel the need to insult others or myself in my blog, not only you are not welcome, but your comment will not show up and will be promptly deleted.

Constructive criticism is always welcome on my blog, now

If you feel the need to be rude, offensive, lie or you are intentionaly trying to start a fight, I encourage to do that in your blog.

If you can not articulate your thoughts without attacking and you can not keep your temper in check, I encourage to do that on your own blog.

Trolling will be removed.

Today Andrew branched Mono trunk for the Mono 2.6 release.

Mono 2.6 is the last release that will support the mscorlib 1.1 profile and the C# 1.0 compiler. We are now moving to a pure generics world with Mono.

Update: Specifically, we will be removing the 1.0 assemblies from the build, the mcs.exe command will now point to gmcs.exe, all of the xxx1 command versions will be eliminated and all of the conditional code in the Mono class libraires that depended on NET_1_0 and NET_1_1 will be removed.

As for the Mono 2.6 release notes: we will put those together in the next few days. Please be patient.

I want to say that God loves all creatures. From the formidable elephant to the tiniest ant. And that includes Richard Stallman.

As for me, I think that there is a world of possibility, and if Richard wants to discuss how we can improve the pool of open source/free software in the world he has my email address.

Love, Miguel.

MonoTouch is a commercial product based on Mono and is made up of the following components:

• MonoTouch.dll The C# binding to the iPhone native APIs (the foundation classes, Quartz, CoreAnimation, CoreLocation, MapKit, Addressbook, AudioToolbox, AVFoundation, StoreKit and OpenGL/OpenAL).
• Command Line SDK to compile C# code and other CIL language code to run on the iPhone simulator or an iPhone/iPod Touch device.
• Commercial license of Mono's runtime (to allow static linking of Mono's runtime engine with your code).
• MonoDevelop Add-in that streamlines the iPhone development and integrates with Interface Builder to create GUI applications.

The MonoTouch API is documented on the Mono site. The MonoTouch API is a combination of the core of .NET 3.5 and the iPhone APIs.

We have created some tutorials on how to use MonoTouch and you can read the design documentation on the MonoTouch framework.

Some History

Almost a year ago when we released Mono 2.0 for OSX, I asked the readers of this blog to fill a survey to help us understand where we should take Mono.

Many developers asked us to provide Mono for the iPhone.

A year ago, it was possible to use Mono's static compiler to compile ECMA 1.0 CIL bytecode for the iPhone. This is the technology that powered Unity3D's engine for the iPhone.

Users of Unity3D have published more than 200 applications on the AppStore.

We debated internally what exactly Mono for the iPhone would be. We considered doing a Windows.Forms port, to bring Compact Framework apps to the iPhone, but that would have required a complete new backend for Windows.Forms and would have required also a "theme" engine to make it look like the iPhone. We discarded this idea early on.

We decided instead to go with a native binding the iPhone APIs. It would not be a cross platform API and it would tie developers to the iPhone platform, but it would also mean that applications would look and feel native, and developers would get closer to the iPhone.

Creating a binding for the Objective-C APIs with .NET in the past has relied extensively on dynamic code generation, and this feature is not available on the iPhone (the kernel prevents JIT compilation from taking place). As we started doing the work to bind the low-level C APIs, Geoff started prototyping a new Objective-C/C# bridge that was specifically designed to work within the iPhone requirements.

By the time we had sorted out the foundation and the Objective-C bridge we had gained some fresh experience from binding the C++ PhyreEngine to .NET and we decided to create a new binding generator to simplify our life (I will blog about this new approach to binding creation in another post).

At this point, we started investing into supporting not only the device, but support the simulator. This would prove to be incredibly useful for quickly testing the code, without having to wait a long time to compile and deploy on the device.

The Developer Experience

At this point, we had enough to create mix-mode GUI applications (they were mostly Objective-C apps hosting Mono) and the pipeline was horrible: it involved using some 3 compilers, having 3 Mono checkouts and applying individual patches to all trees.

We were aware of how easy Unity had made things for their users, they had set the bar pretty high in terms of usability for us. Unity had some advantages, they could "debug" without deploying the code to the device, something that we could not really do ourselves.

We were still far from this.

We introduced a command that would isolate all of the complexities of creating simulator and ARM executables, the mtouch command.

With the mtouch command and the bindings complete, we started trying out the API by porting the Apple iPhone samples from Objective-C to C#. And in the process finding two things: C# 3.0 constructor initializers are a thing of beauty:

UIControl SliderControl ()
{
	var slider = new UISlider (new RectangleF (174f, 12f, 120f, 7f)){
		BackgroundColor = UIColor.Clear,
		MinValue = 0f,
		MaxValue = 100f,
		Continuous = true,
		Value = 50f,
		Tag = kViewTag
	};
	slider.ValueChanged += delegate {
		Console.WriteLine ("New value {0}", slider.Value);
	};
	return slider;
}
	

And also that the samples ported were half the size of the equivalent Objective-C programs.

As we were doing this work to iron out the kinks in the API design, Michael got started on designing the MonoDevelop support for the iPhone. This included the regular bits that you would expect like templates, building, running and deploying, but most importantly the Interface Builder integration.

Interface Builder produces an XML file that describes your UI, and it is able to generate some header files for you, but in general developers that want to refer to components in the UI and implement their backing store have to repeat the same stuff over and over. For example, controlling the contents of a label on the screen requires the developer to declare the same variable three times: 2 in the header file, and one in the Objective-C file (if you are lucky).

We took a different approach. We made it so that MonoDevelop would automatically generate a code-behind partial C# class for each Interface Builder file. This meant that to users the entire process would be transparent.

They would define outlets or messages, and those would just become part of their class. Intellisense and code completion would become available to them without any extra coding.

Microsoft today launched the CodePlex Foundation a non-profit organization to promote the open source collaboration between companies and open source communties, projects and individuals.

This is another step in the right direction for Microsoft. I have been working on open source software since 1992, and back then a world where open source played a major role was a dream to many of us. Microsoft adopting open source licenses, releasing some of their code under open source licenses and being a better community member was the stuff of fiction.

There are still many things that I would like to see Microsoft do, and many things that I believe Microsoft has to change to become a full member of the open source community, but it is encouraging to me to see Microsoft evolve. I hope that the CodePlex foundation will help us continue to build bridges between our communities.

I am glad that I was asked to be part of the board of directors of the foundation. And to work together with some great advisory board.

I hope that I can last more on this foundation than I lasted at the FSF, where I was removed by RMS after refusing to be an active part of the campaign to rename Linux as GNU/Linux.

MonoDevelop goes cross platform.

Since the beginning of time, man has yearned to get a cross platform .NET IDE. Homer's Odyssey described one man's effort to achieve such a thing. And it was not until today, September 9th of 2009 that the world can test out such a tool.

With this release MonoDevelop leaves its cozy Linux nest and embarks on a wild adventure into the hearth of MacOS and Windows. The MonoDevelop team made this one of their major goals for this release: to turn our loved IDE into a cross platform IDE.

If you are curious about the details, check out the What is new in MonoDevelop 2.2 page.

MonoDevelop on Windows

We are not only bringing MonoDevelop to OSX and Windows as a plain GUI port, but we are also providing installers, deep operating system integration and support for native debugging on each platform.

MonoDevelop on MacOS X

In addition to becoming a cross platform IDE, there are many new features in MonoDevelop.

For instance, MonoDevelop can be used to develop ASP.NET MVC applications on OSX and Linux and Silverlight applications on OSX and Linux.

Debugger

MonoDevelop now has integrated debugger support. Not only it is able to debug Mono applications, it also can work as a frontend to GDB to debug native applications.

In addition, on Linux it is possible to debug ASP.NET pages.

New Add-ins

New exciting add-ins: ASP.NET MVC, Silverlight and iPhone (for use with MonoTouch).

Policies

A common problem that we face as open source developers is that not every project uses the same coding style. Different teams use different coding conventions. MonoDevelop now supports policies to describe how files should be edited and what defaults should be used in each:

Editor Improvements

My favorite new feature is Dynamic Abbrev (Alt-/) a feature that we brought from Emacs and that fills me with joy. That being said, for the non-Emacs lovers there are plenty of features that you asked for, and that we implemented:

• Extensive refactoring support. And I mean, it is extensive.
• Code templates.
• On the fly formatting.
• Acronym Matching in Code Completion
• XML Documentation Shown in Code Completion
• VI mode for those users hooked up on VI commands, they can now use those within MonoDevelop.

Another pretty cool feature is the code generation support that is triggered with Alt-Insert. When you press Alt-insert it will popup a context sensitive dialog box that offers a few options of code that could be generated at this point: ToString methods, Equals/GetHashCode methods all based on existing fields and properties.

Why go Cross Platform?

Going cross platform means that developers will have the same tool across all of the operating systems they use: Windows, Mac and Linux.

.NET developers that have been enchanted by OSX will be able to continue developing software with their favorite programming languages while enjoying OSX and will be able to go back and forth between Windows, OSX and Linux as needed. This also means that they can work with developers in other platforms, regardless of the personal choices of other team members.

As many of you know, the number of contributors to a project is linked to the number of users of that project. By expanding our market presence from Linux, we expect to get contributions, fixes, improvements, bug reports, code and add-ins from developers in other platforms.

We intend to make MonoDevelop the Eclipse of the .NET community. Just like Eclipse became the foundation for Java development, we hope that MonoDevelop will become the foundation for .NET development, and hopefully for much more than that.

A multi-system IDE

We are not religious when it comes to supporting other programming languages [1]. We want to embrace not only .NET-based projects like Gtk#, Silverlight, ASP.NET, Boo, C#, F#, Visual Basic and Windows.Forms. We are also embracing other developer platforms like Python, C/C++, Vala, and we want to expand our presence to work with the Flash, PHP, Ruby, Rails, Flex and any other communities that need a cross platform IDE.

[1] we are just religious about the fact that C# is a better programming language to build an IDE than Java is.

Thanks!

This release could not have been possible without the endless nights and the collaborations of our contributors and all of the end users that reported bugs and gave us feedback.