We then broke out into sessions. Most of my day was dominated by low level discussions of the protocols and formats that could shape the Federated Social Web. These include:

• Webfinger
• Salmon
• ActivityStreams
• PubSubHubub
• PortableContacts
• Microformats

Salmon FTW, Webfinger WTF

There was a session on private messaging. Blaine Cook proposed a method for subscribing to a feed which contains public and private entries. It used the From HTTP header, Webfinger and a Dialback to authenticate the request.

Next Bret Slatkin proposed a similar technique for sending a private message that used OAuth for authentication, which was much more complicated than Blaine’s dial-back method.

It turned out that these two ideas were Isomorphic. Then the term isomorphic was used about 20 times in the next 5 minutes. These ideas were seen as generalizations of the Salmon protocol. Speaking of which… Salmon’s public key crypto requirements were discussed as an impediment to adoption. The protocol has been simplified as much as possible, but many technologies have been doomed to obscurity due to the propeller head nature of properly implementing various schemes properly.

Account Manager and Contacts in Firefox

Dan Mills ran a session to ask “How can we change the client to make federation easier?”. There are some great notes. It seems like Michael Hanson’s XPrefs concept is needed to avoid a centralized broker like XAuth. Currently if you log into Identi.ca and visit Mozilla’s StatusNet node and you want to follow Paul Booker, you have to type in your identi.ca url as it can’t discover that your logged in to a valid OStatus node due to the same origin policy.

The importance of interoperability testing was discussed. I watched Evan Prodromou work with Diaspora team and I expect to see lots of work between Appleseed, Crabgrass, and other systems working together over these decentralized protocols.

Update: – The standard test we’ll work towards passing by Sept 30th is SWATv0.

This meeting was in Portland… check out the photos below for your Portland moment of zen…

If you do any of the following… you should consider yourself a member of the Mozilla Community:

• You’re passionate about a Mozilla project
• You suggest to others that they try a Mozilla product
• You’ve advocated on behalf of user control for privacy, data, and code
• You’ve explained why the Open Web is superior to proprietary technologies
• You help answer support questions
• You promote new releases of Mozilla products via Twitter or Identica
• You’ve uploaded artwork to the Mozilla Creative Collective
• You’ve entered a Design, Jetpack, or other Challenge
• You participate in a Mozilla Drumbeat project
• You install Firefox onto School computers
• You wear Mozilla t-shirts and discuss these ideas with your friends and family
• and many more

You don’t have to be a hardcore C++ programmer to be a Mozillian. Teachers, bloggers, and internet enthusiasts are part of the Mozilla Community also! It took me a long time to realize this personally. Let’s help the next group of community members realize it sooner.

The terminology “Stream” is no good and confuses everyone. Describing the project as a stream editing and publishing platform is a non-starter. More work needed here.

On the other hand, people would get excited about specific use cases such as a Mozilla profile page or research topic page.

Luis Villa was excited about the possibilities of giving people control over their online identity.

zwol had some ideas around deployment from version control systems instead of tarballs to help user’s keep their installs patched.

Guillermo Movia thought that sudoSocial was just like Feedly and that he should be able to search content for items. I really enjoyed Guillermo’s lightening talk and thought his graphitti Add-on idea is in a very similar spirit to sudoSocial… which is to get more Designers involved with creating the web.

Ryan Snyder liked the idea of owning your own data and suggested pushing the project towards the direction Tantek Çelik has gone with his blogging engine.

Anant Narayanan had a cool idea for people to create FamilyStreams by linking together sources from various family members, so they could keep in touch.

Lucas Adamski responded to the idea that sudoSocial is a middle ground towards MySpace and liked the idea that people can completely control the look and feel of their profile.

Atul Varma visited for awhile (which is an honor) and we did a bunch of brainstorming. We talked about how his “daily edition” tool could be re-built on a platform like sudoSocial. He brought up Howard Reingold’s work around having non-programmer students use Yahoo Pipes to create radars and dashboards. He championed the idea of pushing client side elements into sudoSocial to increase hackability. We discussed his Tweetblog experiment.

A common theme was that the name sucks. Join in and help name it. A related issue is that I’ve learned that it’s much better to talk about concrete use cases before talking about building a platform.

I wonder if the introduction shouldn’t focus on very specific ideas:

• A Mozilla profile page that you control
• A Homepage Elixir (drop in replacement for homepages)
• etc

The science fair hosted several other Drumbeat projects and it was a good chance to discuss the Drumbeat model.

Many users have started customizing their CSS. Two people I wanted to highlight are Turmel Antoine and Charlie November, who have created some pretty cool themage.

To make customizing your HomeStream easier, there is a new release of
sudoSocial. This 0.4 release brings a new tab in the editor
called “Page Widgets”. Here you can:

• Add HTML or Text around your profile
• Add HTML or Text around your stream
• Show/Hide the profile blurb
• Show/Hide the “Follow Me on the Web” list of links

Another change is that you can edit CSS directly from the “Design” Tab.

So let’s keep hacking on customized themes and sharing CSS/JavaScript with each other.
We’ll take the best themes and make them part of sudoSocial for non-technical users, kind
of like Personas for your sudoSocial stream.

Discuss themes and more in the Mozilla Labs sudoSocial discussion group.

Here are 4 applications that we’re not setting out to build:

A FriendFeed Killer

Cliqset, Jaiku, Google Buzz, Sweetcron, Pubwich, and other lifestreaming socialnetworks are pretty dope and I’ve followed this space for several years. I use them. I love them. But, it is possible none of these applications will ever achieve mainstream adoption, because they are hyper geeky. (That’s okay, it’s fun to live in the future).

Facebook’s “news” feature is a lifestreaming service for mainstream audiences. And they are killing it [sic].

Okay, kinda

I want to see more self-hosted lifestreams. I want to see them heavily customized by look and feel, through backend code, etc. I think that lifestreams could be the QBasic of the iPad generation.

A Facebook Killer

There is a lot of energy around creating a massive new suite of de-centralized, but integrated apps to replace Facebook. Candidates include:

• Dispora
• Elgg.org
• Noserub
• Appleseed

I’d put established projects like Status.net and Drupal on the short list of hopefuls. This is a very exciting space, but sudoSocial is from the unix tradition of small tools that do one thing extremely well.

Okay, kinda

I think we have to chip away at de-centralizing the web (Facebook Like buttons arggh).

Once decentralized socialnetworking standards are baked, sudoSocial simply has to honor and champion them.

0.1 supports OpenID and I’m looking forward to Salmon, XAuth or other cross application protocols for solving the Commenting and Liking problems.

If I could harness the energy around the Dispora project, I’d channel it into creating new social networking protocols for strengthening the OpenWeb.

A Google Reader Killer

Content aggregation is pervasive. Feed readers were the first killer app for syndicated website content. We are not trying to build one of these guys.
The cutting edge here is things like Feedly or TwitterTim.es which try to cut down on information overload. It’s done via metadata and algorithms to determine which entries should rise above the noise.

Okay, kinda

With the sudoSocial platform, it should be possible to create something like Atul’s daily edition, which is a private stream of must read entries.

Classic Lifestream Killer

I guess you can’t have a “Classic Lifestream Killer”, since that category has never had a 800 lbs gorilla. I’m talking about the Freeman/Gelernter style lifestreaming application, something like MylifeBits. It would organize repositories of your entire digital life. Not tryin’a build it.

Okay, kinda

You will (eventually) be able to bulk import and export your data from sudoSocial, so this might be a good net to start fishing for your lifestream with.

Why not?

Each of these 4 applications are a massive pile of work. To deliver a polished and usable product they are millions of person hours to build from scratch.

I’ve asked myself… What is a reasonably sized community project that could create a tool that doesn’t already exist?

We’ve got some amazing Free/Open Source web applications. I think a missing piece is a mainstream publishing platform for streams, which allow you to curate content from across the web. It’s a tool that would compliment a webstack built out of Wordpress + Disqus + Plone, etc.

What are the goals that shape this project?

• Promote the OpenWeb
• Empower Individual to curate and publish their streams
• Promote awareness of privacy issues
• Explore how to do Free/Open Source cloud computing
• Expand the diversity of the Mozilla Community

Wow, that is kind of a mouth full. Ya, trying to keep it small and simple.

Hey, But we should really build X!

This is what sudoSocial means to me, but I can’t do anything without your help. What strikes you fancy? Where do you want to take it next?

You can easily customize the CSS or JavaScript in the page. I also include Processing.js to help make the homepage hackable and easy to pimp out.

The name of the project is sudoSocial. It’s a play on two words:

