Tomorrow I’ll be over in Seattle attending Adobe’s AIR Bus tour. As part of that, I’ll be giving an Ignite talk on “Openness and the Web”. If you are attending, stop by and say hi…
Archive for the 'internet' Category
Yesterday I had lunch with Annette Moser-Wellman, who lives on Bainbridge Island and is interested in innovation, creativity, and leadership. One of the great things about Bainbridge is that there are lots of people here who are doing interesting stuff. The hard part is connecting with the people that are doing things that you might find interesting. Of course, this is a problem in the wider world, but on an island of 25,000 people, with a decidedly small town feel, it seems reasonable to expect that it might be easier than normal to make those connections. The interesting thing about my conversation with Annette, other than the content - which spanned open source, innovation, education, and the Singularity - was how it came about. Annette had read Scott Rosenberg’s Dreaming in Code and noticed that I lived on Bainbridge Island. From there, she hopped onto LinkedIn, which led to our lunch.
That morning, In anticipation of the lunch meeting, I was reflecting on the value of the various social networking sites, when Anne Zelenka twittered:
LinkedIn attracts all sorts of people who would never blog or join Facebook or use Twitter, so it adds a ton of value to online life.
A timely tweet, to be sure. The key insight, I think is that one way of measuring value of particular social networks is the groupings of people that they “reach”. My Firefox bookmarks toolbar has a growing pulldown for social networking sites: Flickr, LinkedIn, Twitter, Dopplr, Upcoming, Facebook, and Pownce.
The ones that I’ve gotten actual value out of have been Flickr, LinkedIn, and Twitter. Flickr is completely an affinity group thing, so no surprises there. LinkedIn has a huge reach, as Anne points out, and perhaps because of its professional billing, has yielded several interesting meetings, and friendships. Not to mention job opportunities. There some interdisciplinary crossover, which I think is a plus. Twitter is very “hipster geek” focused, and has yielded new relationships with people like Ryan Stewart and Anne Zelenka, as well as being the impetus for the series of posts on Rich Internet Applications earlier this year.
In the end, for me it’s still all about finding your tribe. If physical book to virtual social network to real world lunch is what it takes, then I am game.
People working in open source have limited opportunities to meet each other in person. My own experience is that meeting someone in person, even if it is only once, can be a help in working with them in the virtual world. The Dopplr service is a social networking application oriented towards people who travel. I’m already using it to find out who is going to at OSCON and ApacheCon US later this year. Meeting folks from various open source communities in person has been an enriching experience for me, and I’m glad to have help at making that easier.
Let me know if you want a Dopplr invite.
So yesterday Dave Winer hooked his version control system up to Twitter. I was just idly wondering how long it would take Bear to hook all of CIA up to Twitter…
Update: It took him 35 minutes. But he’s not turning it on, because he doesn’t want to kill Twitter - and I agree…
Microsoft has announced that it is embedding a version of the CLR into their Silverlight RIA technology. Blogging machine Ryan Stewart had some of the initial details, and Sam Gentile has a good pile of links. The CLR enabled version of Silverlight will run inside Firefox (both on Windows and OS X) and inside Safari. This is a good step at cross platform support, but the omission of Linux, while not surprising, reduces the reach of Silverlight versus Flash or regular AJAX. Also, it appears that there are no Mac development tools for Silverlight, although presumably there is always text editors.
DLR
The most interesting part of the whole business is the Dynamic Language Runtime, which is the project that Jim Huginin has been working on since he arrived at Microsoft. The DLR currently supports JavaScript, a dynamic version of Visual Basic, IronPython, and IronRuby. John Lam’s work at Microsoft also appears to be paying off. eWeek had three good articles on DLR technology, and all three articles include conversations with Jim and John. It’s nice / interesting to see that two people could have a large impact on Microsoft. The DLR is being made available under a BSD style license. While I have to give props to Microsoft for choosing an unrestrictive license, I’d point out that a license is not a governance system, and while the DLR might technically be open source, the “Core CLR” definitely is not, and neither is the XAML portion of the Silverlight runtime — no surprise there. I wonder if we will be seeing a port of the DLR on top of Mono. I also wonder if IronRuby can run Rails, although that seems like a weird thing to want to do inside of Silverlight.
Linq
Another part which I find interesting is the inclusion of Linq as part of the Core CLR. I like Linq, and if Microsoft is going to try to define a new platform for inside the browser, I’m happy that they’re including Linq as part of the core.
Impacts
Here are some of the potential impacts of this announcement:
Since Silverlight will include the CLR, it will benefit from the CLR JIT and garbage collector, which together with Mozilla’s Tamarin, will raise the bar for JavaScript performance in the browser. It’s unclear whether regular AJAX apps running in a Silverlight enhanced browser would beneft from CLR acceleration of Javascript. I’m in favor of the browser vendors getting into a Javascript performance race with each other.
Allowing people to write browser side applications in multiple languages fragments the technology on the browser side. You could argue that the benefits of either IronPython or IronRuby are sufficiently large over Javascript that such fragmentation is ok. I’m not as sure that this is a good thing.
If there is significant uptake of IronPython or IronRuby for Silverlight development, that could have interesting impacts on the Python and Ruby communities. The Ruby community is already dealing with a proliferation of different Ruby runtimes, so there probably isn’t much new there other than a change in the mix of adoption of the various runtimes. On the Python side, its less clear, since the CPython implementation is the most heavily used.
The inclusion of facilities like Linq will boost the semantic level of the platform running in the browser. Granted, it only does that for Silverlight, but I hope that this puts some pressure on the other players to provide more leverage in the platform. If we are going to be building much richer applications inside the browser, we are going to need all the help that we can get.
So what?
In the end, though, I probably won’t be doing much with Silverlight, for the same reasons that I’ve written about before. The technology has definitely gotten stronger, but the other issues haven’t really changed much: there are no tools for the Mac or Linux, and as far as influencing the technology, you’re just standing outside the Big House, pressing your nose up against the window.
Last week while I was in San Francisco, I sat down for an hour with David Wadhwani, the VP of product development for Flex and Ely Greenfield, one of the Flex architects. After I wrote my original post about open sourcing Flash, I got a note from David asking if I would be willing to spend some time to help him understand the issues that I raised in that post and its follow ons. This afternoon David called to tell me that Adobe was announcing that it was open sourcing Flex v3. I was especially happy when he said that my posts and our conversation had an impact on his thinking about open source and Flex. There is a press release with the announcement as well as a FAQ on the basics.
The Basics
The basics of the announcement are that Adobe will open source Flex v3, due later this year, under the Mozilla Public License (MPL), which is sensible given that they have already open sourced their Tamarin Javascript engine via Mozilla. Before that happens, Adobe will make daily builds of Flex available (the source is already available, but daily builds gives better visibility). Also, they will open their bug tracker to the public in preparation for the open source version of Flex.
Adobe is taking a slow approach on governance. Unsurprisingly, the initial set of committers will be folks from Adobe, and the governance model is underspecified. Right now, the FAQ says that the schedule and roadmap for Flex will continue to be defined by Adobe. There are stated plans to create a subproject process and subprojects could be managed by people outside Adobe, and incorporated into the Flex tree. The full governance model is not yet determined, and will be influenced by feedback and what actually happens between now and the end of 2007, which is the target for the transition to being a full open source project.
I think that there are likely to be some concerns around use of the Flex trademark. Unlike Java, where (in theory anyway) an open source Java could pass a compatibility test suite and gain access to the trademark, the open source version of Flex cannot be called Flex. It remains to be seen whether this will actually impact participation in the project.
Flex, but Not Flash
This is a good first step for Adobe, but it’s just the first step. The Flash player is not being open sourced at this time, but when I talked with David he told me that that Adobe had been telegraphing the fact that they were going to open source Flex for about 20 months, since the opening of Adobe Labs. When I asked him about the Flash player, he said that open sourcing Flex should be viewed as a telegraphing of Adobe’s intentions. Of course, there’s a big difference between intentions and actual followthrough, so we’ll have to wait and see how the Flex project ends up working out.
Bottom Line
Adobe is moving pretty quickly. When I met with David a week and a half ago, I got the impression that he and Ely had decided that they wanted to open source Flex, but hadn’t cleared it with his management chain. A week and a half later, they are making an announcement. As I’ve mentioned, this is just a first step for Adobe, and there are plenty of opportunities for things to go sideways. Nonetheless, I think that Adobe has understood the importance of openness and is taking some initial exploratory steps to do what’s necessary.
If you think that an open source Flex is important, then you should go to the new discussion forum that Adobe is setting up for open source Flex. There are a lot of things which are intentionally unspecified, and there is still lots of time to give Adobe feedback on this move. I know that I’m going to keep giving them feedback for as long as they continue to solicit it.
Update:
Scoble has a video interview that lets you hear some of what I’ve heard from David and Ely.
So back in March, Brendan Eich of Mozilla wrote post titled “The Open Web and its Adversaries“. His definition of open seems to rest on this:
a web whose major content formats are not controlled by a single vendor
A goal which I agree with, and the basis for my series of Flex posts, which he also referenced. So far, so good. As he continued, I got confused. He asks us to:
Consider just the open standards that make up the major web content languages: HTML, CSS, DOM, JS. These mix in powerful ways that do not have correspondences in something like a Flash SWF.
I agree with his assessment of the powerful ways in which these technologies combine. But much of what he finds laudable are technical properties — they don’t derive from the fact that these are open standards. It’s just a fortunate (or perhaps, designed) outcome that those are the technologies that are combined in a browser. After all Java, C#, and even C++ have been standardized (well at least if you believe that the JCP is standards body), so being an open standard technology is not a guarantee that you’ll have the properties that make the web “alive” according to Brendan. It seemed like what was really being discussed was the “live web”, not the “open web”.
The place where I really got lost was when he started discussing the future of the open web,
Implicit in my writing is the assumption (conclusion, really) that browsers can adopt the necessary advanced rendering and faster virtual-machine programming language support that the “rich client platforms” boast (or promise in version 2.0). … There’s no technical reason this can’t be interoperably supported by other browsers in the near term.
There’s no technical reason, but there are plenty of political/business reasons. Every browser implements each of the open standards to a varying degree. They implement different versions of the specs. They implement each spec imperfectly. That translates into lots of debugging and testing when building an application atop the open web. I like the improvements that are likely to come in Firefox. The problem is that until many of those improvements appear (if ever) in Safari and IE, it will be hard to justify using those improvements, because it means writing multiple versions of the same code and then qualifying those versions. Contrary to Brendan’s assertion, big companies with armies of developers might have the resources to devote to all that additional work, but small development houses are the least able to tolerate that additional labor. Since Microsoft has an interest in advancing WPF/E, part of the Closed web, it’s hard to imagine that they will be motivated to improve IE quickly enough for innovative Live web features in Firefox and Safari to make a difference to application developers versus something like WPF/E or Flex. The risk to Microsoft is that instead of collecting those developers themselves, they lose them to Adobe.
Or so it would seem.
A few weeks back, Dare Obasanjo said “Open Source is Dead“. The crux of his argument:
This is why Open Source is dead, as it will cease to be relevant in a world where most consumers of software actually use services as opposed to installing and maintaining software that is “distributed” to them.
If the only valuable property of open source was as a distribution mechanism/channel, I’d be inclined to agree. But open source is a means of production not only a means of distribution and routing around lock in. And of course, his argument applies to all distributed software, not just open source software. Which would make Microsoft dead as well.
This would no doubt please Paul Graham, who earlier this month wrote that “Microsoft is dead“, repeating the idea that software delivered via the web is in the process of displacing desktop software. Although for him to be announcing this in 2007, ‘to be the first one to call it” seems somewhat late. Also he weakens the case for web vs desktop software by tossing Apple into the mix, and the last time I looked, Apple was a desktop software company.
To complete the trifecta, Jeremey Wagstaff [via Marc Orchant] clarified that ‘It’s Not the “Death” of Microsoft, it’s the “Death” of Software‘. That doesn’t seem right either, since there’s a lot of software running all those web apps that are killing off everybody else. Of the three prognosticators of doom, his comments resonate the most with me:
We somehow demand less and less from our software, so that we can declare a sort of victory. I love a lot of Web 2.0 apps but I’m not going to kid myself: They do one simple thing well — handle my tasks, say — or they are good at collaboration. They also load more quickly than their offline equivalents. But this is because, overall, they do less. When we want our software to do less quicker, they’re good. Otherwise they’re a pale imitation of more powerful, exciting applications in which we do most of our work.
—
But all this just proves to me that there has been little real innovation in software in the sense of making programs do more. Web 2.0 has excited us because we lowered our expectations so much. Of course web apps will get better, and one day will deliver the functionality we currently get from desktop software. They may even do more than our desktop applications one day. But isn’t it a tad strange that we think this is all a huge leap forward?
Perhaps its a Great Leap Forward…
A few weeks back, I had dinner in Seattle with Ryan Stewart and Brian Zug. Over the course of several hours we covered a number of topics, including a crash course in open source software. Yesterday Ryan posted some of what he learned during our conversation, including his conclusions about whether or not open sourcing the Flash Player was a good idea. That post generated a bunch of traffic, so Ryan put up a follow up post on his personal blog.
Unfortunately, many people reading Ryan’s post or one of the aggregated excerpts didn’t have the context which prompted the dinner and the posts. All of this took place in the context of three blog posts which I wrote last month where I took a look at Adobe’s Flex/Apollo technology from the point of view of the openness of the technology. I’m interested in Flash only as a component of Flex. I’m not interested in singing/dancing web pages or in Flash based ads, but much of the reaction to Ryan’s post was centered around traditional uses of Flash in web pages. Many people said “oh, open sourcing it will destroy compatibility”. Yet the context of the discussion included ways of maintaining compatibility.
The most interesting response that I found was from Ted Patrick at Adobe. Ted shed some light on the ways that Adobe/Macromedia have involved customers in the development of previous versions of the Flash Player. This was useful information to have — I think that I was probably more ignorant of these facts than Ryan was, truth be told - and suggests to me that there is some culture of working with people outside of Adobe/Macromedia. Perhaps most encouraging was his acknowledgment that Adobe could be more open. Of course that’s not a commitment to be more open, and indeed, he warns that becoming more open will not happen overnight. I am not expecting something to happen overnight — after all, I’ve waited 9 years for Java, and am still waiting. The wheels do have to start turning sometime, though.
From the desk of Alex Payne:
All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.
Yep. Dynamic Language performance sure does count… Read the whole thing.
Recent Comments