Why should you work in the open?

Recently, I have been reflecting on, discussing and writing about open source. After the publication of an article on the Wired web site, one of my colleagues, Kristofer Joseph, came to me and essentially said: “I think there is something about open source that your article does not cover, that is important and that people often miss”. Of course, Kristofer had my full attention with that introduction. So we talked more and Kristofer went on to explain that he felt that the ‘working in the open’ part of the open source culture was either overlooked or not understood. I think he is right so, let’s talk about that. Why open source often means working in the open (it should)? Why is it important?

Raising standards

When you work in an open source project, your code is visible by anyone. Not only your source code, but every single code commits you make and every interaction (comments, issue tracker, mailing list) you have with the community. There is no hiding in open source. Your contributions and interactions paint a living memory of your persona.

You have to show your true color and that is why open source is a meritocracy and not a status based culture. Your work speaks for yourself. That typically makes people raise their standards, strive for excellence and I am convinced that the open collaboration explains a large part of the open source software’s success.

Get early and constant feedback

If you work in the open, you can interact with people as you develop your code. In a way, it is related to the lean start-up model that is geared towards early customer feedback that allows quick iteration and course correction. Transposed to an open source project, working in the open is letting you be lean: your customers, people who might use your project, can see on-going project, try early versions of the software and comment. You can also reach out to them to ask for opinions, preferences or guidance. You can experiment fairly quickly and validate or invalidate hypothesis you have.

A great example of early and constant feedback is the work that Kristofer and his team do on the Topcoat project. By working in the open, we have made a lot of design choices and course correction, thanks to the feedback we got from our bleeding edge users.

But working in the open has its traps. As Kristofer mentioned, it is not always understood.

Working in the open means good and bad work in progress is shared

People not familiar with open source sometimes have the expectation that it should be like a product from a commercial company. So if I get code from the project, and if it is not perfect, then there is disappointment.

This is where open source project are usually careful at setting expectations and try to guide their users, making it clear where to get a stable build, versus a development version or a beta build. For example, you can get nightly builds of WebKit and by the design of that version of the project, it is clear it is work in progress.

The best open source projects use continuous integration to get natural quality assurance on their code for building, testing, coverage and performance regressions, which helps maintain high standards even for in-progress work.

Working in the open means that you can implement your own wishes!

Another thing which sometimes happens is that people would expect that they can interact with an open source project like they do with a vendor. If there is a feature that I want, they I should demand that it be added. It works a bit differently in open source.

Of course, projects typically welcome suggestions or requests for features. That is part of getting feedback and guidance from the users. But if you really want something to happen on your schedule, the best approach is to actually contribute to the project and start engaging and contributing to the effort. A lot of individuals and companies do that routinely with a lot of success, for example around the Eclipse open source project.

So, why work in the open? Not just for open source!

Working in the open makes your project run like a start-up trying to get constant feedback, reacting to demand quickly and adjusting course as needed. It makes you and your team raise your standards. It means that you have to set expectations properly too, but that is ok. And it also allows you to welcome contributions to your project, making it more valuable than you could on your own. So Kristofer is right, this is all important!

A final, important point: working in the open can also be done for non ‘open-source’ projects. It is an approach you can take for internal project and even very large companies such as SAP have been able to implement that successfully, as Dirk Riehle described in his research.

Open Source Flash C++ Compiler, CrossBridge

We are excited to announce that the Flash C++ Compiler (FlasCC) has been contributed to open source as CrossBridge and will be delivered through GitHub.  FlasCC has become the standard technology to bring C/C++ content to the unparalleled reach of the web.  As CrossBridge, it will enjoy the speed of innovation and improvement that the open source community can bring.

FlasCC was previously delivered as part of the Adobe Creative Cloud.  As CrossBridge, it is available to everyone and we invite you to join with us to improve it.  Adobe will continue to invest in CrossBridge, contributing to and managing the project.  CrossBridge has been released as 1.0.1, containing all the original source of FlasCC 1.0 plus several improvements to the product.  In addition, we have contributed all current, on-going development work of CrossBridge 1.1, which includes an upgrade to LLVM and the front end, Clang to enable advanced C++ syntax support.  We look forward to collaborating with the community to complete this exciting release.

To get started with CrossBridge, please visit adobe-flash.github.io/crossbridge and, to find out more about our Game Developer Tools and the Adobe Creative Cloud, visit gaming.adobe.com/getstarted.

The Changing Web Platform Landscape: More Fragmentation?

The Web is an ever changing place and the first half of the year has been rich in surprises, big announcements and industry shifts! A diversity of implementations is good for many reasons we will discuss. But a more fragmented web could be the price to pay. Will it be the case?

About Implementation diversity