• sudo – Giving you control of your social identity
• psuedo – a fake social networking site, counterfeit

Enough with the intro, check it out:

• Patty O’s homestream on sudoSocial.me
• “MySpace Fugly” example of a customized and embeded homestream
• Log in and publish your own stream

This is the very first release, so it’s buggy and incomplete. The ultimate goal is to build a stream editing and publishing tool.

Let’s Do This

I’d love your help and feedback!
I’m ozten on Twitter and Identi.ca so message me there.

How can I play?

Designers – The Design Tab of the editor lets you change the CSS url. Copy the default style and start tweaking. Upload your designs to your personal website and then plug them in.
Artists – Their is a Process.js textarea. Paste your Processing code into the box.
JavaScript hackers – The Design Tab also lets you change the JS url.
Application hackers The code uses the standard Mozilla tri-license.
If you want to hack on the project without setting up the environment, I’ve created a VirtualBox Appliance which is up and running the code. Download via Torrent (1Gb) and run it inside of VirtualBox.

I’m back from my first time trip to Austin Tx and SXSW Interactive.

My friend Jeremy Britton from Zurb Interactive inspired me to write up a post on the week. He also told me my cold is SXSW Sars.

Activity Streams Meetup

A highlight for me was the Activity Streams meetup. It filled a huge gap in my research when Chris Messina talked about Activity Theory in Is it getting Streamy in Here. Todd Barnard brought a first edition copy of Yrjö Engeström’s tomb to the meet-up. Mark Krynsky introduced me to Jyri Engeström and I felt like quite a dolt for not knowing this history. I’ve grabbed a copy of Acting with Technology: Activity Theory and Interaction Design and I’ll read it during my trip to Turkey.

Mozilla SXSW Happy Hour Party

Another highlight was the Mozilla Party. Unlike your typical cave dwelling hacker… I actually like some marketing activities and had a blast meeting people and handing out Rock Your Firefox t-shirts. The Jetpack for Learning Design Challenge was judged and it was great to meet the hackers. Brian and I finally met face to face and battled for our surname.

Speaking of hackability…

Webhooks / View Source Has A Posse

Jeff Lindsay gave a great talk about how and why you should integrate Webhooks into your web applications. This talk, in true SaturdayHouse fashion, was a jam session that covered all sorts of crazy topics. Some of the best ideas involved enabling the next gen programmers. Where will the BASIC of our next gen be?

It could be the web, because View Source Has A Posse. This was a great discussion on how 90% of internet programmers learned by tinkering. Copy and paste, although a crude first step, is a massively enabling technology. Focusing on performance and programming in the large really threatens the View Source culture. View Source tools need to catch up to deployment tools or we’ll end up with:

It’s like you open the hood of your car and there is another hood under there to open.

The talk was lubricated by Tequila. If any panel members agreed, they had to drink!

Networking while Rome is burning

Okay, I’m a big nerd and went to almost every 9:30am session and consumed talks through 5pm. I talked to dozens and dozens of people who caught one or two sessions a day. Hmm. Weird. I’d skips sessions for BOF and open space style sessions, but 1 or 2 session? I think I’m doing it wrong or SXSW is mostly about getting hammered. I’d rather go to a resort town for that kind of flow. Why be surrounded by marketers and 20k other people in Downtown Austin?

Don’t get me wrong, I’m no tea-tottler and had plenty of Shiner Bock, Austin Amber, and Karaoke till 3am Saturday night… I just still got my learn on most of the week.

This partying is a metaphor for our lack of focusing on what really matters.

Bruce Sterling had a great quote for SXSW. While there is global warming, a financial crisis, and other serious problems to tackle… we’re all walking around with iPhones and networking while Rome burns. A great and classic talk by Sterling, very witty and insightful.

Shiny, Shiny Add Privacy and Security Later

Sterling warned us of the future… where we live in the future we’ve built. ouch. The youth aren’t makers and don’t know what it was like, before we tore down the walls of the old world. They will whine, they will tear us down, and we’ll have to help them move forward without being bitter and grumpy. Ugh, sounds like fun.

He cautions that a world build out of small pieces loosely join will have plenty of rattling bones and bugs.

