While it won't be formally announced until Monday, reports of the Mono project are starting to leak to the press. The question of how to respond to Microsoft's .NET initiative is a sensitive one, with many complex and subtle issues. Thus, this cat predicts a spate of uninformed articles in the technical press, followed by lots of flamage on the message boards.
The goal of the Mono project, briefly, is to create an independent, free software implementation of the various languages, protocols, and interfaces making up the .NET platform. Much to Microsoft's credit, they seem to be taking the open standards process quite seriously. Draft ECMA standards for C# and other components are available on a page Microsoft has set up for the task. Additionally, they've generally played well in the process of defining SOAP. There's already a free implementation: soup.
The C# language itself looks quite appealing. It may well present a sweet tradeoff between language richness and complexity, well suited to writing applications. Certainly, Microsoft seems to have learned from the mistakes made with Java. The progress of the free software Java community has been disappointing to me. Perhaps C# will be considerably more vital.
Finally, it is very much in the spirit of free software to interoperate. Many projects, including Wine, Samba, netatalk, wv, various filesystems for Linux, are dedicated to this goal. It is often in the interest of authors of proprietary vendors to put up barriers so that various combinations of software won't work. A great strength of free software is the absence of any such incentive.
That said, there are definitely concerns about implementing the .NET protocols. It will certainly help Microsoft, and certainly help the adoption of .NET itself. Whether that's a good thing or not is a very good question. Certainly, there are aspects of the broader .NET vision that are scary from a security and privacy standpoint, especially Passport.
As the title of this essay suggests, I believe we face the danger of a monoculture. While monocultures clearly have some advantages (or they wouldn't exist), they also have many weaknesses. They are much more vulnerable to attack, for one, and also close off many avenues for innovation that would be present in a more diverse environment. Today, free software is one of the few forces actively resisting such a monoculture (Apple being one of the others).
Whether free implementation of .NET will aid or impede such a monoculture is a very good question. Having more diversity within the .NET world will be helpful. Further, it will probably help with the implementation of gateways between .NET and other free projects.
There has definitely been concern expressed about Mono drawing attention away from other worthy free software projects. However, this cat is not very worried. Matching up free software talent to worthy projects has always been a chaotic process. It's possible that some projects will feel the loss as people's attention is captured by the shiny new thing, but the chance of the free software community moving en bloc to .NET is about as much as, say, all Perl hackers suddenly switching to Python (or vice versa!).
As the excellent editorial in Linux Weekly News points out, it is disappointing that we don't have a large-scale system architecture comparable in scope to .NET. "The community needs to act here," but what is the best way to do so? Mono provides one potential answer.
Micro$quash certainly seems to be playing nice with C# and SOAP. They are working the standards committees properly, and apparently interact well with competing implementations.
However, it appears that they view the recent court of appeals decision as "The gloves are off!!!" While I don't think anyone can know that they are going to pull the embrace and extend trick with SOAP/C#/.NET, there is certainly no reason to think they couldn't. It would be a waste of a lot of time to spend all energy working in the .NET world, only to find it doesn't work.
I'm not saying that .NET work is bad, but it needs to be thought out.
The problem with the "Object Web" (which has been predicted for years, but never happened) is that it requires some centralized way to list all the services available, and it requires actual useful services in the first place. Micro$quash is in the proper position for these requirements. In general, the only true client these days is IE on Windows. We can talk about Mozilla, but 92% of the world's client machines are Windows. If these clients automatically have convenient access to .NET services, they will choose to use them. They will not even regard security or quality as an issue.
As soon as .NET is an integral part of the Windows application landscape (essential to using Office, say), it becomes easy for Microsoft to extend it to the proprietary things that make life hard for non-Windows users. Windows extensions to your website are a neat idea when you know that 92% of users can view them. Windows extensions to your .NET services are an even neater idea if you know it results in sales. The browser wars proved that proprietary extensions may not defeat an existing competitor, but that doesn't mean they can't make an effective lock-in against new competitors.
These are, of course, merely cautionary thoughts. I don't know what the future may hold. But watch WMP kill RealVideo. And think.
What is the plan for CLI and C# ? Will you guys implement a virtual machine?
It would be advantageous to "tie" the Free Software implementation to existing Free Software infrastructure, like Apache, GNU/Linux, gcc, Kaffe, gtk, GNOME (Bonobo), CORBA, KDE, etc. It helps distinguishing the Free implementation from the Microsoft implementation and helps negating the possible "help" to Microsoft to make .NET popular. Basically this takes away the 100% control Microsoft would enjoy over .NET. and makes the Free Software community a player in steering .NET's future. Or at least, hopefully....
Embrace, extend, and extinguish Microsoft. That's the plan.
The Software Wars are really heating up...
As much as I hate "solution providers," there is something to be said for a well-architected, cohesive platform. .NET and J2EE both seem to be addressing this. Both are development platforms that let you add network services pretty easily, and the APIs are extremely consistent. I don't think that can really be said of any existing development environment in the GNU world. I think that Ximian is smart in trying to develop either a clone, or an answer to .NET for free software.
A number of people probably find something like this against the UNIX ideal - small applications that do 1 thing really well. But I would argue that things like component systems and extensive consistent APIs are in the same vein. These are just architectural building blocks to make powerful applications. In UNIX-land, the wheel is reinvented too often. We're too interested in rolling our own. I don't even want to know how many different projects have implemented their own string classes, or other relatively basic data structures. This is just a waste of time.
That all said, I would like to voice some concern over just implementing the .NET apis as they stand. I don't want to use Passport or go through Microsoft for any transactions or data storage. I frankly don't trust them. I *am* interested in that odd "net services" term though. I'd like my configuration data backed up somewhere, so no matter where I log in, my apps are all set up as I like. I'd like to be able to seemlessly back up some of my files. My calendar, todo list, and other work-related things should be available from wherever I am. Little things like that would be nice to have. I can come up with any number of other small things that would be cool. And I'm willing to pay a reasonable amount for such services. But, I do want my applications to be useful when I'm not connected to the network. And I want to know that my data is secure, wherever it is stored. And I don't want to pay a Microsoft tax.
The free software community should work to develop a "services" API that is vendor-neutral. I should be able to search for the best vendor for each service, and not have to recompile my app when I switch vendors. We can get real competition there. The Eazel folks were working on "Reef" towards the end there - it seemed like a really promising project. I would love to see something like that take off as a part of a larger application development framework. We even have readily-available systems that we can use as free "service providers" - Themes.org could be Reef-ified, and theme preview/update systems can be built into theme switchers. There are a number of digital libraries that have a wealth of information and resources for us to take advantage of, and make readily available within applications. How cool would it be if your word processor let you do a quick quote cross- reference? Little things like that would be very useful, and very feasible to program with the proper framework in place.
The idea of providing an infrastructure that makes it easier to interface disperate languages such as Smalltalk and Haskell is in my opinion a step in the right direction. Currently making these languages talk together in a portable way across platforms is very difficult... which makes most people standardize on C or some subset of C++. If Microsoft delivers on this one, they'll have made a real contribution to software development.
Secondly, supporting .NET is an opportunity for Linux to suceed in the embedded IA market: currently plugins are Windows executables, which could only possibly be run on Linux using Wine (or CodeWeaver's cross-over embedded Wine product). If I understand it correctly, .NET is essentially the output of the compiler before it emits assembly. The "JIT compiler" thus performs the last compilation phase, allowing cross-platform portability, but ensuring C-like speeds. I see no reason to do all this work, if you are going to tie the result to the x86 Windows platform. Instead I expect plugins will be written for .NET so that Microsoft can gain a presence on all the handheld devices, internet fridges, whatever of the future than run whatever OS and .NET. In the mean time Linux can become the "whatever OS".
Let me preface this message by saying I'm not terribly interested in web services, however in .Net it seems partially what they want to do is make clients go beyond what is possible with the hyper text transfer protocol(HTTP).
This seems good to me, except why would we, the free software community, suddenly adopt Microsoft's protocols and start implementing the very Microsoft-centric infrustructure needed to support them?
In long run it seems better to stick to the standards and protocols specified by the World Wide Web Consortium. They seem fairly independent, and much more trustworthy than the Microsoft Corporation.
If you're going to start another project related to .NET, please call is Poly. I can hardly wait until we have Mono and Poly around. Oh, no, wait...
My personal viewpoint is that we need one good high level programming language on linux in order to develop good (i.e. featurefull and not buggy) applications in an easier way. Java could have been that except that it's 1/ not standardized 2/ there is no good free softare implementation (Kaffe never reached taht goal and the compiler with gcc don't include enough of the virtual machine) 3/ linking with native libraries is an horrible problem. C++ is for the moment the best option it seems, python seems nice too but I don't think people can implement an office suite in Python realistically. C++ has its own problems, and is not garbage collected which seems to become a requirement for the new generations of programmers (sigh ...).
The C# language looks nice, it seems to solve the main technical problem I have with Java, and I hope the standardisation at ECMA will complete in a reasonable time-frame. Then that standard is an useful piece to implement, assuming that there isn't too many holes in the specification (Bruce Perens seems to have raised a problem there). Similary, the SOAP specification is being standardized at W3C (check the XML Protocol activity page if you are interested).
All this is nice and great because this means this common ground for developping applications and services gets standardized, so a lot of things comes along (stability, documentation, books, mindshare, examples ...) and I think implementing such a framework makes sense because it will reduce the cost of entry in the Linux programming world for the masses of programmers from the other side. it may also provide a good language and framework for the application develpper community in general.
However developping the framework up to a stable and reusable stage will take time. I expect that it won't divert application developpers from their current focus (it should not, that's a very diffferent effort than writing application and requires very different skills), we should also not bet too much on this because well this may very well not succeed for various reasons. I also hope that the implementation will stay strictly within the scope of 1/ the pieces standardized 2/ the glue needed to allow easy access to the existing libraries from the new framework. Trying to engage in a race with Microsoft developers pool on possible extension is not a productive use of free software programer time and would at the end provide a justification for such extensions, we should not go there. Hence the title "Standards, only standards"
Good luck Miguel, but it will be a long road.
Daniel
microsoft has a policy - as we all know from the leaked halloween documents - of pushing technology to a level where it is difficult to pick up and follow in their footsteps. the typically quoted lag-time is two years.
now, what happens when microsoft develops some technology, off we go, yes, been there, done that... now what? okay, well, we have some well-established services, we know they work, oh, yes: i know, we'll do Something New, and, well, we can use our existing services, right?
so, here's the timelines of where i think (these may be wrong) microsoft has 'stacked up' their house of cards, along with estimates on number of man-years to completion:
stack all of that up, and you have about 50 or more man-years of development over a _full decade and more_ to play catch-up.
so _why_ am i telling you all this? [begin flame mode]
well, we have a load of whining, bitching open source developers, who in their arrogance say things like, *begin-nasal-voice* 'eeeew, i don't liiike that microsoft stuufff, it's realllyy bloaated and it's not open souuurce and i don't have to deeeuuw iiiiit it's all teeew cooomplicated for liitttle meeeee' *end-nasal-voice*.
in other words, they can't _deal_ with layered complexity. they like to live in their little world, where everything is nice, and clean, and simple, and open, and limited to about 100,000 LOC *max*.
[end flame mode]
yes: i _know_ that most open source developers are working in their own time, give me that much credit: i _do_ understand the realities.
it's just that people bitching on the one hand about microsoft and how they can't get a word in edgeways into their technology but at the same time aren't prepared to pull their fingers out and actually catch up just pisses me off.
the number of dedicated open source developers on large complex projects of greater than 100,000 LOC is actually quite small (less than 10? apache, linux-kernel, worldforge, samba, samba tng, perl, python, freedce) hence the main reason why the TNG architecture advocates subdividing into small, clean projects that are manageable by individuals, to give them a fast feed-back loop to worthwhile achievement, to keep them actually interested and part of something big.
to the point, then: my concern is that all you wonderful open source developers out there, who don't like to get your hands dirty by distastefully following someone else's footsteps (not that you can, any more, because of microsoft's latest SDK licensing trickery, except under a BSD license), are going to get left behind.
AGAIN.
make the decision NOW. are you going to doggedly keep up with microsoft's initiatives, or are you going to wait for a decade, when it will be approximately one hundred to five hundred man-years too LATE.
choice is yours, guys.
I wonder what people feel are the advantages of C# over Java, as a language? There is the easy C/C++ binding, which I agree is a great thing. But what else?
One thing that would be great if it could get worked on in the free software community is a common runtime for Python, Perl, Java, C# and such. This doesn't neccessarily have to be done in a ".NET compatibility" mode, but if CLR and the .NET IL are found open and good specifications, why not.
lkcl -
While I appreciate your points overall (and generally agree), you vastly underestimate the number of large Free Software projects. A quick list (and there are many more):
I seriously question the wisdom of naming a product Mono. I just don't think of banner ads saying "go get mono now!!!" to be terribly compelling. Especially among the college crowd.
hiya samth, oh darn, yes of course i knew about openoffice, mozilla and emacs, but not the others. good call. still, that brings the total up to... maybe fifty? one hundred tops? ... [oh, there's AFS as well, of course].
i read the references from the article. very interesting to note that, well, basically, they say the same thing as i did but in a nicer, more friendly, more readership-acceptable manner but with no real-world example.
me, i seem to be turning into some sort of open source Nemesis / Devil's Advocate...
in order not to have people fall foul of the unbelievable arrogant licensing terms of passport.com (see older advogato article pointing to the TOS agreement) implementing passport's functionality - a clean-room, wire-compatible implementation - is more than a simple good idea, it's almost essential.
More information can be found in
http://iwsun4.infoworld.com/articles/hn/xml/01/07/06/010706 hnximiandotnet.xml
Interestingly GNOME Mono will enter the compiler and virtual machine business. That has been traditionally outside the scope of a desktop project.
atai: it's Ximian Mono, not GNOME Mono. The GNOME Project hasn't even been presented with the idea yet (and in any case this is a much broader-scope initiative than GNOME, I don't think GNOME Mono makes any more sense than GNOME C++ or GNOME X Window System).
But I hope it will fall under the umbralla of GNOME or GNU. It shall get more support that way. Hopefully it also gets the support of Red Hat, so there can be cooperation on the virtual machine technology (as you (HP) proposed similar things before)
The GNU Project has announced two initiatives to replace Microsoft .NET. They are dotGNU and GNU Mono. GNU Mono is the Mono we are talking about here. The FSF press release is here.
It is not clear how dotGNU and Mono will cooperate. Probably it is ok to compete, since the two developer communities (GNU Telephony and GNOME) are disjoint, at least at this time.
However, the GNOME Project may be extended too thin. How much resource does Xiaman have, to put into GNOME and Mono at the same time?
<person>atai</person: My impression was that there wasn't really competition between dotGNU and Mono - they are attacking different areas of the problem space. Mono is focusing on the development environment, whereas dotGNU is working on the actual web services end - like a passport.com clone (but it seems like it will be distributed), and other web infrastructure issues. So they are pretty much 2 prongs on the same pitchfork.
As for GNOME spreading itself too thin, this isn't really a GNOME project. Ximian is working on it, and some GNOME developers are probably going to be involved, but I think it is more of a GNU effort. Also, I think Ximian hopes that Mono will be something of the future for a nice integrated development platform for GNOME, so it isn't really a waste of effort - it is more of an investment in the future of the platform (as Miguel sees it).
The press released linked from my previous message appears to be incorrect. The correct one, obviously, can be found on GNU's web page.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank