Strong opinions, weakly held

Tag: open source (page 2 of 2)

Links from March 23rd

There are a whole ton of links in the backlog today.

Programmers should study a little economics

So the big news on Twitter among Ruby programmers is that the “hashrocket” operator has been deprecated. For those of you who aren’t Ruby programmers, here’s what that means. If you want to declare a hash literal in Ruby, right now you can do it like this:

my_hash = { :foo => "1", :bar => "2" }

Also, many methods accept hash literals as an argument, so you can do things like this:

url_for :controller => 'posts', :action => 'index'

At some point, that notation will be unsupported, and hash literals will have to declared in a different way.

When the version of Ruby is released that doesn’t support this notation, it will be incompatible with a massive amount of Ruby code. My advice to the Ruby developers would be not to do it. I don’t know what the rationale is for removing it, but the result is going to be lots and lots of servers that are simply never upgraded to that version of Ruby.

They should take a lesson from the PHP people. The migration from PHP 4 to PHP 5 has taken forever as a result of much smaller incompatibilities than this one.

Economics tells us that we have to be careful about the incentives that result from our actions. Removing the hashrocket operator creates a strong incentive to leave the Ruby upgrade path.

Update: Sometimes rumors on Twitter are just rumors on Twitter. I don’t see any mention of deprecating the => operator in the Ruby Subversion repository.

jQuery is awesome

I’ve been convinced for some time that jQuery is the best JavaScript library around. What I am coming to realize is that it’s also one of the best-run open source projects around as well. jQuery 1.3 (released today) has a new selector engine, a key component of any modern JavaScript library. To encourage other projects to adopt their selector engine, the jQuery project has turned it over to the Dojo Foundation, which currently manages the Dojo Toolkit, a jQuery competitor:

More importantly, though, we’re taking a big leap with Sizzle: We’re releasing it as a completely standalone project to be collaborated upon by many library creators and developers. We saw an opportunity to give something back to not just the jQuery community but to the JavaScript development community as a whole; and at the same time be able to collaborate with developers of other libraries on a single, unified, selector engine. We feel that there’s too much competition and not enough collaboration occurring and so we put our coud out on the line as a good first step towards working together.

As a sign of good faith and willingness to collaborate, we’ve turned over Sizzle to the Dojo Foundation (an excellent non-profit well suited for this project, not to be confused with the Dojo Toolkit). We wanted a common meeting ground where all developers would be able to work together and under which there would be a clear long-term copyright holder.

Truth in advertising

You have to appreciate the honesty of MySQL’s Michael Widenius:

Don’t expect that all critical bugs that you may have encountered in 5.0 to be fixed in 5.1. Even if we have fixed a big majority of the bugs from 5.0 some really critical ones still haven’t been addressed.

Matt Raible on picking a framework

Matt Raible (now a full time employee of LinkedIn) posts about how he came to work there as a result of a consulting project where he helped them evaluate open source web frameworks against a framework that they had built in-house. In the end, he recommended enhancing their internal framework to include some of the best attributes of the open source frameworks, and he was hired to build a team to do just that. Anyway, the post contains a lot of wisdom about making these kinds of technology decisions.

Mozilla is 10 years old

The Mozilla Foundation is celebrating the ten year anniversary of AOL’s having released the Netscape Navigator source code and creating the foundation. Here’s the original press release. One thing I remember is that Slashdot broke the story of AOL releasing the code before it was announced — it was the first really big story Slashdot broke. (In fact, I think I learned of the existence of Slashdot when someone pointed me to the story there.)

Not long after the code was released, there was a big argument about whether Mozilla should dump the Netscape 4 HTML rendering engine and use a new, modern, standards compliant engine called NGLayout, or whether they should just get a release out the door built on the existing code. Back in October of 1998, I wrote a scathing piece insulting the Web Standards Project for lobbying the Mozilla folks to move to NGLayout, which I’ve quoted in full below. (This was in my pre-blog days when I was more an essayist.) The Mozilla Foundation rewarded me for defending them so ardently by announcing that they were adopting NGLayout just a month later.

“I Want My NGLayout!”

October 5, 1998

As regular Outraged! readers already know, this writer is generally dissatisfied with the so-called standards process in the computer industry. Standards which are written before working code is created are more often than not doomed to failure, standing instead as filthy monuments to the capriciousness and excess energy of companies with time and money to burn.

One particular showpiece of the standards process is the current state of HTML, as implemented by the world’s two most popular browsers, Netscape and Internet Explorer. They both comply to varying degrees with the relevant standards (CSS1, CSS2, and DOM to the buzzword savvy), but neither browser maker has shown much initiative in the race for 100% standards compliance. This indicates two things; one, that writing browsers that comply with standards isn’t a high priority, and two, that it isn’t particularly easy (if implementing CSS and DOM were easy, both browsers would support them).