This was a minor but important theme through my SXSW. Jaron Lanier is both one of us (contemporary technologist) and one of these future whipper snappers, due to accidents of history. He gave a great talk explaining his ideas behind You Are Not a Gadget. The talk was good, because it wasn’t easy to listen to. I got really angry a couple of times and thought… my god this guy doesn’t understand anything about computers. Sadly he knows more than I ever will, but he’s also able to step outside of our status quo and try to keep pushing the ideals of Ted Nelson and to make sure Artists are getting paid and have a place in society. Extremely tough questions and problems.

Something that resonated in Lanier’s talk was that our software isn’t very social and that it’s incredible hard to be a teen in the Facebook world. There’s no space to reinvent yourself while you already crystallized into a profile page and defending your position in the pecking order.

Which leads into another challenger to blind technologists… Dana Boyd’s keynote was excellent. She talked about real world privacy gaffes and the underlying theory of why this happens. She pointed out that when implementing software, privacy isn’t a set it and forget it feature. We have to constantly pay attention to social norms, the interaction of all software features, and the nuances of the data we are exposing. A great example – making something that is public more public can be a violation of privacy was such a powerful reality check for me.

SXSW, and our larger tech world, is technologists running as fast as they can after the new shiny. That is what we do. We’ll add the privacy and security features on later… along with the business model. Gowalla and Four Square were buzzed to be the most important ideas at SXSW. Let’s chase the geolocation shiny…

Why are we letting 3rd parties collect this data? What is the long term value? For whom? Who do they share it with? For how long?

Context, Filtering and Search

I’m starting to get older. Doh. Now I see the patterns. Chasing the shiny leads to market leaders who flip their startups for big cash. Then these market leaders product will eventually get commoditized or won’t exist because they were built on short term value and there is no reason for them to exist. If we don’t focus on building real services with real long term value. So how could these location check-in’s be of short term value? Advertising, Johnson, Advertising.

The Making content relevant to me session had the best panel. Some key ideas:

• Hunch.com has correlated whether someone likes iceberg lettuce with whether they are Republicans or not and it holds for a surprising number of people
• They know if you’d switch from a PC to a Mac, based on if you’d like to dance
• Douglas Merrill talked about how hard it is to anonymize a dataset, as the Netflix prise dataset was de-anonymised
• Companies are sharing these datasets as Recommendation engines become SaaS
• Every search you make on Google is targeted via 200 axis so the ads will be relevant to you. Turns out geo data is much richer than cookies and HTTP referrers.

Also Sam Altman from the The Life Graph session stated that given 2 or 3 days of Four Square check-ins, you can identify someone with 90% accuracy, because the fingerprint of where people live and work is pretty unique.

I used Gowalla all week and am no Luddite. But we should pause and reflect… We’re building some amazing shiny tools, but to what end?

Synthesis

Lots of other sessions worth mentioning, but I’ll leave off with some ideas.

DEVO’s session was Ironic and revealing. They are devolved genius, so I’d expect no less. They are using all of these advanced marketing technologies to create their next album.

Lots of Open Web sessions. The open web is winning. We web developers missed the boat on the iPhone (before the native SDK) and we better get ready to throw down some View Source on the iPad. We’ve got to keep pushing for better tools and keep choosing open platforms over sterile ones. Why doesn’t the next Adobe Flash CS target HTML5? I meet a lot of potential customers.

Social Networks without SocialObjects are missing the point. Our SocialGraphs are an artifact, not the means to an end. We need to pay attention during every step of building something. We should be mining Sociology to build better social software instead of mining machine learning to build better advertising machines. To end with another Sterling quote: You should’ve open sourced food and shelter first!

The goal is to teach HTML. Hypertext Fiction, like the Choose Your Own Adventure book series, is a narrative with multiple story paths and endings. The web is a natural medium for this type of story. I’m hoping that teaching kids how to write hypertext fiction is a natural way to teach them how to create HTML.

A major impediment to learning the basics of HTML is all the web publishing cruft:

• Text editors
• Files
• FTP
• Hostnames and Hosting

All of this crap is an accident of history and seems like a big stumbling block, before you get to the juicy stuff of HTML, CSS, and JavaScript.

The approach I’m taking is to create a web application that paves over these four problems. The student will have create a short page name and then get an edit box. This gives them a body tag and let’s them create from there. Saving the page publishes it. Linking involves using the “short page name” of another page in your HTML code.

This workshop is only 2 hours, so I will focus on teaching hypertext fiction basics and the following HTML tags: A, P, UL, and LI. Students will use Sticky Notes and a whiteboard to coordinate the story and page flow.

