Media Blog

It’s often said that you can’t kill an open source project.

The logic behind that maxim is that, as long as the source code is out there and freely available, someone will always show up to work on it, add to it, improve it. Indeed, that’s often the motivation behind releasing a project under an open source license.

One example is tr.im, the URL shortening service that shut down temporarily, but whose code is now open source. Another is OpenTape, a clone of the popular (and long gone) Muxtape music streaming app. Both released into the wild after the original developers became overwhelmed in the hopes that someone, anyone, would keep those projects alive. Whether or not the community actually forms around the release is irrelevant. The point is that it could.

But what do you do when an ostensibly open source project lacks support from its creators, and it becomes nearly impossible for the community to contribute? That’s the question programmer Jeff Atwood raised in a blog post Tuesday regarding John Gruber’s Markdown software.

Markdown is a text-to-HTML conversion tool which allows you to write web code using an easy-to-understand plain text format. Markdown text is then converted to structurally valid XHTML (or HTML). Markdown is used all over the web — it’s even understood by the content fields and comment forms within most popular blogging platforms, including WordPress and Movable Type. It’s been ported to Python, Ruby, PHP and other popular languages.

However, the original Perl script has remained largely unchanged since its release in 2004. In his post, Atwood takes Gruber to task for what Atwood calls “bad parenting,” an indictment of Markdown’s lack of bug fixes, updates and improvements.

Markdown was released under a BSD-style open source license, meaning the community can do pretty much whatever it likes with the code, so long as it respects the copyright notices and naming rules. Indeed, many ports of Markdown enjoy rather widespread support with numerous contributors and an aggregate community of active developers that the original Markdown lacks.

So while the various implementations of Markdown have regular fixes and updates, Gruber’s original code lacks such activity. What’s the difference? Atwood lays some of the blame at Gruber’s feet, citing what Atwood calls “passive-aggressive interaction with the community,” and quotes one of Gruber’s famously bristly e-mails (Gruber also writes the famously bristly blog, Daring Fireball) that shows the author discouraging changes. Single programmers rarely have that sort of influence. Which isn’t to say we disagree with Atwood’s assessment, just that Gruber is an extreme example and that it shouldn’t matter either way.

The bigger reason Markdown’s original Perl source doesn’t see bug fixes and maintenance releases seems to lie more its hosting situation than any other single problem Atwood raises. Without a way to easily contribute to your project, your potential users can’t improve your code.

The Perl source of Markdown is hosted as static download on Gruber’s website. Download the zip file and you’ve got a copy of Markdown you can use, modify and even redistribute according to the terms of the license.

But you don’t have a copy that’s easy to patch, and there’s no simple way to contribute back to the project, short of sending code directly to Gruber or to the support mailing list.

If the Markdown source code lived somewhere like GitHub, BitBucket, Google Code or any of the other free, open source code repository hosts, it would be infinitely easier for the community to contribute. To be fair, none of those sites existed when Markdown was released, but moving the code wouldn’t be hard — it’s a single archive with a license and readme text file.

A good project hosting service allows the community to contribute in ways that it just can’t when the code is static download.

Markdown isn’t alone in this respect. Django programmers were very excited to get their hands on the EveryBlock source code when it was finally released. However, since the EveryBlock code is, like Markdown, a static download, there isn’t and easy way for the community to contribute.

I have been using the EveryBlock code in a personal project for some time, and I’ve found at least a dozen bugs and several oversights and contradictions in the documentation. None of these stumbling blocks have stopped me from using the code, but it would be nice if I could contribute patches so others don’t also have to bang their heads against a wall for days on end trying to make the code work.

Yet a static hosting environment prevents that. There’s no easy way for me or anyone else to contribute to the code, update the documentation, add helpful links to a wiki, ask a question and get it answered. As a result, the whole community around the project suffers.

While it’s true I could put the codebase into a version control system and host my own copy, but not only does that feel wrong, it shouldn’t be necessary. The “you can always fork it” motto of open source has proved one of its least helpful tenets, leading to a proliferation of nearly identical code forks that are difficult to keep track of and work with.