A few weeks ago Opera announced they were stopping work on their Presto rendering engine and switching to Chromium. They have already started contributing code to the project. Then, earlier this month, Google announced the Blink project, essentially a new fork of WebKit. And now Opera announced they will contribute to Blink!

Reactions were interesting as we went from WebKit monopoly concerns to worries about web platform fragmentation in a matter of weeks. Quite a 180 degrees turn!

At Adobe, we actively contribute to Web standards and browser implementations (historically mostly WebKit and Chromium, even though we also make some contributions to Gecko). As such we are delighted to see Opera join one of the projects we contribute to. Their considerable web expertise will undoubtedly be an asset.

There was some debate before the Blink announcement about whether or not we were heading for a WebKit monoculture: a web where content can be written with the assumption a WebKit-based engine is most likely to render it. While WebKit browsers share much core layout code they also differ in many ways at runtime: different JavaScript engines and graphics libraries, even different sets of features enabled by default. This makes it difficult in practice to write once for WebKit and run everywhere.

So we were not too concerned about a WebKit monoculture. But…

… there was a but in that view. The web is bigger than any one of its leading browser implementations and too important to be limited to a single code base even if that implementation has variations. The web is even growing to be an OS platform (e.g., ChromeOS, FirefoxOS, the new Windows Runtime), the core technology behind packaged applications (like PhoneGap applications). And ongoing innovation across HTML, JavaScript (in the TC-39 group at ECMA) and CSS needs validation, testing, consolidation.

As Brendan Eich says in his blog about “why Mozilla matters”:

“The web needs multiple implementations of its evolving standards to keep them interoperable.”

I believe this tenet to be central to delivering on the promise of the Open Web. A single implementation does not establish a standard. The W3C process even recommends two implementations in order for a specification to reach completion.

The Web needs Mozilla’s Gecko and Microsoft’s Trident engines to nurture an open, innovative environment. Historically, both companies have done a lot for the Web  - think of XHR which Microsoft invented (among other key contributions) or WOFF from Mozilla –  and they continue to innovate:  Microsoft and Mozilla co-edit the CSS Grid specification, which provides much needed and improved layout flexibility to CSS.

I trust that the addition of Blink will strengthen an already healthy browser competition. Over time, the Blink code base will diverge from WebKit’s but no harm to the web occurs if both engines implement the same features in different ways. Only significantly different feature sets could result in harmful fragmentation. Making sure that WebKit, Blink and other browser engines interoperate is more important than it has ever been.

About testing, fragmentation and experimental features

As the founders of Test the Web Forward, we have come to appreciate the mutually reinforcing benefits multiple independent implementations bring to standards. Historically, testing has been key to the success of web standards. For example, the focused testing effort on CSS 2.1 has shaped that specification and its implementations in the corner stone CSS has become. A single implementation would leave a lot of stones unturned.

It should also be noted that the Blink policy regarding prefixes is really good for standards and compatibility across browsers:  draft standard features can become truly experimental features that will not be used (and abused) in production. This should help avoid browser compatibility headaches down the line and I hope this example will be followed by all browsers.

About fragmentation and Adobe’s contributions

In this new web platform landscape, what about Adobe’s contributions to open source browsers? What impact does additional browser fragmentation has on Adobe’s efforts?

Adobe contributes to standards in open browser implementations for many reasons.

One of them is that our new generation Edge tools use a ‘web design surface’. For well over a year now, we have chosen to use the Chromium Embeded Framework (CEF) to provide this ‘web design surface’. So naturally, we will contribute to Blink since it is now the core engine that powers CEF.

Another reason for contributing to open browsers is to accelerate the availability of new features on the web. This is why we collaborate with Mozilla on a number of standards and contribute code to Gecko (like this patch on masking for canvas). And this is why we will also contribute to WebKit, in addition to Blink, now that the two are separate projects.

An open, innovative and tested web!

So yes, I think it is good to have multiple browser engines and Blink is a welcome addition to the web platform landscape. It is bringing a healthy diversity that I hope will help keep the web open and foster innovation as long as all browsers strive to implement ‘the same web’.

And this is where testing efforts are key to achieving diversity without fragmentation. I hope testing activities (of browser code of course, but of standard test suites as well and major initiatives that the W3C is driving) will be a major focus for all the browser vendors going forward, in particular for Google with its new Blink implementation.

A Vibrant Web Development Community: Pushing the Edges of the Web

It is really amazing to see the level of energy and enthusiasm around Web technology and how the envelop get constantly pushed by developers. This becomes really visible in the conferences that happen around the world on the topic. In our teams, we attend and participate to a lot of events as a way to present new advances on the Web but also as a way to learn and be aware of developer pain points.

In the last week alone, for example, we have been involved in various events.

First, Adobe hosted W3Conf in San Francisco.

1