I’ve looked around a little for a web application, but nothing is perfect, so I’ll probably write my own. R.Y.O.H is a clever new project, but doesn’t allow HTML coding and it’s quite a bit different than my wireframes. Wordpress is too distracting. Wikimedia is close but doesn’t allow HTML and I don’t want to just teach wiki markup. Do you know of a good hypertext fiction web tool?

I’m creating the curriculum online. I’d love feedback. I’ll post and link to more materials as I create them. Steal my work. Improve it.

What if you could directly edit the copy on the staging server of a website and have it transparently save your changes in the background without messing with PO files, SVN access, etc

You’d eliminate lots of problems that localizers have… and provide a richer, fun editing environment.

Like any idea worth building… I found out it’s already been invented A few months back when I pitched this idea to Stas Malolepszy, he mentioned that Gandalf already thought of the idea and built a prototype.

I’m realizing that this has been sitting in my TODO list for too long and I’m better off doing a brain dump in this blog post. Here’s my take on the idea:

Design Constraints:

Keep po files as the backing store
Work as much as possible with existing gettext tools
Use direct object manipulation for the UI - pick strings directly from page, see live updates

Requirements:

Let localizer view a web page and pick a string to translate
Display an editor widget that sit on top of or beside the page
Display the msgid and msgstr. In practice this is the English String and the Localized version.
As they type, redisplay the page with their updated translation
Provide a revert button
Provide a save button. Save persists this string back to the po file server which commits the change to SVN.

PO LiveEdit at 10,000 feet

PO Enhanced HTML – In PHP or other web code, instead of making calls to gettext methods, a set of wrapper methods would be used which add metadata to the HTML output. This would basically add the msgid to a span tag that surrounds the output of the msgstr. This would extra metadata wouldn’t affect the display, but would capture the semantics of a localized string.
Old PHP code
<p><?= _(‘Be the Difference’); ?></p>
outputs
<p>Fai la differenza</p>

New PHP cde:
<p><?= _w(‘Be the Difference’) ?></p>
outputs
<p><span id=‘md5_58cbc46092296cbe517d748685f52838’>Fai la differenza</span></p>

PO Edit Client - This editor would use the msgid or some other token (such as the md5 hash of the msgid) from the enhanced html, to retrieve the information for an individual string and display it for editing. The comments, English translation, and Current localization string would be displayed. The editor would be aware of the current locale which is a page. It would be a live editor where changes would be reflected in the web page as you type.

PO Edit Web Service – The server manages the collection of messages.po files for a web application. It’s provides read and write access to the PO Edit Client, one string at a time. It manages commits to SVN and conflict management. 

Technology:

So three are three components to build… PHP gettext wrapper libraries, which are pretty trivial and produce the enhanced metadata in the HTML, a Server and a Client which lives within the browser.

Server