We understand that the people who release open source code might not have time to work on it, or might simply lose interest in it over time, but that’s precisely why version control systems exist — to take the burden off the developer and let the contributions of the community pick up the slack in an open, organized manner.

Does a project still need an maintainer and someone to check in code, run tests, merge branches and so on? Sure, but that need not be a single person. Sizable open source projects — take Firefox for example — have dozens of committers and (in theory) no one person winds up feeling overwhelmed.

While in this particular case, it could be argued that Markdown doesn’t need further development. We use it everyday without issue. But the larger issue remains for other projects. Without active development, particularly bug fixes and maintenance releases, your open source project will rarely be successful.

Get your code into a decent version control system and make it easy for other users to do what you don’t have to — make your code better.

Photo by gerhard3/CC BY-NC-SA 2.0

See Also:

• Why Great Documentation Matters in Open Source
• Making Open Source Software More “Humane”
• Money, Not Spare Cycles, Drives Open Source

In many cases, web design begins in an image editor. A designer mocks something up in Photoshop (or some similar tool) and that design is eventually translated into HTML, CSS and JavaScript to create a live website.

But why do we work this way? It violates one of the fundamental tenets of good design, that design should follow content. It also means working with static documents. You submit a design to a client, the client likes it, but wants all the corners rounded. Have fun changing the corners in Photoshop — meanwhile, we’ll be adding a single line of CSS 3 to our live mock up.

In the final post to this year’s 24 Ways (see our coverage of other 24 Ways highlights), Meagan Fisher picks up what’s become a popular idea among many of web design’s most respected voices — that web designers should do their mockups in markup. That is, start with a live HTML and CSS page to create your designs.

Citing Photoshop’s shortcomings (not to mention expense) Fisher argues that tools like CSS 3 make writing — and more importantly updating — your mockups pure code just as fast, if not faster than the old Photoshop methods.

But there’s an added benefit Fisher touches on only briefly that bears further emphasis. Working with the code from the begin gives you chance to refactor, refine and improve it before production work ever starts.

Part of the reason lies in something designer Jeffrey Zeldman once posted to Twitter, “design in the absence of content is not design, it’s decoration.”

Starting with content — whether actual content, or simply the markup of the page — will force you to focus more on structure and making sure that your design fits the site from the ground up. In our experience this leads to slimmer, more semantic and easier to maintain code. As with writing in any language, the real process is not writing, but rewriting.

Even if you’re thinking that the world can pry your Photoshop markups out of your cold dead hands, give Fisher’s piece a read and, even better, try starting with code and see what happens. For some it might mean learning a new skill set, for others merely a shift in thinking. Regardless of whether you decide to switch to this method for good, we guarantee you’ll learn something new in the process.

See Also:

• Slick Web Design Gets Easier Thanks to CSS 3’s Transform Tools
• Design Patterns Solve Common Problems for Web’s Color Blind Users
• 10 Reasons to Politely Decline a Web Design Gig

It’s looking like Firefox 3.6 will miss its 2009 release goal, but the browser should arrive shortly after the start of the new year.

Firefox 3.6, currently in the final beta-release stages, will arrive in the first quarter of 2010, according to Mozilla Wiki. The slight delay is having a ripple effect, however, because future Firefox releases have been rescheduled as well. Mozilla has already pushed back its road map for both Firefox 3.7 and 4.0.

Once Firefox 3.6 is out the door, Firefox 3.7 (a fairly minor, incremental release) shouldn’t be too far behind, but we may have to wait until 2011 before the next major revision roles around. According to recent Mozilla meeting notes, Firefox 4.0 won’t come around until late 2010 or early 2011.

Despite the distant release dates, Mozilla is already hard at work on both Firefox 3.7 and 4.0. Judging by the current schedule, Firefox 3.7 will bring a few updates and possibly a slightly tweaked theme, but we’ll have to wait for 4.0 before we see any big changes and new features.

So what can you expect in Firefox 4.0 when it finally does arrive? Well, on the new features side of things, most of the answers lie in Mozilla Labs. JetPack, which was recently updated to version 0.7, is on the short list, as is Weave, a tool that syncs your Firefox installations across PCs. There’s even a chance that some elements of Ubiquity, the “command-line for the web,” might be integrated into the Firefox 4.0 Awesomebar.

