Passport will be heavily demanded once it starts to get popular.
Free Software developers should concentrate on software that end users are likely to demand. While it is definitely hard to compete with Microsoft on their own turf, there are Free Software projects that do it successfully (most notably Samba). If Free Software developers aren't building the software that the end users want then how in the world are they ever going to grow the Free Software userbase?
Passport is a pretty cool idea, except for the fact that it is centralized on Microsoft servers. If a competing product were produced that allowed for a distributed authentication system then it would almost certainly give Microsoft a run for their money. After all, who wants to be locked into Microsoft's pay schedule when there is a choice.
We'll have to see how this plays out, but shying away from building competition to a service that we know is likely to be popular with end users is not the way to build popular software packages.
Nobody's saying the Samba project was a bad idea. But it would have been a better use of time overall if a better protocol than SMB had been developed in an open manner so that everyone could write equally-workable implementations.
Yes, and it would be nice if Microsoft simply released.NET under the GPL as well, but that's not going to happen.
Like it or not, Microsoft controls the desktop, and they will continue to use that leverage to control what technologies are viable on the server. SMB works because it is available on every Microsoft client ever. That means that when the Free Software hackers figure out how to impersonate a Microsoft SMB server we magically gain compatibility with the entire world. This is hard, but it isn't nearly as hard as Microsoft's job of trying to find ways to extend the protocol that don't break backwards compatibility. Once something like Samba exists it basically ties Microsoft's hands. They want desperately to make incompatible changes to the protocol, but they know that if they break any existing applications or clients that their customers might very well get tired of the game and simply switch to Samba.
Which means that Mono has a golden window of opportunity here. If a useful version of Mono can be developed right now, while Microsoft is still trying to win developers to the.NET cause, it could grab a significant marketshare (especially on the server where Linux has serious traction). Microsoft can't make incompatible changes this early in the game, or they will scare everyone away, and if Mono was actually useable, then it's existence would serve as a deterrent to Microsoft trying to shaft their customers down the road. After all, as long as there is an alternative to their technology Microsoft has to listen to their customers.
SMB may be crap, but the existence of Samba has opened up the market for Linux file servers. Nowadays most large organizations are using Samba, and even quite a few small organizations have some sort of commodity server running a version of Samba.
Samba is clearly a case where it was a worthwhile effort to reverse engineer a closed protocol. SMB clients are so ubiquitous that it makes sense to try and figure out how to talk to them.
.NET should be even easier to reverse engineer. After all, the parts that Ximian is working on duplicating are all soon to be ECMA standards with plenty of documentation. Besides, all of the RPCs are done via SOAP which is basically nothing more than spitting plain text XML out of port 80. Microsoft is going to have a hard time fiddling SOAP so that it's clients still work and Mono clients don't. Especially since even non-guru hackers like myself will be able to open up the RPC packets in the text editor of their choice.
Remember, the desktop controls the server, not the other way around. Servers can be changed out over a long weekend by any halfway decent sysadmin. Desktops require bargaining with end users who will give up their familiar tools over their dead bodies. SMB became the file transfer protocol of the LAN because it was "good enough" and it was on every single Microsoft client..NET is soon going to be on every single client as well, and it is cool enough that it will get used. IBM and crew will make sure that we can create.NET compatible services under Linux (they are nearly done now) because they want to continue to sell servers. But unless there is a.NET compatible client Linux will slide even further into the Internet ghetto than it already is. Pretty soon only the hardest of hard core Pro-Linux sites will function 100% on Linux boxes.
The web is one area where Perl actually stands out as an excellent choice for a development language. Perl has an excellent set of modules for dealing with web content, XML, and Databases, when combined with mod_perl it performs very well, and web development is all about shuffling text. Perl is a well respected web development language, and for good reason, Perl simply works.
However, Perl's rivals (particularly Python) is also no slouch when it comes to web development, and IMHO it is much more useful for developing non-web applications like GUI front ends. It sounds to me like Larry Wall is hard at work making Perl more like Python because he realizes that this is the case. If he can pull it off then that is a win for Perl Monks everywhere. If not, Perl still rocks.
The reason that Larry is working on making Perl more like Python or Ruby is because many of his users are migrating to Python or Ruby.
I still use Perl for one off scripts and general data munging, but that's basically because I never bothered to learn sh, awk, and sed. In my opinion Perl is the best glue language ever. However, for anything more substantial than this I use Python, and from what I have seen that is becoming more and more the case.
Perl has a tremendous head start as a scripting language, but Larry's target audience now wants more from their scripting language than lightning fast text manipulation. Entire applications are being written in scripting languages these days, and Perl simply doesn't have the tools to make this sort of thing easy to do.
If you happen to have an exciting new idea, and you want to create an Open Source version of it, the easiest way to do this is to a) set up a website, and b) start putting code there.
Let's say I had an idea for a fabulous new piece of software, but I didn't have clue one as how to create it (very unlikely in my opinion). Under your system I would have to round up a bunch of developers interested in building the software, and a group of investors and money larege enough to make competing for the cash prizes worth the developers while. Oh, I also have to get these groups of people to agree on a license that would be compatible with their needs but still open enough so that I would have access to the software for my needs when they were done.
Want some eternal life and world peace with that order? Good Luck sorting that mess out.
On the other hand Linux, Emacs, Sendmail, the Gimp, Perl, Python, Apache, etc. all exist today without any such process. People simply started sharing code because the project was too big to do by themselves, and they were too poor to pay for the commercial alternatives (or no such alternative existed). In groups, however, these small time developers could afford to tackle these large projects. None of these projects were started to make money. And had money been the prime motivator then the source code to the project would not have been released. It's far easier to simply sell commercial licenses.
The next generation of Free Software will come into being the same way the previous generation did. Someone will release the source code to their software because it is in their best interest to do so. Either they will have based their software on existing Free Software (to save time and money in development), or they will do it in the hopes of receiving developmental help. In both of these cases the question isn't raising the money to do the development work, but instead it is about lowering the cost of development work so that it is affordable to the people who need the software.
How is this easier or more functional than simply hiring a contractor to make the changes that you would like to see made? And why should a company pay money so that it can vote when instead it can pay money and hire a contractor to add features. Especially since you can sit down with your contractor and sign a legally binding contract.
Wouldn't it be easier to simply hire the contractors that are actually doing the work? It seems to me that the infrastructure that would go into making these sorts of bonds possible would be a lot more expensive than simply hiring a lawyer to write up a standard contract with the developers (or their company).
Heck, if you actually hired the developers and brought them in house you could even decide which parts of the software in question became Free Software. That might be important if you had important business intelligence you were interested in coding into the application that you didn't want your competitors to have. This would be perfectly legal under the GPL. Your customer would receive a copy of the source with their copy of the modified binaries fulfilling the requirements of the GPL and then neither you or the customer would distribute binaries with the proprietary bits (guaranteeing that you needn't distribute the code you didn't want to share).
With bonds and several investors this sort of deal wouldn't be possible.
And that's not even the most obvious of its failings. The most obvious failing is that companies that don't participate in the bond will probably also receive access to the product. What exactly, then, is the incentive to pay?
Free Software developers currently share code for various reasons. One reason seen in Mozilla, OpenOffice, eSpeak, etc. is that the sponsoring company wants a product to become a standard. The company then hopes to leverage their expertise to sell hardware, support, or other goods and services. These projects generally don't need to worry about outside financing as the the organization sponsoring the project has sufficient resources to carry the bulk of development out itself.
The other reason that Free Software developers share code is because it allows small time developers with limited resources the ability to tackle large projects by pooling their talents. The fact of the matter is that if you have enough money to pay for all the coding to be done in house, and you plan on paying your bills by selling software (and not some other good or service) then you are probably better off keeping the code private.
How many would invest knowing that it was likely that the software would be released as Free Software at the end of the project whether you paid or not. Why not simply let your competitors pay for development, and you could simply scoop up the project when it was finished.
You could probably even hire the original developer to install it for you (he would be looking for a new job).
This type of system would actually work much better for closed source development. But we already know how to finance those sorts of companies. Basically the whole point of Free Software development is that it requires less working capital, and allows you to spread development costs over several interested parties. If you are going to develop software in a closed source commercial type of setting (ie, cathedral style) why not simply fund your R&D in a more traditional manner.
It seems to me that there are currently at least 4.5 million (more or less) schemes designed to make Free Software development "profitable." Now, I am certainly not opposed to making money, but I fail to see how the current system of Free Software development is broken. It seems to me that when I sit down at my Debian GNU/Linux box I have plenty of good software available to me. In fact, the advance in the state of the art for Free Software has been so amazing in the last 7 or 8 years that commercial software houses are finally realizing that they have to adopt some Free Software techniques in order to remain competitive. Nearly every major commercial software vendor has sponsored some type of Free Software project. And Microsoft is clearly borrowing ideas from the Free Software community with their "Shared Source" initiative.
If you really are interested in making money writing free software here is the trick. Don't spend a big fat pile of money going to trade shows, buying fancy cars, and purchasing expensive office space in Silicon Valley. Instead start by doing contract work for small companies and make sure your contract has a provision that allows you to keep the copyrights for your work. Then turn around and use that same source in your next contract. Now take that working software and release some (or all) of it on the Internet, and start to market it. Chances are good that your source will be of interest to a fellow developer with a similar problem, and with a little marketing you might even get some patches containing new features (which you can then sell to your existing customers).
Cygnus made money like this for years. With many business type packages the service and support contract is the main revenue source anyhow. You won't make Microsoft type money, but you probably wouldn't make Microsoft type money with a closed source product either.
There are plenty of software packages that small businesses pay tens of thousands of dollars for that are literally overgrown Access Databases. Competing with these packages on price and features is not particularly difficult (considering the wide array of inexpensive useful tools and existing source code), and more importantly it isn't particularly expensive to finance this type of software. In fact, that's one of Free Software's biggest advantages. Free Software development requires substantially less working capital, and the expense can be shared among interested developers.
Thanks for clearing that up Malcontent. It sounds like Microsoft's version of.NET is simply more of the same. I wouldn't know, as I don't actually do much work on Windows.
I suppose I was responding more on the "hype" of.NET than on the reality. The idea of having a unified platform that would allow the mixing of components from a wide array of languages and that came "out of the box" with a powerful and easy to use RPC mechanism really is a development Shangrila. Hopefully that is what the folks at Ximian are working on with their Mono implementation. If not, then what exactly is the point. As has been pointed out in numerous posts Java already answers the platform issues. The only benefit of.NET was that supposedly it allowed the programmer to use the language of his or her choice instead of always requiring Java.
If.NET ends up like you say (and I have read enough of your posts to believe what you say) then it will be of little use. The world needs a Microsoft only Java replacement like it needs a hole in the ozone layer. In particular I had heard that VBers would get to start from scratch with VB.NET. They should be used to that by now. You would think that eventually people would learn that following Microsoft's lead guarantees expensive rewrites of your applications every couple of years.
In the meantime I am fairly happy using a combination of Python and generic C for my cross platform development. I have even played a bit with using XML-RPC. It's certainly easier to use than Corba, and it seems flexible enough. I never have like Java much. The platform bits are cool, but I don't particularly like the language. That's why the idea of.NET appealed to me.
Yes, Java can do most of what.NET will do. However, with.NET it all comes in one attractive package all ready to go. And it will support more than one language.
And as you point out in your post.NET will even talk to legacy Java code via SOAP.
Do you see where I am going with this? I am not a Microsoft supporter. In fact, I would much rather see Java win over.NET, but the reliance on Java as a platform on the Java language is problematic. Java programmers might wish that the entire world would simply switch to their language, but it isn't going to happen..NET makes the choice of development language a much less political deal. With.NET you can choose the correct language for the job, instead of simply using Java for everything.
That's what makes.NET so great. It's got all of the advantages of the Java platform, without the downside of only being able to use the Java language.
Of course, in the real world.NET is not even close to being cross platform, which is a serious problem, but that's only because Microsoft isn't interested in building cross platform tools. They want you to use their operating system. It's also worth noting that Java isn't nearly as cross platform as Sun would have you believe. While it is true that they finally have a decent Linux implementation, the BSDs are still waiting.
A Free Software implementation of.NET would solve that problem nicely, and it would quickly become a very cool development platform.
In short: Java Platform Good! Java Language Mostly Good, but not as cool as my favorite language . If your favorite language happens to be Java, then it's no wonder that you can't see the benefits of.NET.
If the MCA bus would have come out earlier we would all be using Apples today.
Early Macintoshes were much nicer machines than their clunky DOS based IBM PC clones, but they were much more expensive because they used proprietary hardware. The reason that IBM designed MCA was because they thought that it would give them total control over the PC market and dry up business for the clones (who wouldn't be able to use IBM's proprietary bus). This would have raised prices for PCs (by lowering the amount of competition). If IBM would have succeeded IBM PCs would have lost the one incentive that they had over Macintoshes, lower price.
Technologically MCA was much better than ISA, but it wasn't open (and therefore cheap), and so it lost.
In the computer business it is all about being "good enough" at the lowest price. That's why Microsoft is making inroads against proprietary big-iron Unixes and Mainframes, and why Linux, in turn is making inroads against Microsoft.
Java compiles to Java Bytecode, which is interpreted by the JVM. C# (and VB.Net, Perl.Net, et al), compile to IDL, which is interpreted by the CRE (Common Runtime Engine). As others have said in the past, there is nothing stopping someone from making a compiler spit out Java bytecode for a non-Java language.
Yes, this is true (theoretically). It's even true in a practical sense for Jython. However, Microsoft has taken the extra step and made it automatic. Not only did they specifically design their runtime environment to support multiple languages, but they are actually including working support for various languages. They actually went out and did it.
If Sun would stop raving about Java as a language and promote Java as a platform it might quickly become competive with.NET in this area. For now, however, Java is a one language platform, and that is all Sun wants it to be.
I actually was aware of some of these projects (and I even mentioned Jython, which is far and away the most useful).
Jython proves that the JVM can be used as a multi-language, cross-platform, tool, but only if you define "cross-platform" to exclude the BSDs (or is their finally a recent JVM available for these platforms), and if you define "multi-language" as Java, most of Python, and experimental support for Perl in CVS that mostly works using GNU's Kawa. Comparing that to the lineup that Microsoft has for.NET is utterly laughable.
The fact of the matter is that Microsoft has sorted out some of the thornier issues with Java. On paper Microsoft has designed a development environment with some pretty compelling features. They will support, in a sane unified way, a number of different languages, and will allow components to call other components reguardless of what language they are written in. On top of that they are adding a powerful easy to use RPC system based on SOAP. This will make writing distributed systems much easier than using Corba and its IDL language. Right now, without any real world tests Java still holds the edge because it is currently working in the real world. But if Microsoft's.NET doesn't absolutely suck performance and stability wise Java is in for a hard road ahead.
Now, I am not a Microsoft fan. I am writing this from Mozilla 0.9.2 on My Debian GNU/Linux workstation, but even I can see that Microsoft has really come up with something in their.NET architecture. Java has the potential to do what Microsoft has envisioned for.NET, but Sun's emphasis on Java as a language and their refusal to simply open up Java is hurting them.
I don't know whether or not Mono is a good idea. There are all sorts of projects trying to reimplement Java under a free license, and none of them are particularly useful. Despite what Microsoft says about the Free Software community being good at "chasing tail lights" I have yet to see a Free Software reverse engineering effort that has been wildly successful. As an example the Free Software hackers worked on Lesstif forever without having something that actually worked. When they went to create an alternative (GTK) it didn't take them very long at all to come up with something that was better than Motif in nearly every respect.
Microsoft is just trumpeting their anti-GPL FUD. They know that this is a hot button issue for many managers an dos they bring it up whether it applies or not. They realize that it doesn't matter what the truth actually is if they can get people to believe their lie.
The fact of the matter is that Microsoft has trumpeted C# and.NET as open since before they were even vaporware. Microsoft new that submitting the specification to ECMA would guarantee that alternative versions could be created. Including implementations covered by the GPL. In fact, they have publicly lambasted Sun for not doing the same thing with Java.
On the other hand, Microsoft currently has a software license that disallows the use of Free Software tools. So it is still possible that Microsoft will be able to throw up legal obstacles to Mono. But my guess is that it is all smoke and mirrors.
Short term, however, I am still doing my work using Python and XML-RPC, just in case.
The problem with Sun's Java as a platform strategy is two fold. First of all, as you point out in your post, Java is not a *free* language. The standard is completely controlled by Sun, and there are no free (as in free speech) implementations that have all of the features of Sun's version.
The second problem is slightly larger. Java is a nifty platform, but unfortunately it requires that you do all of your programming in Java the language. Microsoft's.NET allows you to pick and choose your language, and it has (supposedly, I haven't actually checked) included support for a wide array of languages. Java, as a platform, really only supports two languages: Java and Jython (and Jython isn't officially supported).
Of course, if you are a Java programmer you probably think that this is well and good, but most programmers are not Java programmers.
Actually, that was my point. Microsoft pretends that they need to centralize these services so that the passport ids are unique, but in reality that particular problem is something that has already been solved. Email addresses are a prime example of this. They are all unique, and yet there is no central authority.
Basically Passport is a service that aggregates information and associates it with a unique key. If Microsoft shared their protocols and schema with service providers then anyone could be a hailstorm host. Microsoft is intentionally designing the system so that it constitute a chokepoint. Microsoft has learned from experience that controlling the computing crossroads is a lucrative job, and so they designed their system not for technical excellence, but rather because it would allow them to eventually name their terms for use of their system.
In other words, Microsoft is simply creating a chokepoint for information. Seriously, Internet users generally already have a unique identifier (or two), an email address is the perfect example. Microsoft is going to add one more, and then they are going to create a list of "other" pieces of information that you can aggregate with this unique key.
However, instead of turning Passport into a service that can be distributed Microsoft has specifically created a centralized service that puts them in control. At first this control won't be too big a deal. They will probably charge those passport users that want more than the "basic" services. The idea, however, will be to get as many people to sign up as possible. Both websites and web users will be able to use this service basically free of charge.
Once Microsoft has all of the users, and a good portion of the websites using passport, they will start to reel the suckers in. Businesses will find that they can't access Passport without paying a fee. Users will find that they can't access their data without paying a fee etc. Microsoft will have succeeded in building a toll bridge for the information super highway.
Of course, it doesn't have to be this way. Since Microsoft isn't double checking any of this user entered information it could just as easily reside on a server at my ISP (or my authentication provider of choice). Email addresses have already shown a way to allow for unique addresses without namespace collisions. ISPs could similarly hand out "identity keys" (that may or may not be the users actual email address). Each ISP could then function as a mini-Passport site, all that would be necessary is an agreed upon protocol and a set of XML schemas (you could borrow Microsoft's work).
Of course Microsoft promises that they aren't going to use the information for marketing purposes. It is even possible that they will live up to their part of the bargain. They almost certainly will use access to this information in the same way that they use their current control of the desktop. ASPs and web sites that don't follow the Microsoft line will find that they are unable to use the Passport service. This might not seem like a big deal now, but if Passport becomes what Microsoft hopes it will be the de-facto method of sharing personal information and authentication for the web. If Microsoft were control how you share your information and how you authenticate then they could dictate terms in much the same way they bully the hardware OEMs currently.
It's not a privacy issue. That's a complete red herring. Of course Microsoft is going to say that they aren't interested in mining Passport for marketing data. They probably even mean it. Microsoft wants control and Hailstorm will give it to them in spades.
The beauty of the Agenda is that when you ssh into it, it is basically like sshing into a Linux box. Complete with Linuxy tools, and a Linux development environment. The Psion might be a cool machine, but there is almost certainly a learning curve that must be tackled before you can develop for it. With the Agenda Linux developers already have all the knowledge they need to be productive immediately (well, you might want to learn FLTK, but how long is that likely to take). With the Psion being effectively dead, there is little point in learning their development tools and API, but even if the Psion weren't a dead end there is more to the idea of handheld Linux machines than "bragging rights."
I think that Linux is cool running on my desktop computer. The idea of being able to carry around a Linux box wherever I go sounds incredibly useful, and the idea of developing PDA applications without having to learn another possibly dead end API is equally appealing. So, while I am sure that your Psion is a nifty gizmo, I am not interested in it.
1. Bill Gates laughing himself silly over how publicly this latest open source food fight is being waged.
I couldn't agree more. Of course, if I was part of MySQL AB I would go to war too if someone was misusing my source and my trademark name. What else can they do?
On the other hand, poisoning the MySQL well might be NuSphere's intention. They do, after all sell another commercial database (Progress), the beast even runs on Linux.
2. Hundreds, maybe thousands, of corporate decision makers crossing MySQL off their list of products to investigate. With Red Hat about to release their version of PostgreSQL, this is incredibly bad timing, to say the least.
This might be a good thing:). I am a very happy PostgreSQL user, and I personally think that it should get more use, it rocks. More importantly it stacks up in features against commercial databases like SQL Server. Comparing MySQL to Microsoft's SQL Server is ridiculous, but PostgreSQL compares relatively well (and the price is right).
That's a fairly razor thin argument. If they just wanted to create a "community" site dedicated to the advancement of the MySQL database why didn't they simply fork the MySQL codebase (legal) and rename their project to something else (legal). The Open Source developers working on the Phoenix database did precisely that when they split off from Interbase.
NuSphere didn't write the MySQL software, and they haven't released any MySQL related source code. In fact, they are currently in violation of the GPL. Yet all of a sudden they should be the ones creating the "community" site?
What dope are you smoking, and why aren't you sharing with the rest of us?
Re:mySQL.com and mySQL.org......
on
MySQL & Nusphere
·
· Score: 2
You are correct in that this is all an argument over a name (well, there is the separate GPL violation thing as well). However, it shouldn't surprise you that the MySQL AB folks would be upset over how NuSphere is using their name. I imagine that I showed up at your job, with a drivers license that said Chanc Gorkon and "borrowed" your paycheck you would be pretty upset too.
The MySQL AB folks have done all the development work for MySQL. They wrote the entire piece of software, and now the Nusphere folks are trying to hijack not only the project, but MySQL's good name as well.
As for the "little OSS project" NuSphere, the folks that acquired the mysql.org web site, is actually a fairly large commercial database company. They even have another database that they sell (called Progress). Compared to NuSphere MySQL AB is tiny. In other words you have gotten your prejudices confused. MySQL AB is the tiny Free Software company. They have currently written every piece of MySQL. NuSphere, on the other hand, is the "corporation." They have release absolutely no code, but instead are illegally bundling a statically linked library with the GPLed MySQL binary (which is clearly a violation of the GPL).
This doesn't have anything to do with elitism. It has everything to do with a commercial software company trying to muscle the creators of MySQL right out of the business that they created with their own work. If NuSphere wants to build their own "enhanced" version of MySQL, they should 1) change the name (as it violates MySQL AB's trademark), and 2) release their extensions under the GPL as MySQL's license requires.
Bruce's response is nothing more than the cold hard truth. Just because you want to make a living selling software, doesn't mean that you can make a living selling software. It doesn't even really matter whether you use a commercial or a Free Software license. In fact, in some cases you have a better chance of making money under a Free Software license than a commercial softwrae license.
A case in point is database software. No one would even consider using MySQL if it was just another proprietary database system. There are plenty of commercial products that are much better. But since it is Free Software, people use it. In fact, enough people use it so that the author and a fair amount of other hackers have a full time job selling service and support.
The fact of the matter is that there are a whole pile of software niches that it is basically impossible to enter as a commercial software vendor. Try making a living selling a proprietary web server or web browser (if you aren't Microsoft, of course). Commercial software firms fail all of the time.
Now, if you happen to have a successful business selling commercial software right now, then you would be a fool to release your software under a Free Software license. Unless, of course, you are started to see increased pressure from a Free Software product that does essentially the same thing, in which case you might have to rethink your strategy.
Slashdot Mirror
Free Software developers should concentrate on software that end users are likely to demand. While it is definitely hard to compete with Microsoft on their own turf, there are Free Software projects that do it successfully (most notably Samba). If Free Software developers aren't building the software that the end users want then how in the world are they ever going to grow the Free Software userbase?
Passport is a pretty cool idea, except for the fact that it is centralized on Microsoft servers. If a competing product were produced that allowed for a distributed authentication system then it would almost certainly give Microsoft a run for their money. After all, who wants to be locked into Microsoft's pay schedule when there is a choice.
We'll have to see how this plays out, but shying away from building competition to a service that we know is likely to be popular with end users is not the way to build popular software packages.
Yes, and it would be nice if Microsoft simply released .NET under the GPL as well, but that's not going to happen.
Like it or not, Microsoft controls the desktop, and they will continue to use that leverage to control what technologies are viable on the server. SMB works because it is available on every Microsoft client ever. That means that when the Free Software hackers figure out how to impersonate a Microsoft SMB server we magically gain compatibility with the entire world. This is hard, but it isn't nearly as hard as Microsoft's job of trying to find ways to extend the protocol that don't break backwards compatibility. Once something like Samba exists it basically ties Microsoft's hands. They want desperately to make incompatible changes to the protocol, but they know that if they break any existing applications or clients that their customers might very well get tired of the game and simply switch to Samba.
Which means that Mono has a golden window of opportunity here. If a useful version of Mono can be developed right now, while Microsoft is still trying to win developers to the .NET cause, it could grab a significant marketshare (especially on the server where Linux has serious traction). Microsoft can't make incompatible changes this early in the game, or they will scare everyone away, and if Mono was actually useable, then it's existence would serve as a deterrent to Microsoft trying to shaft their customers down the road. After all, as long as there is an alternative to their technology Microsoft has to listen to their customers.
SMB may be crap, but the existence of Samba has opened up the market for Linux file servers. Nowadays most large organizations are using Samba, and even quite a few small organizations have some sort of commodity server running a version of Samba.
Samba is clearly a case where it was a worthwhile effort to reverse engineer a closed protocol. SMB clients are so ubiquitous that it makes sense to try and figure out how to talk to them.
.NET should be even easier to reverse engineer. After all, the parts that Ximian is working on duplicating are all soon to be ECMA standards with plenty of documentation. Besides, all of the RPCs are done via SOAP which is basically nothing more than spitting plain text XML out of port 80. Microsoft is going to have a hard time fiddling SOAP so that it's clients still work and Mono clients don't. Especially since even non-guru hackers like myself will be able to open up the RPC packets in the text editor of their choice.
Remember, the desktop controls the server, not the other way around. Servers can be changed out over a long weekend by any halfway decent sysadmin. Desktops require bargaining with end users who will give up their familiar tools over their dead bodies. SMB became the file transfer protocol of the LAN because it was "good enough" and it was on every single Microsoft client. .NET is soon going to be on every single client as well, and it is cool enough that it will get used. IBM and crew will make sure that we can create .NET compatible services under Linux (they are nearly done now) because they want to continue to sell servers. But unless there is a .NET compatible client Linux will slide even further into the Internet ghetto than it already is. Pretty soon only the hardest of hard core Pro-Linux sites will function 100% on Linux boxes.
It will be interesting to see how it plays out.
The web is one area where Perl actually stands out as an excellent choice for a development language. Perl has an excellent set of modules for dealing with web content, XML, and Databases, when combined with mod_perl it performs very well, and web development is all about shuffling text. Perl is a well respected web development language, and for good reason, Perl simply works.
However, Perl's rivals (particularly Python) is also no slouch when it comes to web development, and IMHO it is much more useful for developing non-web applications like GUI front ends. It sounds to me like Larry Wall is hard at work making Perl more like Python because he realizes that this is the case. If he can pull it off then that is a win for Perl Monks everywhere. If not, Perl still rocks.
The reason that Larry is working on making Perl more like Python or Ruby is because many of his users are migrating to Python or Ruby.
I still use Perl for one off scripts and general data munging, but that's basically because I never bothered to learn sh, awk, and sed. In my opinion Perl is the best glue language ever. However, for anything more substantial than this I use Python, and from what I have seen that is becoming more and more the case.
Perl has a tremendous head start as a scripting language, but Larry's target audience now wants more from their scripting language than lightning fast text manipulation. Entire applications are being written in scripting languages these days, and Perl simply doesn't have the tools to make this sort of thing easy to do.
If you happen to have an exciting new idea, and you want to create an Open Source version of it, the easiest way to do this is to a) set up a website, and b) start putting code there.
Let's say I had an idea for a fabulous new piece of software, but I didn't have clue one as how to create it (very unlikely in my opinion). Under your system I would have to round up a bunch of developers interested in building the software, and a group of investors and money larege enough to make competing for the cash prizes worth the developers while. Oh, I also have to get these groups of people to agree on a license that would be compatible with their needs but still open enough so that I would have access to the software for my needs when they were done.
Want some eternal life and world peace with that order? Good Luck sorting that mess out.
On the other hand Linux, Emacs, Sendmail, the Gimp, Perl, Python, Apache, etc. all exist today without any such process. People simply started sharing code because the project was too big to do by themselves, and they were too poor to pay for the commercial alternatives (or no such alternative existed). In groups, however, these small time developers could afford to tackle these large projects. None of these projects were started to make money. And had money been the prime motivator then the source code to the project would not have been released. It's far easier to simply sell commercial licenses.
The next generation of Free Software will come into being the same way the previous generation did. Someone will release the source code to their software because it is in their best interest to do so. Either they will have based their software on existing Free Software (to save time and money in development), or they will do it in the hopes of receiving developmental help. In both of these cases the question isn't raising the money to do the development work, but instead it is about lowering the cost of development work so that it is affordable to the people who need the software.
How is this easier or more functional than simply hiring a contractor to make the changes that you would like to see made? And why should a company pay money so that it can vote when instead it can pay money and hire a contractor to add features. Especially since you can sit down with your contractor and sign a legally binding contract.
Wouldn't it be easier to simply hire the contractors that are actually doing the work? It seems to me that the infrastructure that would go into making these sorts of bonds possible would be a lot more expensive than simply hiring a lawyer to write up a standard contract with the developers (or their company).
Heck, if you actually hired the developers and brought them in house you could even decide which parts of the software in question became Free Software. That might be important if you had important business intelligence you were interested in coding into the application that you didn't want your competitors to have. This would be perfectly legal under the GPL. Your customer would receive a copy of the source with their copy of the modified binaries fulfilling the requirements of the GPL and then neither you or the customer would distribute binaries with the proprietary bits (guaranteeing that you needn't distribute the code you didn't want to share).
With bonds and several investors this sort of deal wouldn't be possible.
And that's not even the most obvious of its failings. The most obvious failing is that companies that don't participate in the bond will probably also receive access to the product. What exactly, then, is the incentive to pay?
Free Software developers currently share code for various reasons. One reason seen in Mozilla, OpenOffice, eSpeak, etc. is that the sponsoring company wants a product to become a standard. The company then hopes to leverage their expertise to sell hardware, support, or other goods and services. These projects generally don't need to worry about outside financing as the the organization sponsoring the project has sufficient resources to carry the bulk of development out itself.
The other reason that Free Software developers share code is because it allows small time developers with limited resources the ability to tackle large projects by pooling their talents. The fact of the matter is that if you have enough money to pay for all the coding to be done in house, and you plan on paying your bills by selling software (and not some other good or service) then you are probably better off keeping the code private.
How many would invest knowing that it was likely that the software would be released as Free Software at the end of the project whether you paid or not. Why not simply let your competitors pay for development, and you could simply scoop up the project when it was finished.
You could probably even hire the original developer to install it for you (he would be looking for a new job).
This type of system would actually work much better for closed source development. But we already know how to finance those sorts of companies. Basically the whole point of Free Software development is that it requires less working capital, and allows you to spread development costs over several interested parties. If you are going to develop software in a closed source commercial type of setting (ie, cathedral style) why not simply fund your R&D in a more traditional manner.
It seems to me that there are currently at least 4.5 million (more or less) schemes designed to make Free Software development "profitable." Now, I am certainly not opposed to making money, but I fail to see how the current system of Free Software development is broken. It seems to me that when I sit down at my Debian GNU/Linux box I have plenty of good software available to me. In fact, the advance in the state of the art for Free Software has been so amazing in the last 7 or 8 years that commercial software houses are finally realizing that they have to adopt some Free Software techniques in order to remain competitive. Nearly every major commercial software vendor has sponsored some type of Free Software project. And Microsoft is clearly borrowing ideas from the Free Software community with their "Shared Source" initiative.
If you really are interested in making money writing free software here is the trick. Don't spend a big fat pile of money going to trade shows, buying fancy cars, and purchasing expensive office space in Silicon Valley. Instead start by doing contract work for small companies and make sure your contract has a provision that allows you to keep the copyrights for your work. Then turn around and use that same source in your next contract. Now take that working software and release some (or all) of it on the Internet, and start to market it. Chances are good that your source will be of interest to a fellow developer with a similar problem, and with a little marketing you might even get some patches containing new features (which you can then sell to your existing customers).
Cygnus made money like this for years. With many business type packages the service and support contract is the main revenue source anyhow. You won't make Microsoft type money, but you probably wouldn't make Microsoft type money with a closed source product either.
There are plenty of software packages that small businesses pay tens of thousands of dollars for that are literally overgrown Access Databases. Competing with these packages on price and features is not particularly difficult (considering the wide array of inexpensive useful tools and existing source code), and more importantly it isn't particularly expensive to finance this type of software. In fact, that's one of Free Software's biggest advantages. Free Software development requires substantially less working capital, and the expense can be shared among interested developers.
Thanks for clearing that up Malcontent. It sounds like Microsoft's version of .NET is simply more of the same. I wouldn't know, as I don't actually do much work on Windows.
I suppose I was responding more on the "hype" of .NET than on the reality. The idea of having a unified platform that would allow the mixing of components from a wide array of languages and that came "out of the box" with a powerful and easy to use RPC mechanism really is a development Shangrila. Hopefully that is what the folks at Ximian are working on with their Mono implementation. If not, then what exactly is the point. As has been pointed out in numerous posts Java already answers the platform issues. The only benefit of .NET was that supposedly it allowed the programmer to use the language of his or her choice instead of always requiring Java.
If .NET ends up like you say (and I have read enough of your posts to believe what you say) then it will be of little use. The world needs a Microsoft only Java replacement like it needs a hole in the ozone layer. In particular I had heard that VBers would get to start from scratch with VB.NET. They should be used to that by now. You would think that eventually people would learn that following Microsoft's lead guarantees expensive rewrites of your applications every couple of years.
In the meantime I am fairly happy using a combination of Python and generic C for my cross platform development. I have even played a bit with using XML-RPC. It's certainly easier to use than Corba, and it seems flexible enough. I never have like Java much. The platform bits are cool, but I don't particularly like the language. That's why the idea of .NET appealed to me.
Thanks for the info.
Do you mean to say that Python will not be part of .NET? Heck, all of a sudden it doesn't sound that nifty after all :).
Yes, Java can do most of what .NET will do. However, with .NET it all comes in one attractive package all ready to go. And it will support more than one language.
And as you point out in your post .NET will even talk to legacy Java code via SOAP.
Do you see where I am going with this? I am not a Microsoft supporter. In fact, I would much rather see Java win over .NET, but the reliance on Java as a platform on the Java language is problematic. Java programmers might wish that the entire world would simply switch to their language, but it isn't going to happen. .NET makes the choice of development language a much less political deal. With .NET you can choose the correct language for the job, instead of simply using Java for everything.
That's what makes .NET so great. It's got all of the advantages of the Java platform, without the downside of only being able to use the Java language.
Of course, in the real world .NET is not even close to being cross platform, which is a serious problem, but that's only because Microsoft isn't interested in building cross platform tools. They want you to use their operating system. It's also worth noting that Java isn't nearly as cross platform as Sun would have you believe. While it is true that they finally have a decent Linux implementation, the BSDs are still waiting.
A Free Software implementation of .NET would solve that problem nicely, and it would quickly become a very cool development platform.
In short: Java Platform Good! Java Language Mostly Good, but not as cool as my favorite language . If your favorite language happens to be Java, then it's no wonder that you can't see the benefits of .NET.
If the MCA bus would have come out earlier we would all be using Apples today.
Early Macintoshes were much nicer machines than their clunky DOS based IBM PC clones, but they were much more expensive because they used proprietary hardware. The reason that IBM designed MCA was because they thought that it would give them total control over the PC market and dry up business for the clones (who wouldn't be able to use IBM's proprietary bus). This would have raised prices for PCs (by lowering the amount of competition). If IBM would have succeeded IBM PCs would have lost the one incentive that they had over Macintoshes, lower price.
Technologically MCA was much better than ISA, but it wasn't open (and therefore cheap), and so it lost.
In the computer business it is all about being "good enough" at the lowest price. That's why Microsoft is making inroads against proprietary big-iron Unixes and Mainframes, and why Linux, in turn is making inroads against Microsoft.
I actually was aware of some of these projects (and I even mentioned Jython, which is far and away the most useful).
Jython proves that the JVM can be used as a multi-language, cross-platform, tool, but only if you define "cross-platform" to exclude the BSDs (or is their finally a recent JVM available for these platforms), and if you define "multi-language" as Java, most of Python, and experimental support for Perl in CVS that mostly works using GNU's Kawa. Comparing that to the lineup that Microsoft has for .NET is utterly laughable.
The fact of the matter is that Microsoft has sorted out some of the thornier issues with Java. On paper Microsoft has designed a development environment with some pretty compelling features. They will support, in a sane unified way, a number of different languages, and will allow components to call other components reguardless of what language they are written in. On top of that they are adding a powerful easy to use RPC system based on SOAP. This will make writing distributed systems much easier than using Corba and its IDL language. Right now, without any real world tests Java still holds the edge because it is currently working in the real world. But if Microsoft's .NET doesn't absolutely suck performance and stability wise Java is in for a hard road ahead.
Now, I am not a Microsoft fan. I am writing this from Mozilla 0.9.2 on My Debian GNU/Linux workstation, but even I can see that Microsoft has really come up with something in their .NET architecture. Java has the potential to do what Microsoft has envisioned for .NET, but Sun's emphasis on Java as a language and their refusal to simply open up Java is hurting them.
I don't know whether or not Mono is a good idea. There are all sorts of projects trying to reimplement Java under a free license, and none of them are particularly useful. Despite what Microsoft says about the Free Software community being good at "chasing tail lights" I have yet to see a Free Software reverse engineering effort that has been wildly successful. As an example the Free Software hackers worked on Lesstif forever without having something that actually worked. When they went to create an alternative (GTK) it didn't take them very long at all to come up with something that was better than Motif in nearly every respect.
It will be interesting to see what happens.
Microsoft is just trumpeting their anti-GPL FUD. They know that this is a hot button issue for many managers an dos they bring it up whether it applies or not. They realize that it doesn't matter what the truth actually is if they can get people to believe their lie.
The fact of the matter is that Microsoft has trumpeted C# and .NET as open since before they were even vaporware. Microsoft new that submitting the specification to ECMA would guarantee that alternative versions could be created. Including implementations covered by the GPL. In fact, they have publicly lambasted Sun for not doing the same thing with Java.
On the other hand, Microsoft currently has a software license that disallows the use of Free Software tools. So it is still possible that Microsoft will be able to throw up legal obstacles to Mono. But my guess is that it is all smoke and mirrors.
Short term, however, I am still doing my work using Python and XML-RPC, just in case.
The problem with Sun's Java as a platform strategy is two fold. First of all, as you point out in your post, Java is not a *free* language. The standard is completely controlled by Sun, and there are no free (as in free speech) implementations that have all of the features of Sun's version.
The second problem is slightly larger. Java is a nifty platform, but unfortunately it requires that you do all of your programming in Java the language. Microsoft's .NET allows you to pick and choose your language, and it has (supposedly, I haven't actually checked) included support for a wide array of languages. Java, as a platform, really only supports two languages: Java and Jython (and Jython isn't officially supported).
Of course, if you are a Java programmer you probably think that this is well and good, but most programmers are not Java programmers.
Actually, that was my point. Microsoft pretends that they need to centralize these services so that the passport ids are unique, but in reality that particular problem is something that has already been solved. Email addresses are a prime example of this. They are all unique, and yet there is no central authority.
Basically Passport is a service that aggregates information and associates it with a unique key. If Microsoft shared their protocols and schema with service providers then anyone could be a hailstorm host. Microsoft is intentionally designing the system so that it constitute a chokepoint. Microsoft has learned from experience that controlling the computing crossroads is a lucrative job, and so they designed their system not for technical excellence, but rather because it would allow them to eventually name their terms for use of their system.
In other words, Microsoft is simply creating a chokepoint for information. Seriously, Internet users generally already have a unique identifier (or two), an email address is the perfect example. Microsoft is going to add one more, and then they are going to create a list of "other" pieces of information that you can aggregate with this unique key.
However, instead of turning Passport into a service that can be distributed Microsoft has specifically created a centralized service that puts them in control. At first this control won't be too big a deal. They will probably charge those passport users that want more than the "basic" services. The idea, however, will be to get as many people to sign up as possible. Both websites and web users will be able to use this service basically free of charge.
Once Microsoft has all of the users, and a good portion of the websites using passport, they will start to reel the suckers in. Businesses will find that they can't access Passport without paying a fee. Users will find that they can't access their data without paying a fee etc. Microsoft will have succeeded in building a toll bridge for the information super highway.
Of course, it doesn't have to be this way. Since Microsoft isn't double checking any of this user entered information it could just as easily reside on a server at my ISP (or my authentication provider of choice). Email addresses have already shown a way to allow for unique addresses without namespace collisions. ISPs could similarly hand out "identity keys" (that may or may not be the users actual email address). Each ISP could then function as a mini-Passport site, all that would be necessary is an agreed upon protocol and a set of XML schemas (you could borrow Microsoft's work).
Of course Microsoft promises that they aren't going to use the information for marketing purposes. It is even possible that they will live up to their part of the bargain. They almost certainly will use access to this information in the same way that they use their current control of the desktop. ASPs and web sites that don't follow the Microsoft line will find that they are unable to use the Passport service. This might not seem like a big deal now, but if Passport becomes what Microsoft hopes it will be the de-facto method of sharing personal information and authentication for the web. If Microsoft were control how you share your information and how you authenticate then they could dictate terms in much the same way they bully the hardware OEMs currently.
It's not a privacy issue. That's a complete red herring. Of course Microsoft is going to say that they aren't interested in mining Passport for marketing data. They probably even mean it. Microsoft wants control and Hailstorm will give it to them in spades.
The beauty of the Agenda is that when you ssh into it, it is basically like sshing into a Linux box. Complete with Linuxy tools, and a Linux development environment. The Psion might be a cool machine, but there is almost certainly a learning curve that must be tackled before you can develop for it. With the Agenda Linux developers already have all the knowledge they need to be productive immediately (well, you might want to learn FLTK, but how long is that likely to take). With the Psion being effectively dead, there is little point in learning their development tools and API, but even if the Psion weren't a dead end there is more to the idea of handheld Linux machines than "bragging rights."
I think that Linux is cool running on my desktop computer. The idea of being able to carry around a Linux box wherever I go sounds incredibly useful, and the idea of developing PDA applications without having to learn another possibly dead end API is equally appealing. So, while I am sure that your Psion is a nifty gizmo, I am not interested in it.
I couldn't agree more. Of course, if I was part of MySQL AB I would go to war too if someone was misusing my source and my trademark name. What else can they do?
On the other hand, poisoning the MySQL well might be NuSphere's intention. They do, after all sell another commercial database (Progress), the beast even runs on Linux.
This might be a good thing :). I am a very happy PostgreSQL user, and I personally think that it should get more use, it rocks. More importantly it stacks up in features against commercial databases like SQL Server. Comparing MySQL to Microsoft's SQL Server is ridiculous, but PostgreSQL compares relatively well (and the price is right).
That's a fairly razor thin argument. If they just wanted to create a "community" site dedicated to the advancement of the MySQL database why didn't they simply fork the MySQL codebase (legal) and rename their project to something else (legal). The Open Source developers working on the Phoenix database did precisely that when they split off from Interbase.
NuSphere didn't write the MySQL software, and they haven't released any MySQL related source code. In fact, they are currently in violation of the GPL. Yet all of a sudden they should be the ones creating the "community" site?
What dope are you smoking, and why aren't you sharing with the rest of us?
You are correct in that this is all an argument over a name (well, there is the separate GPL violation thing as well). However, it shouldn't surprise you that the MySQL AB folks would be upset over how NuSphere is using their name. I imagine that I showed up at your job, with a drivers license that said Chanc Gorkon and "borrowed" your paycheck you would be pretty upset too.
The MySQL AB folks have done all the development work for MySQL. They wrote the entire piece of software, and now the Nusphere folks are trying to hijack not only the project, but MySQL's good name as well.
As for the "little OSS project" NuSphere, the folks that acquired the mysql.org web site, is actually a fairly large commercial database company. They even have another database that they sell (called Progress). Compared to NuSphere MySQL AB is tiny. In other words you have gotten your prejudices confused. MySQL AB is the tiny Free Software company. They have currently written every piece of MySQL. NuSphere, on the other hand, is the "corporation." They have release absolutely no code, but instead are illegally bundling a statically linked library with the GPLed MySQL binary (which is clearly a violation of the GPL).
This doesn't have anything to do with elitism. It has everything to do with a commercial software company trying to muscle the creators of MySQL right out of the business that they created with their own work. If NuSphere wants to build their own "enhanced" version of MySQL, they should 1) change the name (as it violates MySQL AB's trademark), and 2) release their extensions under the GPL as MySQL's license requires.
Bruce's response is nothing more than the cold hard truth. Just because you want to make a living selling software, doesn't mean that you can make a living selling software. It doesn't even really matter whether you use a commercial or a Free Software license. In fact, in some cases you have a better chance of making money under a Free Software license than a commercial softwrae license.
A case in point is database software. No one would even consider using MySQL if it was just another proprietary database system. There are plenty of commercial products that are much better. But since it is Free Software, people use it. In fact, enough people use it so that the author and a fair amount of other hackers have a full time job selling service and support.
The fact of the matter is that there are a whole pile of software niches that it is basically impossible to enter as a commercial software vendor. Try making a living selling a proprietary web server or web browser (if you aren't Microsoft, of course). Commercial software firms fail all of the time.
Now, if you happen to have a successful business selling commercial software right now, then you would be a fool to release your software under a Free Software license. Unless, of course, you are started to see increased pressure from a Free Software product that does essentially the same thing, in which case you might have to rethink your strategy.