Tag: Barcamp

So it serves me right that serendipity scooped me on this one, but I’d had this long post thing that I was working on about the Death of Web * Dot Oh but well, as it was boring and even longer than my other tomes, I never got around to finishing it. So I’ll summarize, since my point was extremely simple, if not pedestrian:

Whatever you want to call it, the point is, we’ve got some pretty decent technologies at our disposal now. And some of them are open, as in open source or open APIs. It’s about time that we stopped futzing around and built tools that worked for ordinary folks, yeh, the ones who don’t have time to live and breathe tech like the rest of us seem to. Most of the world is not like us (surprise!) and at some point, yes, we must break free from our autistic cocoon and realize, “Gee Spudsky, there are other people in the world who still don’t know what a web browser is. Well I’ll be. Dang nab it!”

(I probably should podcast that so you can hear the thick southern drawl on that endquote.)

Whatever, so that’s the premise and the treatise of my defunct rant: build good stuff with what we’ve got for ordinary, good people!

Um, so why do I bring that up? Glad you asked.

So I mentioned open tech stuff. Stuff that you can use without having to ask for permission because it’s granted or presumed granted or licensed that way. These are the tools of what’s coming next. (That which shall remain nameless. Grr.)

So what I want to do is two things. And I’ll be totally honest about this:

1. I want Brad Neuberg’s Coworking idea to spread. And I want it to succeed and take on a life of its own, just like Bar Camp has. Those things which are simple and seem to have built in relevance to a community will survive and flourish when given proper sunlight and water. Coworking needs that.
2. I want a venue and a space that I can go to and designhack with other skilled, interesting folks working on similarly interesting projects, where there is no ego involved, only the building of The Next; where there’s wifi, access to caffeinated beverages, chairs, tables, couches… and no distractions. Such an environment breeds innovation, breeds connections, friendships, revolutions. And when it can become distributed, plazeless even, you have a shot in hell at finding success.

So here’s the deal. January 17 we’re going to have a Mashup Camp at the Coworking space. No, it probably won’t be exactly David Berlind’s concept, even though he gets credit for blogging the idea first (goddamn procrastination!). Rather it’s going to be a day of intense GTD.

There will be 12 of us, mixed and mashed from a superlative cadre of geeks. It’s open to apply, but we’ve got limited space and time, so, 12. Anyway, we start in the morning promptly at 10am (after informal coffee, etc). We do brief intros, discuss our project, what we’re bringing to the table as far as knowledge, know-how and passion. We then break up into a couple groups based on what we want to get done and the utility of our offerings. …Spend the next couple hours drawing, writing, designing, architecting… getting to something with teeth but not code. Break for lunch and cross-polination.

Here’s where we could get tricky (it is a mashup camp after all). Maybe after lunch we play musical chairs with the projects. Y’know, mashup the teams? This means that the folks early in the day really need to be clear about what they want since it’ll be someone else’s fingers actually punching the keys and juicing the code.

Wait, do you mean that want a decent spec?

Uhm, yes.

Don’t worry, we’ll make something up. So after the mashing of people, a coding melee ensues and by the end of the day, we’ll have something. Scratch that, we’ll have a few things. Probably not all that pretty, but beginnings. And, I’ll tell you this in advance, one of the projects will be to construct the website that will host these projects moving forward… what shall become a proverbial open source treasure trove of mashups. Oh yes my friends, this is going to be good.

Ning, eat your heart out. No offense, but a bunch of passionate geeks in a room can run blindfolded circles around any prefab solution any day. Remember? this stuff is for real people. And for that, well, you’ve gotta have heart.

I’ve continued to read over and ponder the varied responses to Flock’s initial release of the public developer preview. While we’ve had an overwhelming amount of positive responses, we’ve naturally had our share of detractors. There’s much to be had from hindsight and given that we’re two weeks from our initial launch, I tend to agree with and find sobering many of the comments, criticisms and blogs that have been written so far.

In particular, Jeff Croft seems to have picked up on the crux of the so-called Flock backlash:

After reading bart’s comments, I think the problem here is that the Flock folks think they have a vision for the way a new kind of web browser can work, but most of the rest of us aren’t really “getting it.” I don’t know if they’re not properly communicating the vision or we’re just too slow to pick up on it.

He elaborates:

But I think people are comparing the grand vision Flock seems to have and the promise of “a whole new web” with the product that has been released — which just doesn’t seem all that revolutionary. Ultimately, there’s a disconnect. I’m left to this it’s one or more of the following:

1. The vision isn’t being communicated amongst all the hype.
2. The current version of the product doesn’t play out the vision, but users expected it to.
3. The Flock team’s vision just isn’t as “revolutionary” to me as it is to them.

This is really instructive and offers a good dose of reality from outside our little Silicon Valley enclave.

Jeff’s point is right on: we haven’t communicated our long term vision for Flock beyond a few quips about a more “participatory web” or one in which your browser helps you “talk back” to the web. Sounds nice and all, but where’s the substance of this thing? (While I’m on the topic, I might as well note that we’ve published our public beta roadmap).

It occurred to me that there are a number of things contributing to the current discussion:

1. We’re viewed as a Web 2.0 poster child (and subsequently pegged for representing many of the things broken about it). Following O’Reilly’s Web2.0 Conference it seemed that the phrase became a dirty word — as a catch-phrase, once it caught on with a wider audience it seemed to lose all relevance or meaning whatsoever.. Not like it makes much difference, but we’ve had a ban on the phrase in our office stemming from around the same time.
2. There’s talk of an impending bubble. It makes sense to rail against those things which smack of history repeating, doesn’t it? A Flock, unfortunately, appears to be part of the same lineage. I don’t think it is, but we won’t know for some time, will we? (Though some are already calling it game over.)
3. Open source projects don’t have launch parties. I’ll elaborate on this one.

As I’ve said, I think a lot of the criticism we’ve weathered so far has been somewhat warranted due to the disconnection between the general hype, where we see Flock going and with what we’ve delivered so far. But evaluating what we’re doing based on the difference between the expectations people had and what the developer preview represents isn’t a useful metric other than proving that the hype — and not the release — was premature.

Consider it this way: historically, open source projects often don’t do “product launches”, least of all when they’re just getting started. Furthermore, in lavishly launching our company at the Web2.0 conference, we generated confusion about the state of the product versus the incorporation of Flock, Inc. The company was ready for public consumption, the product was not, and we tried to make that clear (I mean, it’s not called a Developer’s Preview by accident).

But regardless, we were coming out to the world and saying that we’re building a revolutionary browser and oh, by the way, you’ll be able to play with it in a few days. Not the final thing, mind you, but an early release to give you an idea of what we’re doing.

The excitement built, the buzz became deafening, we were burning the midnight oil at both ends and sleeping in the office. And we didn’t get a chance to stop and consider, hey wait a sec, is everyone really going to be as excited about our code being released as we are? What expectations have been created for what we’re really releasing?

And in that, we missed a critical opportunity to take a step back to prepare people for the difference between what we were giving them to download and where we are actually going.

See, the way open source development seems to happen is that you get some kid tinkering in his college dorm for some time, building up a community of users that offer ideas and fix bugs. The project evolves and grows organically. It takes a long time and many person-hours, but ultimately costs little in the way of hard dollars. It’s a labor of love that depends on the selfless dedication of people around the world. Both WordPress and Drupal (among many, many others) have followed this model.

Now Flock took a different tact. In budgeting a project, Jason Fried typically offers his clients three options, of which they must choose two: good, fast or cheap. Flock chose good and fast, knowing that an investment in an open source ecosystem would both provide the means to improve our product and over the long term, actually keep our costs manageable. It might seem counter-intuitive, but this has been an intrinsic element of our strategy from the beginning. John Battelle summarizes the reasons why:

Open sourcing your IP and using open source technologies is no longer even trendy. It is becoming the decision you can’t get fired for. This is a techtonic shift that has been underway for several years. Proprietary software vendors that don’t adopt to this new world are road kill, pure and simple.

So when Flock launched, we were all psyched to be a funded startup working on a cool project and most of all, doing it open source. But somehow our enthusiasm for being open source caused us to lose sight of the part about ensuring that our product must also work well from the get-go, even if it’s pre-alpha primarily because people will try it out and make judgments about you no matter how hard you message it’s immaturity.

In hindsight, I don’t at all regret launching the Flock code as early as we did. It needed to get out there to start cultivating the open source community that will drive this project forward.

However, the next time I’m involved with launching an open source company, I’ll be damn sure to hold a few Bar Camps before migrating to the self-congratulatory bar crawl.

technorati tags: open source, flock