Under the hood, Firefox 4.0 will feature an update to the Gecko rendering engine, with more HTML5 and CSS 3 support as well as speed improvements. One major goal is to reduce startup times by 25 percent.

But the biggest change will likely be the introduction of Electrolysis.

Electrolysis is the name of a Mozilla project that will split Firefox into multiple processes — one for the user interface, one for plug-ins and one for each tab. Similar functionality is already being seen in other clients, like Google Chrome. As in Chrome, a crash in a single tab will no longer be able to bring down the entire browser. Also, we can expect Electrolysis to make Firefox faster and more stable overall.

Firefox 4.0 will also likely feature a revamped look, possibly with a Chrome-like “tabs on top” user interface and a new, more feature-rich “home tab.” If you’d like to have a say in the look and feel of future Firefox release, check out the current Mozilla design challenge.

The addition of some Chrome-like features is no coincidence. Chrome’s arrival and its subsequent innovations have accelerated developments in the browser market. All the attention being paid to the younger browser puts Mozilla in danger of losing some of the user base it has worked so hard to capture over the last five years. The potential 2011 release date of Firefox 4.0 means that before that next big Firefox upgrade arrives, there will likely be a significant update to Google Chrome, a new version of Safari and possibly even a release of Internet Explorer 9.

See Also:

• Firefox 3.6 Nearly Complete, Fifth Beta Available Now
• Help Mozilla Improve Firefox’s New ‘Home’ Tab
• Mozilla’s JetPack Gets Ready to Take on Chrome Extensions
• Chrome Extensions Are Cool, But They Can’t Match Firefox

Mozilla Labs has announced the release of JetPack 0.7, an update to the new extensions framework for Firefox. It lets people use common web development tools like HTML, CSS and JavaScript to build browser add-ons.

Eventually, Mozilla plans to incorporate JetPack into a future Firefox release.  JetPack will most likely make its way into Firefox 3.7, which is due during summer 2010, or Firefox 4.0, due at the end of next year. At the moment, however, interested developers can grab the JetPack add-on that allows JetPack to work within current version of Firefox. Yes, for now JetPack is an add-on for installing add-ons.

JetPack is designed to make it easy for anyone with basic web developer skills to build Firefox extensions. While JetPack was innovative when Mozilla first announced it, Google has since added an extension system to its Chrome browser that works on the same principles as JetPack — using web-based tools like HTML and CSS. It would be nice if Chrome extensions would work with JetPack and vice versa, but differences between the underlying browsers make such compatibility unlikely.

Jetpack is still an experimental Labs project, but the 0.7 release sees JetPack moving closer to a stable project. Among the new features in this release are a unified first-run API that explains JetPack for new users, as well as some improvements to UI elements like status-bar widgets. The latest version also restores the debugging features available through Firebug.

There are also quite a few more working JetPack extensions available than last time we checked in with JetPack. the new extensions include a very handy tool for web developers: CSS Refresh can refresh the CSS on a page without reloading the whole page.

See Also:

• Jetpack Add-ons for Firefox Get Closer to Blast Off
• Firefox Add-ons Blast Off With ‘JetPack’
• Firefox 3.6 Nearly Complete, Fifth Beta Available Now

HTML5 is changing more than just websites — it’s changing the capabilities of browsers, as well. For example, a very clever use of the HTML5 canvas tag allows developer Heather Arthur’s Rainbow color scheme add-on for Firefox to extract a color palette from any webpage.

Because browser add-ons — those in Firefox and Chrome anyway — can be built using HTML, they too can take advantage of HTML5’s new tools. In Arthur’s case, that means using the HTML5 <canvas> element to load the entire web page and then use the getImageData function to extract colors.

Now it’s true there are already some add-ons (and desktop software) that can do this, but the shortcoming of most such add-ons is that they simply parse a page’s DOM and extract CSS styles to build a color palette. That works just fine — unless key page elements are actually images.

Arthur’s method of putting the page in a canvas tag and then parsing that means that all the colors are extract since the entire page effectively becomes a single, parsable image.

