Open source – Page 11

The yin-yang of FOO and Bar

Much has been made of the supposed sibling rivalry between FOO and Bar, owing to BarCamp’s origins last year as “an open alternative to FOO“.

What I think often goes missing from the story is that the original BarCamp was planned, organized and executed by a small scrappy group of upstarts, only one of whom had previously been to FOO Camp (and who ended up being invited back last year anyway). It wasn’t anti-FOO, it was just different — with different goals and a different raison d’etre.

In fact, I’ve personally reached out to the O’Reilly folks on a number of occasions to try to coordinate our events better and to even ask for favors. On the whole, they’ve been as gracious as anyone with as much going on as they’ve got and personally see no reason to chide them for focusing on their own business interests.

And I think Dave Weinberger‘s post is therefore useful in that he recognizes the value of socially engineered social networking while acknowledging the benefit of the “unbarred” model:

There’s value to an invitation-only party, but it’s not the only sort of party we need. That’s why I’m so happy that the original FOO Camp spurred the invention of unbarred BAR camps that are structured like FOO but are open to anyone. There’s a place for both.

Those who appreciate and have a sense for this duality — of there being both privilege in being invited to anything exclusive and those who, at the same time, can question what they have to offer and why they made the cut — get why both FOO and Bar can and in fact, should, co-exist. At FOO Camp, someone else invites you and you wonder why; at BarCamp, you invite yourself and over the course of a weekend prove why you did.

What I think Tim is still missing out on, however, is that the Spirit of BarCamp is very at odds with the competitive angst and jealousy that spurs events like NoFoo (no offense ~~Robot~~ Robert, but why define your event by what it’s not? i.e. BarCamp isn’t an “unconference” — it’s an “ad hoc gathering” as it says on our homepage). And, Tim, I’d humbly suggest that you consider your own advice:

Stop worrying about what Winer thinks.

The way I see it, a year out, FOO and Bar represent the very yin and yang balance of openness and proprietariness that the open source community and its offshoot industries have struggled with since their inception (which has also been well documented in Markoff’s Doormouse). While one does not need the other to exist, that they both exist, espouse different organizing and ownership models and appeal to different people on different merits is what’s important. This is the reality and benefit of creating non-zero-sum economy where network effects and community rule the day. It’s not one other other, it’s both for one another.

BarCampEarth starts tomorrow!

So it is upon us… in a very short amount of time, BarCampEarth will commence, with simultaneous events happening around the world (with many more coming in September!). Taking part this weekend:

Whoa how far and wide our community has grown in a year. Believe it or not, I have a draft saved in my blog from August 24, 2005 titled “Bar Camp Worldwide”. I got as far as linking to an image and writing this line:

So it’s been suggested that Bar Camp spread outside of Palo Alto. In fact, it’s been suggested that it spread far and wide, from the West to the East to across the pond.

How prescient is that?

And now we even have a theme song (thanks Derek!).

Well there you have it. Forty some-odd camps later and it’s come full circle.

So if you happen to be in the Bay Area, you know where you’ll be this weekend:

Todd Davies has put together a tremendous time, starting off with a BBQ today at 6pm. I expect to see you there!

P.S. Shirts will be for sale soon soon! Thanks Miles!

Alex Bosworth’s API tips

Alex Bosworth has some great pointers on building web APIs. We’ve been advising many of our clients on building out or planning APIs for their products and this advice is very much in line with our advice (we’re also partial to OpenID and microformats).

Oh, and if you forget your API or microformats at the door, Sebastian has developed a way retrofit your site with microformats using Dapper. How cool!

Follow up on the mousetrap

Apparently I could have been more clear in my post on the Google Authentication mousetrap, so here’s some additional summary points:

It’s not so much about lock-in as it is that Google can steamroll over independent competition because of their ability to integrate and cross-promote services. In the first bubble, they called this synergy and it’s not necessarily a bad thing. It’s better for users, but worse for upstart competitors.
As web apps become the norm, being able to move your data between them will become essential, and since almost all web apps require some form of authentication, you need to be able to share your credentials between these web apps to transfer the data.
Microsoft Word already runs on OSX and so you already can copy and paste data between it and Appleworks. My point is that that’s not the case on the web today. Because commercial use of APIs are restricted, you have to wait for companies to forge business deals before you get the kind of interop that you already have between different company’s desktop-based applications.
I feel that my view is squarely looking at reality — looking at what will happen if we don’t open up data formats and authentication protocols. I am placing my hope on microformats and OpenID — not because I care so much about the technology, but because until we have open standards for transferring data and open protocols for authenticating, it’s going to continue to be a disempowering situation for your typical end user. Like me.

The day Facebook stole the network

Marty Wells of Tangler (and a Citizen Agency client) has some great thoughts on Facebook’s usurping of MySpace’s opportunity to set the standard API of the social web. Basically, that Facebook came out with their API first means that they dictate the standard calls and features that everyone else will now have to offer parity with.

Joshua and the Delicious folks found themselves in a similar situation — delaying Flock’s rolling out of privacy in favorites even though Shadows had long since supported the feature in its API. And more recently, Ma.gnolia will be mirroring the Delicious API to speed up Flock integration. In the case of another incumbent, Photobucket mirrored Flickr’s API to push Flock integration.

In these and other cases, the sooner you go open, the sooner you reap the benefits. And, I have to admit, I’m happy that it was Facebook to make a move first.

American Idol for apps launches

Bottom line: Phill Ryu’s MyDreamApp contest launches — could the open source community take some hints from this exciting contest?

I got a chance to hang with Phill Ryu and a few other Mac dev types during WWDC and he told me about his soon-to-be-revealed plan for an “American Idol of Software”. Well, he’s let it out of the bag and ideas (and lots of coverage) are already starting to roll in to the project called MyDreamApp.

The rules are rather interesting, since they leave the creator only 15% of month-to-month sales, with the rest going to the contest’s organizers:

Payment. If Your Submission is Accepted, You will receive royalty payment via PayPal equal to fifteen (15) percent of the net income of the Apple Macintosh-compatible product developed by MDA based upon Your Submission. Payments to You will commence 30 days after the product makes its first sale and will continue at 30-day intervals provided that the product is profitable.

On top of that, the inventor retains zero ongoing interest in the application’s intellectual property:

Ownership of Submissions. (I) When You send MDA your submission, You are assigning MDA all rights and interests – including all intellectual property rights – in the Submission, and MDA shall be the absolute owner of all rights and interests therein;

For some, these issues aren’t a big deal and if your idea isn’t chosen, well, you keep the rights. Besides, this is pretty standard boilerplate legalese given most contest rules — and with some pretty decent prizes and an opportunity to show off your wares to folks like Kevin Rose, Guy Kawasaki, David Pogue, and Apple co-founder Steve Wozniak, it’s worth given up the IP rights for a chance at stardom… right?

Well, in spite of the hype, on the one hand it is. It’s pretty satisfying to see a bunch of independents and friends pull something together like this (though I didn’t realize how male-centric the Macdev community was!). It takes a lot of work and dedication to make this kind of thing happen, and so in some senses that 85% that they retain is a bet that the best ideas that come in will actually be lucrative enough to offset their efforts in organizing the contest.

On the other hand, and this should come as no surprise, I’d like to see something where the results are open sourced at the end (or at least given the choice of being open licensed), opening up the opportunity for more folks to get involved in the building out of a basic premise (and no, I’m not suggesting another centralized Cambrian House). In fact, I’d love to see the Mozilla Labs folks pick this one up and, I’m sorry to say this, but rather just than talk about it, put on your own DreamApp contest for the open source community and see what happens — hell, you’ve got the money, mindshare and, really, SpreadFirefox could use some love as the release of Firefox 2 approaches.

