Ruminations on front end-centric webapps

I’ve been poking around firebase & meteor, and sparkleshare+github and dropbox+site44. I’m a bit disturbed (in a good way) by what feels to me like a sea change that’s happening there, and it seems to me that almost anyone thinking about web developers writ large needs to think hard about what this means for their roadmap.

In particular, a few brief thoughts:

I’ve been, for a while now, using sparkleshare + github pages with CNAME support as a way of making trivial static sites that are real. Sparkleshare is an open source git-syncing-to-filesystem client (with nice ergonomics and design, OMG!). With github-pages and CNAME support, this means that I save in my favorite text editor, and within _seconds_ the thing is live on the web. That’s a disruptive flow.

I’ve been coaching the harp.io team through WebFWD, and they have a service which does similar things on top of Dropbox, including coffeescript/haml processing, CDN, load balancing, push-button deploy, screenshotting for multiple user agents, rollback, etc. In other words, you author your webapp locally on a dropbox folder, and they take care of high-quality, high performance hosting. There is no app-specific server-side logic (which means you need to either have static sites or integrate with hosted services for said features).

I recently ran into site44.com, which does a ‘cheap & cheerful’ version of what harp.io does, with no push-button deploy/rollback, and much more like sparkleshare — instant deploy, with little management capabilities (but instant gratification).

Both harp.io and site44 use Dropbox for syncing, which is a Big Idea in my opinion because setting up Dropbox is so much easier than setting up git credentials (what with SSH keys, etc.). Both assume that the user has write access to local files (which may be a problem in some retrograde environments like enterprises and schools, but which could be solved with web-based editors).

I finally bit the bullet and dig in again into Firebase. Firebase is effectively a key-value store, with Pubsub messaging of data changes. They’ve made some interesting progress in their security and auth models (they include persona support, which is cool). Firebase feels like it makes it trivial to add state and real-time behaviors to previously static sites. The API surface area is quite small, so it should be fairly easy to adopt.

I’m also looking again at Meteor. Since they first launched w/ both fanfare and a bit of ridicule due to overhype, they’ve cleaned up their act significantly: the license is now MIT, they’ve announced $11M in financing from tier-1 VCs, announced an enterprise business plan to complement their open source offering, and build a bunch of APIs. Meteor feels like a steeper learning curve, and another “at-bat” for reactive programming (a topic I’ve been interested in for a decade).

Meteor feels like a solid foundation for a potential full-stack offering, and I like the open source option; Firebase feels like a really compelling basis for demoware and hacks. Regardless, syncing from filesystem to websites without thinking too hard about deployment is a huge benefit of front-end-driven sites.

Single-page apps feels to me like the conceptual next hurdle. Figuring out how to manage history and state management so that the app feels as dynamic as the best webapps, but has good URL support, etc., is an engineering challenge (see e.g. history.js). And it certainly challenges the old mental model of one URL -> one file which pulls down other resources. The newer model (especially on mobile, low-latency devices) needs to be one app -> many URLs, with one core application logic which pulls data-as-JSON and builds most state clientside (with serverside rendering as an optimization for high traffic or slow-CPU environments, as per airbnb’s post).

I’m not sure what this means for advanced webmaker skills. At the very least explaining some of the above to a broader audience is something we could do.

SaaS as a Service?

If you haven’t been paying attention (and really, most people shouldn’t), there’s what feels like a real trend where startups are breaking down common tasks for web & app development, and solving them through a software-as-a-service model. So, in no particular order, you can see

  • stripe doing payments
  • disqus doing commenting
  • firebase, pusher doing lightweight data & realtime updates
  • newrelic is doing deep resource tracking
  • geckoboard is doing dashboards
  • heroku is doing processs/service hosting, relying on a bevy of partners including many of the above for slices of value

There are lots and lots (and lots!) of new entrants that are following this paradigm, and from a developer’s point of view it’s both exciting and daunting.

Exciting because in the right combination, these services can be combined to deliver incredible scale and agility even to very, very small teams. (I have a fantasy of someday figuring out how large a 10-person project can be. It’s pretty large).

Daunting as well, because while when they can work well together in an app, they really should be thought of as independently moving (and failing) parts. And you’re likely not going to understand them as well as you should, or as you would had you built them yourself.

Which leads me to a friday-afternoon prediction: that there will be, over the next few years, a few companies who become experts at solving the coordination problems that arise from assembling so many disparate slices of value into an offering (whether for developers, or clients, or internally). And I expect that this expertise may not be purely technological.

I’ve seen how deep one has to go to get a real understanding of the security and privacy implications of relying on a third party for handling user data; I’ve seen the horrendous chain of dependencies that emerge out of security vulnerabilities; I’ve gotten a glimpse at the regulatory issues which some (soon more) folks will have to face. Dealing with high availability, geo-distribution, etc. all result in systems whose complexity scales in scary ways.

This leads to two thoughts:

  • If I were a wise investor, I’d look for those folks who look like they’ll find ways to integrate value in coherent larger slices, or mitigate the pain.
  • As a “product person”, I probably want to work on problems that require only a few slices, done well.

Said like that, I do get a “nothing new under the sun” feeling. Oh well, it’s Friday. MFBT.

Mentoring isn’t worthless after all!

I enjoy talking to young companies (or proto-companies) about their projects. I do that with a few incubators and the like, and I consistently find it rewarding. I find myself always trying to tweak people’s product vision a bit, looking for a way to turn a “business idea” into something that will have deeper, human value — not just because I think it’s the moral thing to do, but because if you’re “just working for the man” (even if you are the man), then when things get tough, it’s going to be hard to get up in the morning. When you’re doing something that deeply resonates with people, and which either relies on positive human qualities or strengthens them, then I’m confident that your odds as an entrepreneur are better. Also because there are plenty of mentors who will do a better job of getting your social viral marketing plan in shape.

Sometimes I wonder whether I’m the only one getting value out of our conversations, but this blog post reassured me that at least sometimes I have an interesting impact: Do you really need a server? Build your minimum viable product entirely client-side.

I’m particularly interested by the fact that I wasn’t really trying to force them to think about the privacy advantages of client-centric development (I realize it’s hard for budding entrepreneurs to make that a priority), simply going for the pragmatics of it all. I’m so glad it’s working out for them.

Volunteer-powered product development?

Over the last few weeks, I’ve had the pleasure of working with the small-but-growing team that’s building the software offerings that are part of the Webmaker effort.  If you don’t know about Webmaker, you should — go check out the website, and Mark Surman’s blog for more details and an inside view about why Mozilla’s doing it.  The really short version is that one of the major initiatives Mozilla is engaging on in 2012, apart from some of the already incredibly ambitious projects that you may know about (Firefox, Firefox for Android, Firefox Mobile OS, Identity, Apps, etc.!), is to teach the world that the web is not just something to consume, but something that everyone can help create.  In Mitchell Baker’s words:

“Mozillians are people who make things. Moving people from consumption to creation is Mozilla’s goal.”

Now, Mitchell’s words often inspire me (she’s probably the biggest reason I joined Mozilla full time), but this phrase in particular has been bouncing around in my head for weeks.  It’s also one that resonates deeply with many people I talk to, regardless of their degree of familiarity with the web, technology, Mozilla, open source, etc.

Now, the premise of the Webmaking software offering is both incredibly exciting and so ambitious as to be scary.  We want to reach large but diverse populations and find ways to make creating on the web both compelling for them, and fun/productive.  That means that we need both specialized tools, specialized content, and deep connections with whole new populations of Mozillians who can join Mozilla to build these offerings, bringing their passion, skills, knowledge, connections, etc.  We’ve already got great start in a few beacheads: kids/tweens, filmmakers, newsrooms to name a few.  There are many more on the roadmap.

Each of these slices of webmakers will require specific content, and likely tooling, which we think of as a “product.”  As an example, Thimble is a combination of a code editor (a tool) and learning projects (content) developed in partnership with a bunch of great organizations, aimed at giving people who don’t know anything about the web the first bit of a clue, and the first bit of a sense of agency over the web. It’s an early effort, that we built really quickly, but it’s showing a lot of promise.

Initial approach

