Development

Opera, Blink, and open source

Opera Software released the latest Linux build of its web browser this week; the first Linux version to be based on Google's Blink rendering engine (Blink-based Mac and Windows builds having already been available for several months). However one feels about the browser itself—which, like previous versions of Opera, is a closed-source product—the release is also interesting because it remains one of the comparatively few outside projects that make use of Blink. When Blink was forked from WebKit in 2013, many in the development community expressed concern that the result would be a more fractured web-runtime landscape that would pose increased challenges for open source projects.

The new Opera release comes a year after the company announced that it was dropping its own HTML rendering engine to adopt Blink instead. In fact, Opera had initially announced that it would switch to the WebKit engine—only to be surprised by Google's sudden announcement that it was walking away from the WebKit project to develop Blink. Opera's decision may have been a straightforward cost-saving move; the company certainly has a difficult task cut out for itself, since it is neither the default browser on any desktop operating system, nor is it an open-source application like the market leaders Chrome/Chromium and Firefox.

At the time, Google's decision to fork WebKit into Blink was met with no small amount of consternation in the open source community, including WebKit contributors and various downstream projects. The concern was two-fold: first, that without Google's contributions and influence in WebKit, Apple would dominate WebKit development and governance (perhaps to the detriment of other projects), and second, that Blink would diverge significantly from WebKit, thus splintering the single WebKit-using community into factions with incompatible renderers—an outcome that seemingly favored no one.

In September, Igalia's Juan Sanchez told LinuxCon North America that he suspected that one of the goals of Blink would be to streamline the engine specifically to suit the needs of Chrome—eliminating, among other things, the "ports" system that helped to ensure WebKit ran on a variety of operating systems and frameworks. That, in turn, might make Blink less useful to outside projects.

In the year since the split, few downstream projects have adopted Blink. Exact numbers are hard to come by, but most of the downstream projects that are known to exist tend to be proprietary freeware browsers. Opera, for its part, is taking the commendable steps of sending patches upstream and publicly documenting them, which certainly not all derivative browser-makers do. At present, Blink may still have fewer outside contributors than WebKit, although one change since Sanchez's talk is that Blink has adopted a more formal committer-access process, like the one used by WebKit, in place of the old informal review system.

But it may still be the case that WebKit's broader contributor base (including two large browser makers) essentially forced the project to produce a reusable web-runtime component as its deliverable end-product, and that this is what led to its success. Blink, on the other hand, is developed primarily within Google, by the Chrome development team, and released on Chrome's time-based update schedule.

Of course, there are other projects—like Android—that are developed primarily by Google employees. But if Blink is positioned to be a reusable library or platform, rather than a finished product, there are different concerns for those on the other side of the Googleplex wall. Perhaps a third-party rebuild akin to CyanogenMod or Replicant will eventually arise for Blink as well, providing a less-Google-specific result. But Blink being bound tightly to Chrome development is not problematic simply because it results in fewer derivative works. The situation also allows the development team to implement changes that would be controversial for outside contributors—such as has been seen with Android's increasing reliance on the proprietary Google Play Services module for new functionality.

Of course, time could still make up the difference between the sizes of the Blink and WebKit development communities. But it has been slow going thus far. In September 2013, Digia also announced that it would be migrating, switching Qt's web runtime from WebKit to Blink. The status of that effort is far from clear; the Blink-based runtime was left out of the Qt 5.3 release in May (in favor of the existing WebKit-based runtime), and the developers' mailing list remains relatively quiet. In earlier Tizen releases, Intel had been using WebKit as the basis for its web runtime, but in late 2013 the company started its own web runtime project, Crosswalk, which incorporates pieces from Firefox, Blink, and several other sources.

Both of those projects, of course, are developing products that differ significantly from the Chrome browser. Opera, for its part, may find Blink to be just what the doctor ordered, in that it serves as a modern, actively-developed web rendering engine designed with desktop browsing in mind.

But there is one other disruption to the open-source community potentially hiding in the Blink-uptake story. Opera, although it has never enjoyed the same deployment numbers as Firefox and Chrome, has historically been a valuable ally to those projects in the web-standards development process. Apple and Microsoft, by virtue of being OS makers, have a leg up on third-party browsers, and Opera has frequently been the third voice to speak up in favor of a more open approach to some web specification problem, joining Google and Mozilla (see WebRTC for a recent example). Now that Opera has stopped development of its own HTML rendering engine, there is one fewer independent implementation to prove the viability of an open standard.