This is a conference organized by the W3C and which addresses Web developers. The agenda was packed with great talks such as Eric Meyer’s presentation on “The Era of Intentional Layout”, Adobe’s CJ Gammon’s inspiring talk about the future of reading (see “Do androids read electric books?” or Adobe’s Alexandru Chiculita’s stories from the mobile web trenches in “The making of CSSFilterLab”. And of course, Joshua Davis’ talk on “Beyond Play: the Art of Creative Coding” showed how web technologies (SVG) can be used in the creative process, even though not necessarily inside a browser.

2

An example of generative art by Joshua Davis shown at W3Conf

 

3

A slide from Christofer Gammon’s W3Conf talk – Pushing the edges of the Web!

Read more about the W3Conf, the Doc Sprint that was held after, and the Processing Workshop by Joshua Davis.

Unfortunately, I was not able to attend W3Conf myself, but that was for a good reason: I was speaking at another great conference in Bangalore, India. The conference was called Meta Refresh and gathered a lot of developers and designers. I enjoyed giving a talk about “The Quest for the Graphical Web” and listening to speakers who thought beyond simple responsive layouts to get into content prioritization and interleaving (see Arpan Chinta’s talk “Getting serious about Responsive Web Design”) and questioned our approach to design altogether (with Tulsi Dharmarajan’s talk “High on design”).

4

Another example of a great conference is Web Visions NewYork where Mihnea-Vlad Ovidenie from our team talked about “Using CSS Regions to Create Magazine-like Layouts for Any Screen” and Kevin Hoyt gave a presentation on “Building Mobile Applications with Web Standards”.

5

All those events are a testimony of the activity around the Web platform (if proof was needed!) and how creative it is becoming. It is also nice to be in a day and age when, if you miss a conference, or cannot travel to it, you can alway catch up online with videos. See the W3Conf videos and the Meta Refresh videos for example.

We are actively involved in organizing or sponsoring events to make the web better, please join us at html.adobe.com/events!

Packaged Web Apps with PhoneGap

Adobe acquired PhoneGap a little over a year ago because it was and continues to be the leading solution for Mobile Application developers who want to use their HTML5 skills to create native applications.

Essentially, PhoneGap lets a developer write HTML, JavaScript and CSS content, use mobile APIs providing much needed functionality (such as device orientation, access to the address book or location) which is not always yet available in browsers and package these applications as native ones so they can be distributed in application stores such as Google Play or the Apple AppStore.

PhoneGap is the solution that is based on the open source Apache Cordova project, similar to the way the Chrome browser, for example, is based on the WebKit open source project.

Since PhoneGap is using an open source platform targeted at developers and created by a community, the following gives recent updates about the different aspects.

Platforms

Despite the holidays, there was a flurry of activity in the mobile web world. The Cordova team released 2.3 with full support for Windows 8 and Windows Phone 8 (Window 8 support was added in 2.2). The popular iOS and Android projects saw more performance and bug fixes. Long anticipated BlackBerry 10 is shipping this month with complete support. Working closely with Mozilla, the team also has Firefox OS on the horizon early this year. 

Tools

New common Command Line Interface (CLI) tooling is progressing to beta quality for building projects. The plugin tooling is now quite mature for iOS and Android. Work is now starting to migrate the core API to plugins, and add support for BlackBerry and Windows Phone. The Ripple emulator received much love in December bringing in beta quality support for remote device proxy and the ability to host Ripple. Also good news, the long awaited PhoneGap/Build CLI is ready for beta, integration to the PhoneGap release can be expected in the coming releases.

Community

An open source community health is directly proportional to the activity on the code. Operationally speaking, Cordova offers monthly stable source-only releases and a bleeding edge development channel. However, things are progressing and we will likely see stable, beta, and dev channels available in Cordova 2.4. The project has matured in adoption enough to justify this third release channel for developers that want to be on the bleeding edge. The team will continue to ship PhoneGap on the same cadence. 

We added one committer from IBM in December, and have seen two new contributors become active in the project from the Google Chrome team.

Adobe & The Web

Today, we’re unveiling a new addition to the Digital Media blog, focused on the Web platform. The new blog, called Adobe & The Web, will touch on thought leadership, industry trends and product related announcements from Adobe and partners in the standards and open source Web space. We’ll also touch on commercial tools and service offerings. See our inaugural post below and look for much more to come.

Today in San Francisco, we kicked off Create the Web, a worldwide tour for interactive web designers and developers and partners that will provide us with the opportunity to share our vision for the web. We are delivering a live streamed keynote that lays out our vision for the web and the role that Adobe will play.

Our mission is to make the web better and to build the best tools in the world for web designers and developers.

We contribute to web standards and to open source projects, like WebKit and Cordova, to move the web forward. We get involved in the community, through hackatons and meet-ups. For example, we have worked with the community to organize a series of events called Test The Web Forward. These are a kind of hackatons where we focus on identifying and fixing interoperability problems in the various browsers. We welcome and encourage the participation of anyone interested in joining us.

We are contributing improvements in a few areas where we have some expertise, including magazine-quality layout (CSS Regions & CSS Exclusions), graphical foundation (blend modes, compositing and transforms), better device APIs and cinematic visual effects (CSS custom filters). We are also making available today CSS FilterLab, a fun experiment to play with custom filters, which even allows you to write and debug custom shaders right from your browser.

We also build the tools and services that web designers and developers need. This includes tools like Dreamweaver, our all-in one web production tool. We are releasing today an update to Dreamweaver with support for new HTML5 elements, faster FTP, a streamlined insert panel, support for Edge Animate and more. This update is available for free to Creative Cloud members.

We also introduced today the Edge Tools & Services, which are available with a free membership of Creative Cloud. They include Edge Animate, a powerful tool to create interactive and motion content; Edge Inspect, an indispensable tool to preview, inspect and debug your web content on mobile devices; Edge Code, a code editor for HTML/CSS/JavaScript, available now as a preview and PhoneGap Build, a hosted service to easily build web apps for mobile devices using the PhoneGap framework.

We’ve also introduced Edge Web Fonts, a new service built on the Typekit engine to deliver free and open source fonts.

We’ve given a sneak preview of a new tool we’re working on called Edge Reflow which makes it  easy to create responsive web content visually, but using standard CSS and media-queries.

Following San Francisco the tour continues on to London, Tokyo and Sydney in early October followed by a 30-city international tour of “HTML Meetups” in destinations throughout the Americas, Europe, Asia, and more. These “HTML Meetups” are centered on JavaScript, CSS, HTML, designing and developing web content and mobile apps and include a one-hour overview of content from Create the Web and deep dives with demos on our products related to design and development. To request a Meetup in your city, visit http://html.adobe.com/events.

We had a lot of exciting news to tell you about today. To find out more about what we’re doing to make the web better, visit html.adobe.com.

Improved Open Source Testing Tools for Flex

Back in the early days of Flex there wasn’t much for doing unit testing, automated testing, performance testing, etc. Thanks to the community there are now numerous open source testing tools for Flex. Here are some recent updates you should definitely check out if you are building production Flex apps:

FlexUnit 4.1 Beta 1
FlexMonkey [...]

Open Source Media Framework Webinar Wed June 10

An event not to be missed. In tomorrow’s webinar, Lisa Larson-Kelley will dive into the fundamentals of Open Source Media Framework (OSMF), Adobe’s standard video player libraries for building playback experiences and monetizing video on the web. She’ll give you a high-level overview of why you’d want to use OSMF and what it can do, and then dive into its underlying structure and some simple sample code to get you started. This session is for beginner to intermediate programmers and web developers who want to gain a better understanding of OSMF, and how it can simplify media player development.

Lisa is a speaker not to be missed! On top of this, there is a chance to win a copy of CS5!

Register now (I have)
http://www.eventsadobe.com/osmflaunch/invite.html

Flash Player Will Support VP8

As Kevin Lynch mentioned today at Google I/O, we are excited to include the
VP8 video codec in Flash Player in an upcoming release, which will help
provide users with seamless access to high quality video content on all of
their Internet-connected devices. Today, VP8 was released as
open source by Google as part of the WebM effort.

Companies distributing video online need the freedom of choice to deliver
the right experience for their customers and their business. We have a
legacy of embracing standards, such as H.264 and HTTP, in our video delivery
stack and are excited to be building on this with the inclusion of VP8.
Today, approximately 75% of video online is viewed using Flash Player
because it provides the reach and consistency that companies need as well as
additional capabilities, such as content protection, measurement and
monetization opportunities that are critical to driving their business on
the web. By adding support for VP8 to Flash Player we will extend the
ability to use these critical capabilities with this media format and
provide content owners the freedom of choice in how they deliver video.

We will drive Flash Platform innovation well into the future, partnering
with our customers to develop end-to-end solutions that enable them to
create, deliver, and optimize their content across any device or screen
using one, unified workflow. By including VP8 as part of the Flash Platform,
we’re providing companies with a choice as to how they can work with and
deliver great experiences to the web. We are excited to work with Google and
others to ensure web video continues to evolve and better serve content
publishers, web developers and end users.

Visit the Google WebM page to learn more about the project.

GIO.jpg

Flash is as open as HTML5

How’s that for a controversial title? But… It’s true… Hear me out!
First of all let me say that I have absolutely nothing against HTML5! Innovation and competition is always good and keeps everyone on their toes.
One of the first blog posts I read this morning was one on AppleInsider. An Apple spokeswoman claimed that Adobe’s [...]