Of course behind the scenes there’s a good bit more going on. For example, the average web page in Arthur’s testing turned out the use somewhere in the neighborhood of 10,000 colors (think of all the shades actually present in a simple button gradient and you can see why the number is so high). Obviously, displaying that many colors would be useless. So, the Rainbow add-on uses a clustering algorithm to figure out the predominant shades on the page.

Running algorithms tends to slow down your browser, but thanks to HTML5’s Web Workers component, the Rainbow add-on is remarkably snappy. The comments on Arthur’s post also suggest some further optimizations which would make it even faster.

In the end, Arthur has created a plugin that makes an admirable replacement for some desktop software and, even better, showcases yet another possible way to use HTML5. If you’re interested in the actual add-on, head over to the download page. (The add-on is still listed as experimental, but it hasn’t caused any problems for me on Firefox 3.6b5).

See Also:

• How HTML 5 Is Already Changing the Web
• Turn Your Vector Art Into Canvas-based Animations With Opacity
• Google Throws Its Weight Behind HTML 5
• HTML 5 Support by Browser: Opera Continues to Lead the Pack

If you’ve got ideas about how the Firefox home page should look, now is the time to let Mozilla know. The company is hosting a new design challenge focusing on how to improve the home tab for Firefox 4.0.

The current plan for Firefox 4.0 is to move the home button down into the tab bar as a stand-alone and always-accessible tab. If that’s not to your liking, you’ll still be able to disable the home tab, or simply set it to a webpage as you might be doing now, but Mozilla is hoping to make the home tab a bit more powerful.

Pulling the “home” concept out of the menu bar and putting it in its own tab means that the page can access much more than just the web. It could, for example, filter through your history, add-ons, bookmarks — or pretty much anything stored in Firefox — and present that data in novel ways. What sorts of novel ways is the part that Mozilla is leaving up to you.

One thing worth mentioning, Mozilla isn’t looking for a My Yahoo or iGoogle-style start page. That use case is pretty well covered by iGoogle and its ilk. Instead Mozilla is interested in seeing what a browser start page can do with full access to your browser.

One example cited in the Mozilla Labs post is the About:Me extension, which shows you trends in your browsing habits — which sites you visit the most, where you spend most of your time and so on. As the Labs post says, “unlike mainstream portals like Yahoo and MSN, the locally hosted Firefox home tab can potentially offer users an experience that is innately personal.”

If you’ve got ideas and would like to participate in the challenge, create a short video explaining your idea(s). Be sure to include some sort of a mockup showing how your idea works — a wire frame, an image mockup, even a doodle on the back of a napkin. Once you’ve got your idea on video, upload it somewhere on the web and submit your entry using the design challenge submission form.

More details can be found on the Mozilla Winter ‘09 Design Challenge site. The deadline for submissions is February 14th, 2010. Winners, both “people’s choice” and those picked by Mozilla, will be announced in March 2010.

See Also:

• Mozilla Design Challenge: Reinvent Tabbed Browsing
• Mozilla Considers Copying Pieces of Chrome for Next Firefox
• Mozilla Mulls Design Makeover for Firefox 3.7

Typekit, a web service that helps designers use elaborate typefaces in their web projects, has announced an easy way to use custom fonts on WordPress.com blogs. That means your WordPress.com hosted blogs can now take advantage of Typekit’s font library in just a few clicks.

Typekit is like a YouTube for fonts. Browse through Typekit’s library of available fonts, pick one you like and cut and paste some code into your site. As we noted when we first looked at Typekit earlier this year, the service is one of the easiest ways for web designers to use creative fonts without sacrificing web standards or violating font licenses.

With the new WordPress.com features, you don’t even need to know HTML or mess with any code to take advantage of Typekit.

To use the new Typekit features, just log in to your WordPress.com dashboard and click on the Appearance menu in the left-hand navigation menu. On the Appearance page you’ll find a new option, “Typekit Fonts,” with a place to add your Kit ID.

To get your Kit ID, you’ll need to create an account at Typekit.com and select the free option. From there, you can paste over the code and chose from any of Typekit’s fonts.