A year is not long in the lifespan of an open source project, so Blink may have many accolades and successes in its future. But the lengthy adoption period by those who publicly switched over to the new engine in 2013, Opera included, might bolster the concerns of those who viewed Blink as a serious problem when it first split away from WebKit. So far, there have not been complaints about Apple using its dominance in the Google-less WebKit project to inflict harm, but Blink also has a way to go before it offers a smoothly transitioned alternative.

Comments (6 posted)

Quote of the week

— An excerpt from Morten Welinder's tale of woe for GTK+ application developers.

Comments (13 posted)

30 years of X

The X.Org Foundation reminds us that the first announcement for the X Window System came out on June 19, 1984. "The X developers have pushed the boundaries and moved X from a system originally written to run on the CPU of a VAX VS100 to one that runs the GUI on today's laptops with 3D rendering capabilities. Indeed, X predates the concept of a Graphics Processing Unit (GPU) as we currently know it, and even the company that popularized this term in 1999, Nvidia." Congratulations to one of the oldest and most successful free software projects out there.

Comments (21 posted)

PyPy3 2.3.1 released

The PyPy3 2.3.1 release has been announced. This is the first stable release that supports version 3 of the Python language; it also has a number of performance improvements.

Comments (6 posted)

Go 1.3 available

Version 1.3 of the Go language has been released. As the announcement notes, this update includes performance improvements, support for the Native Client (NaCl) execution sandbox, more precise garbage collection, and faster linking for large projects. It also adds support for several new environments, like Solaris, DragonFly BSD, and, of course, Plan 9.

Comments (none posted)

NetworkManager 0.9.10 released

NetworkManager 0.9.10 is out with a long list of new features including a curses-based management interface, more modular device support, data center bridging support, many new customization options, better cooperation with other network management tools, and more. (Correction: the release is almost out, being planned for "later this week").

Comments (18 posted)

nftables 0.3 available

Version 0.3 of nftables has been released. This version introduces several syntax changes, including a more compact form for queue actions and the ability to provide the multiqueue as a range. New features include a new transaction infrastructure that supports fully atomic updates for all objects, and the netlink event monitor for watching ruleset events.

Full Story (comments: none)

Development newsletters from the past week

• What's cooking in git.git (June 20)
• GNU Toolchain Update (June 22)
• Haskell Weekly News (June 18)
• LLVM Weekly (June 23)
• OCaml Weekly News (June 24)
• OpenStack Community Weekly Newsletter (June 20)
• Perl Weekly (June 23)
• PostgreSQL Weekly News (June 22)
• Python Weekly (June 19)
• Ruby Weekly (June 20)
• This Week in Rust (June 22)
• Tor Weekly News (June 25)
• Wikimedia Tech News (June 23)

Comments (none posted)

Microformats turn 9 years old

At his blog, Tantek Çelik writes about the ninth birthday of the microformats effort, which seeks to express semantic information in web pages through the use of attribute names within HTML elements, in contrast to comparatively "heavyweight" schemes like RDFa and Microdata. Çelik notes that the community-driven process of microformats' development seems to have enabled its survival. "Looking back nine years ago, none of the other alternatives promoted in the 2000s (even by big companies like Google and Yahoo) survive to this day in any meaningful way", he says. "Large companies tend to promote more complex solutions, perhaps because they can afford the staff, time, and other resources to develop and support complex solutions. Such approaches fundamentally lack empathy for independent developers and designers, who don't have time to keep up with all the complexity." In addition to his analysis about the past nine years (including an exploration of the down side of email-based discussions), Çelik takes the occasion to announce that microformats2 has now been upgraded to the status of ready-to-use recommendation, and points site maintainers to tools to support the transition.

Comments (44 posted)

Ancell: GTK+ applications in Unity 8 (Mir)

At his blog, Robert Ancell provides a status report about the work he and Ryan Lortie have been doing to ensure that recent GTK+ applications run in Ubuntu's Unity 8 environment. While there is still work to be done, including fixes for cursor changes, fullscreen support, and subwindow focusing, he notes that there is a personal package archive (PPA) available for testing libraries and select applications. "The Mir backend currently on the wip/mir branch in the GTK+ git repository. We will keep developing it there until it is complete enough to propose into GTK+ master. We have updated jhbuild to support Mir so we can easily build and test this backend going forward."

Comments (none posted)