What better way to celebrate the launch of Firefox 2 then to sponsor a web-wide contest that results in something of real consequence for the open source community?

Building a better mouse trap

I’m struggling to make sense of something here. In Blogger’s announcement about its new beta was an interesting tidbit that didn’t get much pickup: Blogger now has a Google Data API.

There’s a lot that I could say about this, and my initial reaction was actually wrong. It seemed to me that Google was going off and inventing its own blog-publishing protocol, pulling the same NIH crap that it did with its non-standard Event Publisher API (using random values that don’t map directly to the international icalendar standard.

But, no, it turns out that GData is actually just Atom “plus some extensions for handling queries”, but branded as a proprietary Google format (kind of ironic, given the long and pained open development of Atom).

So whatever, Atom is what comes next after RSS and MetaWeblog (in particular as hAtom).

The important thing that started to dawn on me was this part of the announcement:

Authentication is fully documented for both Installed Applications and Web Apps
Your GData code should be easily reusable across other GData API apps, such as Calendar

So just as Yahoo had done with Flickr (inspiring a fairly wide backlash), Blogger is going to be fully absorbed into the Google Auth-borg. This continued amalgamation of services behind the Google Account Authentication has consequences beyond the momentary outcry over Google’s supposed steamrolling of companies.

Business is business and competition is a threat to any member of an ecosystem, which is why you’ve got to keep innovating, adapting and bettering to survive. But it’s different when it comes to setting protocols and standards and the seamless moving of data in and out of disparate systems. When those protocols are closed or locked up or can be sealed off at any time, the competitive environment becomes very different.

The problem that I see is Google’s ability to shut out third party services once you’ve imported yourself into the proverbial gLife. No doubt there are feeds and the aforementioned GData APIs but it’s not an open system; Google decides which ports it wants to open and for whom. Think you’ll ever be able to cross-post calendar items from 30boxes to your Google Calendar? Only if Narendra strikes a deal on your behalf — even though it’s your data. Think you’ll ever be able to share your Picasa Albums with your Flickr account? Don’t bet on it. Or — or — how about sharing your Google search history with your Yahoo account? Or merging your buddy list between Orkut and Flickr? Not a chance.

In simplest terms, with the state we’re in with centralized authentication in web applications, it’s like waiting for Microsoft and Apple to strike a deal enabling you to copy and paste from Appleworks to Word. And on top of that, you’d need to have to had created an account in both apps to even boot them up. So from a “normal person perspective”, this is a situation that you’d never want to have to worry about.

But that’s essentially where we’re at.

To put it in greater perspective: Web2.0 should have been the “great wide opening” — that is, where you could be in utter control of your data and move it in and out of services at your whim, just as you can with your money, in and out of banks depending on the quality and diversity of services they offer. And indeed, they’ve got to compete just to keep your business — if you leave, you won’t be stuck with a bunch of expiring pre-loaded debit cards.

But there’s a new trend, seen in Google’s spreading account authentication that foretells of the inevitable Passport-like lock-in that sunk Microsoft the first go ’round. You see, Google’s Account Authentication API makes it easy for you to add more and more of Google services by simply using your Gmail credentials. For Google, this leads to huge network effects, because they can essentially merge behavior data from across its entire network of services to build out a better picture of you — leading to a kind of competitive advantage that no one else can touch.

The problem though, both for you and for independent developers, is that you can’t pick and choose who or what Google works with. They’ll make themselves just open enough to be above reproach but not quite open enough to allow third parties to compete with them on their home turf (man, it’d be nice if there were a “Reply by Skype” link in Gmail — oops, Gtalk only!).

And this is how Google will build a better user mousetrap by leveraging its superior cross-product integration that its authentication system affords them.

(Aside: 37Signals partially benefits from the same kind of integration in typing Writeboards into Backpack but could go further by sharing accounts between different Basecamps).

Trolltech’s open source “Green Phone”

Raven pointed me to Trolltech’s exciting open source Green Phone project built on top of Linux with developer APIs for accessing GPRs location data. The possibilities of a phone like this in the hands of open hardware hackers is immense; the question is, will the carriers allow it?

A combined view of the world

In a post titled “The new Combined View and hybrid web/desktop apps“, Brent Simmons reveals that’s he’s starting to see the power of AJAX-powered interfaces in Mac apps, namely NetNewsWire (beta 3.0b7 now available).

Going one step further, he makes a very important observation:

The key to the whole thing is JavaScript. When something happens in the page—you click on a news item, for instance—the page calls back into the app, and the app tells the page how to update.

It’s kind of like Ajax in that way, except that the communication channel is not http and it’s synchronous (which it can be, since it’s right there on your machine).

And in that, he’s beginning to pull away at what very likely will become the next generation platform of the next revolution in web development.

For some time, people have gone on and on about the LAMP stack — made up of Linux, Apache, MySQL and PHP. It’s certainly a veritable and productive bundle of technology — if you’re always online. The truth of the matter, however, is that our local content stores don’t sync well with the remote stores… that my local LAMP don’t talk much with remote LAMPs. And in terms of offline productivity, that makes for huge dilemmas.

I’m seeing a third generation stack emerging that holds a great deal of promise for sewing up the future of offline-sync-online experiences.

That stack looks a bit more like Rails, SQL Lite (which the next rev of the Firefox bookmarks will be based on), Microformats, some blend of JSON/AMASS/jQuery/behaviour.js/scriptaculous/prototype and, yes, WebKit. What do they have in common? Well, enough inter-woven stickiness to make the heart of a true web geek start to murmur.

The missing link? The client and server OS component to tie them all together. Now, I’d love to see hAtom used as the data transport and storage mechanism in the OS. It would simply so much… but alas, it looks like RSS is the chosen son in the near term.

Why do I say that I wish hAtom were used for this purpose? Well, consider this. The language of the web is, for whatever you make it, HTML (and lately XHTML). This means that any webpage you visit, and indeed, any feed that you suck up, probably has some of this markup in it. In fact, rendering engines are getting better at both supporting web standards and as well as enabling some crazy cool things that you might not have thought possible before. All the while, XHTML is becoming the modern day ZIP format, able to store rich media as well as metadata about that data in microformats.

The browser is also constantly caching this data for you, in order to load sites faster and faster.

Now think about that: where are you doing most of your work in any given web app? Not surprisingly — in the browser! So you’ve got this cached version sitting on your harddrive with all the JavaScript, all the XHTML source, all the graphics and all the CSS, but nowhere to stick the data should you re-instantiate or open that page from the cache. Which is kind of ironic, since AJAX is all about asynchronous messaging… that is, sending messages non-immediately.

So, the thinking here is… if we’ve got this new “stack” at our disposal, it’s only a matter of time before we rewire our web apps to learn to write to a local SQL Lite store, using Rails as the delivery system, meanwhile storing the views and interactivity later, like Brent has done, in XHTML, CSS and JavaScript. In fact, most of the entire stack will end up as strictly JavaScript and XHTML storage unites once we see some diversification in microformat schemas. There’s no reason why you couldn’t save your bookmarks, your emails, your blog posts, your IM conversations, your documents, your financial records and the whole lots of content that means something to you in simple, basic, readable-everywhere, XHTML.

And so I appreciate, very much, that Brent is starting to see this — and the power that might be found therein — not just for him or for his app, but for anyone for whom the web and its online-offline machinations has caused great consternation. An XHTML-driven world, though potentially messy at first, offers a great deal of flexibility, of efficiency and of reuse and cross-polination.

If only I could get Brent to use hAtom… and if only I could get Microsoft and Apple to support hAtom in the OS like they all do for RSS… We’d begin to bear witness to the promise of this so-called “semantic web”.