Not using WordPress.com? No problem, there are already two plugins that make it easy to integrate Typekit into a self-hosted WordPress blog. If you’re on another blogging platform or custom site you can still use Typekit — see our earlier hands-on review of Typekit for details on how to use Typekit on your site.

See Also:

• Review: Typekit Delivers Custom Web Fonts to the Masses
• Typekit Hopes to Become the YouTube of Fonts
• JavaScript Offers Type Designers Better Choices Than Flash
• The Future of Web Fonts Looking Brighter

Opera has pushed out a pre-alpha build of the next version of its flagship desktop web browser. For Opera 10.5, as the next version will be known, the focus is on speed, and while this pre-alpha release is a long way from done, the speed boost is already noticeable.

This pre-alpha release is currently only available for Windows and Mac OS X users. Opera says a Linux version will be released soon. If you’d like to test out Opera 10.5, download links can be found at the bottom of the Opera Labs announcement page.

Much of Opera 10.5’s speed improvements come from the revamped JavaScript engine, known as Carakan, which Opera claims is up to seven times faster than the engine in the current shipping version, Opera 10. It’s worth noting that the Mac version is not nearly as far along as the Windows release, so Mac users may not notice a dramatic speed boost in this early release.

Also new under the hood is support for CSS3 transitions and transforms, which means that the cool CSS 3 transform tricks we told you about last week will work in this version of Opera (note that you’ll need to add the Opera flag to your CSS code, for example, -o-transition-property).

The pre-alpha release of Opera 10.5 also features a new graphics engine that can take advantage of hardware acceleration (when it’s available) to render SVG graphics. Given the possibility of very complex graphics thanks to HTML5’s canvas tag, we expect to see more emphasis on graphics engine in the coming year (think of hardware-accelerated graphics as a sequel to the JavaScript engine contests of recent months).

Opera is also one of the last browsers to jump on the private-browsing-mode bandwagon, but it is finally here in this release.

While the speed boosts in Opera 10.5 are noticeable, particularly on JavaScript-intensive sites and web apps, Opera 10.5 is very much a work in progress and lacks some very basic features — like printing in the Mac version. Also missing is support for Opera’s Unite web server tools.

As you would expect from the pre-alpha designation Opera 10.5 is also somewhat unstable, but if you’d like to test out the latest release, head over to the Opera Labs page and grab a copy.

See Also:

• Opera 10 Arrives: Turbo, New Tabs and a Fresh Coat of Paint
• Faster, Sleeker Opera 10 Is Built for Better Web Apps
• Opera Unite Puts a Web Server in Your Web Browser

Firefox has finally achieved one of its main goals, surpassing Internet Explorer as the most popular web browser.

This latest shift is illustrated by a new batch of browser share stats from analytics firm StatCounter, which is making the rounds on tech news blogs Tuesday.

There is, however, one big catch to StatCounter’s numbers — to arrive at the conclusion that Firefox is bigger than IE, you have to break down both Firefox and Internet Explorer’s share into separate version numbers.

Firefox’s popularity among web evangelists sometimes leads to overly-optimistic press, and StatCounter’s latest numbers are no exception. Which isn’t to say that StatCounter’s numbers are wrong, merely that, as Mark Twain said, “there are three kinds of lies: lies, damned lies, and statistics.”

StatCounter’s data shows that Firefox 3.5 had 21.93 percent market share at the end of last week, compared with 21.2 percent for IE 7 and 20.33 percent for IE 8. That’s certainly good news of Mozilla, but if you ignore the versioning, IE still wins with some 55 percent of the web, while Firefox can claim around 32 percent.

The fact that all the browsers need to be split by version number for Firefox to come out ahead obviously means that, in the real world, IE is still winning the browser wars.

The good news, from a web developer’s perspective is that IE is losing market share overall. Adjust the slider on StatCounter’s graph to look at the last year and you’ll find that IE’s combined stats have fallen from 68 percent to 55 percent.

Furthermore, IE 8’s growth appears to be cannibalistic, that is, as IE 7 drops, IE 8 grows, meaning that IE 8’s growth is largely from upgrades, not brand new users.