Anyway, some disgruntled Web developers have banded together to cajole Microsoft and Netscape into providing full standards compliance in their Web browsers, in order to further the Web as a platform for deploying applications, and to make the job of designing nice Web sites easier and less expensive. Anyone who has attempted to use the latest features in the Web browsers (generally mashed together under the misnomer DHTML) can attest to the fact that this is a worthy effort; the current state of standards compliance basically dictates that everything must be written twice (once for each browser).

Unfortunately, the members of the Web Standards Project, as this nascent group is called, have decided that their first axe to grind is with Netscape over which “rendering engine” will be included with version 5.0 of its browser. As most everyone who hasn’t been in a deep sleep for most of 1998 knows, Netscape released the source code to its browser back on March 31. Since then, even though Netscape has retained the prime caretaking role over the code, the browser has been open to public input, contributions, and scrutiny.

Thus, the public has gotten a rare inside look at the guts of the development process of an incredibly complex, popular application. Not long after the Mozilla project got underway, Netscape released the source code to NGLayout (which was, at the time, called Raptor). NGLayout is Netscape’s next generation rendering engine; it will provide tighter standards compliance and better performance than the current rendering engine, which is known as Mariner. Unfortunately, it is also significantly further from completion than Mariner, and hasn’t been integrated with the rest of the browser. Today, you can download a rough build of NGLayout which runs in a skeleton window and renders HTML extremely quickly during the brief period of time before it crashes.

Under ordinary circumstances, the public wouldn’t even know that NGLayout existed, and certainly wouldn’t know where its level of completion stands as compared to the Mariner engine, which is undergoing incremental improvements for the first public release of Mozilla. But, now that it’s part of the Mozilla project, people are free to view and toy with the source code, and compare it to what’s currently out there.

The Web Standards Project (WaSP) has started a petition to urge Netscape to forget about Mariner (the current rendering engine), and focus all of its energies on NGLayout, which is going to be much better than Mariner when it is completed. While this seems like a good idea, and I have no doubt that the WaSP means well, this effort betrays a baffling lack of understanding of the way the open source development model works, and poor choice of tactics.

First, let me talk about the sheer inanity of the very concept of the Internet petition. Perhaps, at one time, the online petition was a fine way to demonstrate that there was a groundswell of support behind an issue, but I firmly believe that day has passed. There are petitions for everything on the Internet; covering everything from television shows that get cancelled to the lack of a particular game for the Macintosh. News of various petitions spreads like wildfire, and since the cost of filling out a petition is nothing, people fill out petitions campaigning for issues that they scarcely care about. Unfortunately, because the level of effort required to circulate a petition online is so low, the petitions get no respect. Decision makers just aren’t interested in reading a report saying that 150,000 people want the latest version of QuickBooks to be ported to the Macintosh without knowing how many of them are willing to put their money where their mouth is.

The fact that Mozilla is an open source project only further dooms the WaSP petition to irrelevance. Even if the signatories of the petition have money to spend, it doesn’t matter, because Mozilla is totally and completely free. The blessing and the curse of the open source movement is that the areas of development are driven by the aims of the people who actually work on the projects. Mozilla will support Apple’s ColorSync because people at Apple felt it was worthwhile to contribute that code, not because somebody signed a petition saying they should do it.

The galling thing is that if the WaSP wants better standards support in Mozilla, they should be working to contribute to the Mozilla project directly, or to find some friends who can. The reason Mariner is slated to be part of Mozilla is that NGLayout doesn’t look like it will be ready in time to meet the project’s timetable. Does it really make sense to hold up the release of the first public version of Mozilla in order to appease a few puling Web developers?

Jeffery Zeldman, one of the leading members of the WaSP urges Netscape to “do the right thing,” but I’m forced to wonder if he even really knows what that is. What he and the other members of the WaSP seem to be saying is, “do the right thing for us.” Dan Shafer, pundit at large for CNet’s Builder.com, lays down an ultimatum, “Netscape must not ship a 5.0 browser without NGLayout.” He further urges them to pull out all the stops and commit its entire engineering resource to this effort.

What he, and the other folks behind this petition, fail to realize is that they are part of Netscape’s engineering resource. The success or failure of Mozilla depends on the Internet community at large as much as it does on Netscape. If they, or others, want Mozilla to have a particular feature, or look a certain way, or run on a certain platform, then they’re as empowered as anyone at Netscape to make it happen.

The source code is out there. The rest is up to you.

Newer posts

© 2022 rc3.org

Theme by Anders NorenUp ↑