Either a stand-alone python server using Stas and Zbigniew’s [https://wiki.mozilla.org/Silme Silme library], or integrated into an existing web based L10n tool like [http://en.wikipedia.org/wiki/Pootle Pootle], it would provide a REST web service for editing po files by locale and msgid.

Client

The client can be built as either:
Pure JavaScript included from the page
Addon – Firefox/Fennec Extension

Pure JS has the benefit of working with any browser (Safari on iPhone, IE 6 in corporate dungeon, etc). It has the negative affect of introducing L10n only code that you wouldn’t want to push to production. It adds another integration point to every app.

The Addon has the benefit of being totally isolated from the specific web application’s codebase, which makes for easier adoption. The client would have the ability to use the PO Edit WS without any same-origin policy limitations. Downsides are that it’s requires Firefox or Fennec and it is an extra step for localizers.

Either way, a simple textarea will be a good start for a prototype. Localizers will be loosing any features of their current text editor (say POEdit), but they will gain rich “preview”. For a prototype, the addon route could be built out of an existing extension, such as Jetpack Slidebar or Ubiquity pageLoad command, since it’s a more rapid development env.

Considerations:

The devil is in the details, here are some design decisions.

By default, does this introduce a new requirement for a L10n preview environment? Or is the web application in a testable state? Adding String metadata changes the web application and invalidates it for QA, unless you ship this metadata in the production version also. The ‘right’ thing to do would be to introduce a localization step into the SDLC, but this might lower adoption. Or you could focus on making the implementation of the String metadata really light weight, so it would have minimal overhead and not need an additional phase, since it could ship to production and other applications can invent new uses for this metadata.

Exposing hard to reach state: Many strings are hidden behind a hard to reach sequence… such as error messages. A common practice in web app development is to expose every part of the app through testing hooks. Many large applications grow these features through time, such as allowing testers special query string parameters for each error condition to simulate the error. Another example is web apps with emails; provide urls so that each email is a click away w/o actually running through the registration process. These kinds of hooks would make translation easier and you’d have to list them somewhere so it’s easy to find them all. These become a requirement for a live web editor, unless you make the user jump through steps to reach all the states of the UI.

Out of Scope(?) but on the Radar

A real-time synchronization between the client and server would be ideal, so that multiple localizers could see who was editing a string and to reduce conflicts. Mike Morgan and Fred have suggested Bespin which is a freaking awesome idea.

Wrapping up

If we had a web based live editor for translating sites, this could be a huge win for localizers and the people of earth. Translating a website is one of the most painful and dangerous workflows I’ve seen. You know we have an amazing community, if they are willing to put up with the draconian toolchain we have today. Throwing everything out, is simply not an option, but if we can make a small evolutionary improvement towards a live preview edit workflow which hides revision control systems and text files…

There are plenty of sticky corner cases and whiz bang features one can dream up, but I think building a prototype for this is a tractable problem. I did some brainstorming with Fred this morning and he had lots of other cool ideas and good observations on how this would work in practice.

Of course 100% of our code is open source, but we want to do a better job of letting others use and contribute to our libraries.

Screenshot of a typical project layout

A typical project

Let’s talk about a theoretical new project foomo which is the code behind Foo.mozilla.org. This project may reuse a couple libraries as well as host it’s own code. Let’s assume this is a project has the layout pictured to the left:

In bin we have various Python and shell scripts which are executed via cron or CLI. These scripts depend on the config directory for configuration and the lib for libraries of code. I won’t focus on the bin part of the project, but it could follow the pattern below, but using a Pythonic packaging idiom.

Let’s assume that the web directory houses a Kohana PHP project. Under the web/application directory there are typical these project specific directories: config, controllers, helpers, hooks, libraries, models, andviews.

In addition to application, Kohana also provides modules and system directories. Let say that foomo project reuses a Mozilla WebDev PHP library barlib library it will be located under modules. system is where Kohana stores it’s framework code that is overridden by modules and application code. But how do we manage foomo and barlib codebases?

Version Control

The authoritative code repositories for this website would be in atleast two places.
If we keep all the code for foomo under one project, say svn.mozilla.org/project/foomo, this makes it easy to deploy and manage. The mainline of application specific code would be changed from here.
The second codebase is for the library barlib. The mainline of development would happen on github.com/projects/barlib. Let’s look at the source code layout of foomo and barlib to see how they relate.

foomo's module directory contains barlib

barlib's project layout

So foomo’s web/modules/barlib on the left is a subset of barlib’s development tree on the right. A read only copy of this dist directory, heck even just a tarball distribution of it, comes from github and lands in foomo’s web/modules/barlib. As we want to enhace barlib, we work in that codebase on the right. barlib is it’s own project, so development includes running it’s tests, etc and then creating a release version to be imported back into foomo, on the left, as needed.

Keeping the official repository for reusable libraries separate introduces some disadvantages, but is worth it.
Disadvantages:

• More complexity and administrative overhead
• Requires more discipline
• You have to manage dependencies between libraries and apps
• Increases development costs

Advantages:

• Encourages Reuse
• Removes barriers for community contribution
• Makes QAing and releasing components possible

All Growed Up

As code in foomo solidifies or another project wants to use chunks outside of just foomo, the various pieces of code can be pulled out into a module and moved from web/application to web/modules/<library name>. We’ll have to re-QA foomo after this code extraction, but we will gain the benefit of reduced development on the second project and anyone who needs it won’t have to pick through foomo internals to copy and paste the tasty chunks. If the second project is a CakePHP project, then all it will need to do is write CakePHP wrappers analogous to the very this Kohana specific layer of barlib.

Everything Cannot Be Reused

Not ever line of code can be reused. A lot of web development is about crafting a very specific solution. Localization, error handling, and coding conventions introduce challenges. That said, we should spend the extra time it takes to publish and integrate dynamite WebDev libraries.