Because much of the future of the web depends on HTML5 and other tools absent in all version of Internet Explorer, IE’s loss in market share means that more people are now using a browser that supports web standards and more of the latest and greatest the web has to offer.

And that’s a good thing, no matter which numbers you want to throw around.

See Also:

• After 5 Years on Web, Firefox Preps for Next Round
• Firefox Could Pass IE by Next Summer
• Wired Readers Prefer Firefox, High Res

Twitter’s API has spawned hundreds of mashups and third party software apps, but now it’s growing even further — outside sites have begun mimicking an API to piggyback on Twitter clients.

It started last week with a clever hack by WordPress contributors which allows WordPress.com users to post and read their WordPress.com blogs through third-party Twitter apps like Tweetie 2 for the iPhone.

Now Tumblr has joined in on the fun, allowing you to post and read Tumblr blogs through any third-party Twitter app that allows you to change the API endpoint.

The last bit is key, since while both WordPress and Tumblr have mimicked the Twitter API, you still need to make sure your Twitter client can be manually pointed to the correct URL, i.e. tumblr.com or wordpress.com, rather than twitter.com.

We tested both the WordPress and Tumblr clones of the Twitter API using Tweetie 2 for the iPhone and had no problems setting up and connecting to either service. There are, however, some shortcomings — for example, if your WordPress of Tumblr stream is primarily photos, you won’t see much through the Twitter client. Also, because WordPress and Tumblr both offer infinitely more posting options than Twitter — for instance, uploading photos — the experience of either through a Twitter client is sub par. Still, if you’ve been looking for a good way to blog quick links or short posts on the go, the new API support combined with a mobile Twitter client makes an excellent option.

Dave Winer recently called the development third-party support for the Twitter API an open standard in the making. While we think he might be right, we’re not sure it makes it a good candidate for a de facto standard yet.

For one thing, Twitter is a private company with its own goals for its own API. In order to really become a standard, Twitter would need to freeze its API, ensuring that it doesn’t change. Since Twitter has been doing interesting (and sometimes backwards-incompatible) things with it, like adding geotagging support and changing how replies are handled, and we don’t want to see that stop.

There’s also a very good chance Twitter doesn’t want to freeze its API, which leaves the web with a proprietary API that could change at any given moment — hardly a stable platform on which to build the future of microblogging. In short, WordPress and Tumblr’s recent clones of the Twitter API are just hacks. What Winer and others are hoping is that the hacks will evolve into something more.

It’s important to remember two things. This isn’t the first time an API has been cloned, nor is it the first time a proprietary API has been proposed as a good candidate for a de facto standard. Social bookmarking site Ma.gnolia cloned the Delicious API to great success (before Ma.ngolia went offline) and the OAuth protocol emerged out of a desire to create an open, cross-site authentication platform that mimicked Flickr Auth and other systems.

The web wants a simple, cross-site API that allows basic functionality common to many popular web services — posting, reading and following.

We e-mailed web standards advocate Chris Messina and asked where he thinks this is heading. He points out that there’s already OpenMicroBlogging, an open standard that allows different messaging hubs to route microblogging messages between users in a near real-time time frame.

Unfortunately, OpenMicroBlogging has thus far failed to catch on. Which is why the Twitter API is appealing, because it has caught on and enjoys a wide ecosystem of mashups, desktop apps and mobile clients. It only makes sense that other publishing services — like WordPress and Tumblr — want to be involved in that ecosystem.

As Messina points out in his e-mail, and as has been argued by Dare Obasanjo’s post on 25hoursaday.com, this creates an interesting moral dilemma for Twitter. The company can either embrace this new growth and continue to nurture the efforts of the community, and thus cede total control over its own API, or just ignore it and continue developing its API with aims on improving its own business, even if it breaks the tools built by outside developers.

Whether that ecosystem will remain closely tied to Twitter or perhaps grow beyond it to some kind of standard remains to be seen. But in the mean time, at least you have yet another way to consume your favorite WordPress and Tumblr sites.

See Also:

• New Foundation Wants to Bridge the Gaps Between Open Web Tools
• Thanks to OpenID and OAuth, the Open Social Web is Beginning to Emerge
• Twitter Puts Geotagging Tools in Place