We built Thimble v1 “the easy way” — a dedicated designer, a dedicated product manager, and a dedicated engineering team, working full-time over a few weeks, coordinating with professionals who themselves had well-defined roles and responsibilities.  It wasn’t really easy, but it was familiar territory for most of us.  We knew what to expect of each other, we could rely on the traditions of both open source projects for the “code”, and product development for the integration of the code into an overall “consumer experience” (although the word consumer is particularly ironic in this context). 

I don’t think we can expect to keep this approach and scale the way the Webmaking project deserves to. (Michelle Levesque thinks so too!).

Now, one might think that that’s what Open Source projects do, but I think in fact very few open source projects are run as products.  In particular, in my experience, a good product team has learned that code is only part of the equation — design, project management, writing, engagement, etc. are equally important, for which there is no equivalent to the code open source culture.  As an example, good designers, as a result of decades of abuse by clients, typically refuse volunteer work. There is no global culture around any of the non-coding skills (with a few notable exceptions, such as QA and localization, and most interestingly, the legal profession, who has incorporated pro bono work into its professional culture).  Now, Mozilla as a whole has been tackling all of these issues for years to support the main products (Firefox in particular), but even then we have not yet figured out how to gather volunteer contributions in many parts of the workflow.

I’m hoping that within the Webmaking effort, which I think is so compelling to so many non-engineers, we have another opportunity to refine our approach.  I used the title “volunteer-powered” rather than “open source” in the title because I think that while open source has a lot of lessons to bring in, it also has a bunch of antipatterns.  Forcing non-developers to think or act like developers isn’t the answer.

Question!

Here’s my question for the day: are there collaborative models of work in non-engineering disciplines where people have developed ways of working that I should be reading about or talking to people about? 

To make it more precise and hopefully a bit controversial: I fear that a lot of the tradition of “collective action” has its roots in cultural norms around equality, fairness, and making people feel good about their contributions ahead of all other values.  And as a result, in my experience at least, a lot of volunteer groups for example end up very pleasant and “nice” but lacking the urgency, the drive, the decisiveness, the ambition to kick ass in the market that turns ideas into shipping code that users love.

How can we combine the rapid pace, deliberate action, role assignments of a product team, and the openness to volunteer and part-time contributions of open source?

Story telling as a webmaking task

In a new-thing-for-me, I’m working with a group of four students from the Center for Digital Media as part of their Masters program, on a design-led project that ties to Mozilla.  Specifically, these folks are working on a project they call The Cucumber, which is (in my words), trying to make a tool that lets any traveler easily create a compelling micro-documentary about a place they like, using the tools of the open web.

At this point, they’ve done a bunch of thinking, blackboard sketches, paper prototypes, and more, and they’re making good progress, but they need your help!  In particular, they’ve got a hypothesis that by preparing a few templates and story-telling concepts, they can define a design framework that everyone could use to make something compelling.

If you’re interested, it’d be great if you could check out their questionnaire and do a “pretend story-telling” — think of a place you want to document, and fill in the form — it will only take a few minutes, and be very helpful to the team!

What’s the lesson?

I’m not supposed to be in front of a computer right now. I’m supposed to be attending the Vancouver premiere of Tiffany Shlain’s Connected, in a fundraiser to benefit A Human Right.  This looked like a fun event, for a good cause.  So I bought two tickets, one for myself and one for my 14 year old son, who seemed really interested in the trailer, and who I was pretty sure would both enjoy and get a lot from the movie & discussion.  I was happy for Mozilla to sponsor the event, promoting it.

But, this is Vancouver, British Columbia, in North America, a continent where lawyers and fear have way too much sway on policy and clearly no firm grasp of reality.  In this particular case, the problem is that the venue — the swank Vancouver International Film Festival’s VanCity Theater has the audacity to serve wine and the like to its patrons.  As a wine and movie enthusiast, that seems like a delightful plan.  But apparently, this very civilized offering is seen by regulators as implying that the location is evidently such a den of iniquity that my kid would obviously be irretrievably harmed by the sight of some adults having a glass of wine. Of all the things that I worry about as a parent, this doesn’t make the top 1000.

This was mildly embarrassing for all concerned, and led to my son and I going home early and having a conversation about the puritanical roots of the Canadian legal system rather than the much more interesting discussion that I expect would have ensued after the movie.

Such a waste.

Somebody let me know how the show went?