The Smarter Alternative to Email

Q&A with some of our users

2007-08-19T12:32:00.001-07:00

Some users (in Bangkok) had questions about Kerika's peer-to-peer model that we thought may be of general interest:

When a document is attached to an Idea Page, how it is transferred to the Kerika server: is the file transferred immediately or after some time? And is any data compression is used?

When a document is added to an Idea Page, all Kerika does it hold a pointer to the document – the document itself never moves. Thereafter, a "file watcher" process inside Kerika periodically checks to see if the file has been updated, and if it has, it sends the new version to the rest of the team.

Kerika is a hybrid peer-to-peer system, not a client-server system, so we don't automatically store anything at all on our servers. Here's how it works:
- There is a rendezvous server which helps each peer connect to every other online peer. Every time a Kerika user comes online, it checks in automatically with the rendezvous server, which keeps track of who is online and who isn't. If you update a document or Idea Page, and everyone on your project team is currently online, your computer sends the updates directly to everyone elses computer, where they are stored locally. In this scenario, Kerika has no involvement in the transfer, which takes place peer-to-peer.
- If, however, you update a document (or Idea Page), and some of your team members are not online, then your computer automatically sends a copy of the update to Kerika's storage server. When a Kerika user comes online, his computer automatically checks with the storage server to see whether there were any updates that he missed while he was online. Once he gets the updates that he had missed, the storage server automatically gets rid of the copy it had been storing. All of this happens automatically, so you don't have to worry about whether your team members are online or not.
- For greater privacy, you can run your own storage server, on any Mac or Windows computer you have with spare capacity and a fixed Internet connection, at no extra cost. Some users do this for greater privacy, since this means their files never go through our data center.
- In a peer-to-peer model, everyone on the project team has a complete set of project materials for every project that they are working on, which means that (a) you don't rely upon the Kerika storage server, and (b) there is no single point of failure. If someones PC gets trashed, they can recover all of their project materials by asking one of their team mates to add them back to the project.
Is there any limitation on size of the document?

No. This is one of the big advantages of the peer-to-peer model: if both users are online at the same time, you can share really big files.

Is it possible to give some project team members read-only access?

No. We used to have this feature in early beta versions, at the beginning of 2006, but we found that our users had a very hard time remembering who had read-only access and who had full access. We decided to create a true collaboration of peers model since this was easier for most users to handle.

One point to note: no one can really trash a project, or get ever get rid of anything that's on your computer. The worst that can happen is that someone rearranges items on an Idea Page in a way that the Project Manager dislikes. In this scenario, it is easy for the Project Manager, or any other member of the team, to move items around again. In practice we have found that the ratio of active people vs passive people on a project is highly skewed: within a group of 10 people there might be just 2 people who are active enough to arrange items on Idea Pages; the rest are happy to go along with whatever is presented to them. So there is less conflict in practice than you might expect.

Another point to note: if someone modifies a document, all this does is create a separate draft of the document which is automatically circulated to the rest of the team – it doesn't overwrite the original version, or anyone else's version. This is different from a client-server model with check-out/check-in, where you have to worry about people modifying the master copy.

In Kerika every person can make as many changes to as many documents as they like, without overwriting anyone else's copy, and Kerika automatically takes care of all the filing so that every member of the team has a complete set of documents. This lets the document owner see all the different edits that may have taken place, each in its own file, and then decide how to evolve the document going forward.

Finally: if someone deletes an item from an Idea Page, any other member of the team can restore it by using the Page Trash on his local computer. This is another unique feature of Kerika: it works like a distributed graphical Wiki.

So, on the whole there isn't a real need to create read-only access since Kerika's P2P model takes care of most scenarios where you would otherwise have problems.

Is it possible to send email (to all members) automatically with just the update info, not all documents, when ever project is updated?

No. However, please note that only documents that were recently updated get sent in the email updates. If only the page layout was changed, or only the team members list was changed, then no documents get sent.

Is it possible to add Web URLs to Idea Pages?

Yes, just drag-and-drop any Web URL from any browser (IE, Firefox, Safari) onto any Idea Page. After you are done, right-click the URL on the page and rename it so it has a more user-friendly name (e.g. "Kerika's site" instead of "http://www.kerika.com/")

Version 1.2 in beta test now

2007-08-13T10:16:00.000-07:00

We have been beta testing version 1.2 with a few selected customers, and hope to release it in the coming days once we get the final OK from the beta users.

This version will have some significant new functionality:

Mac users will be able to add "packages" to Idea Pages: some Mac applications, e.g. Keynote, OmniPlan, Pages, etc. save user documents as "packages", which look like files but are actually folders. Previously, Kerika would handle only ordinary files, which meant that Mac users couldn't use our great document management features when sharing documents produced by these applications – but all that will change with version 1.2!
As a happy consequence of adding this new feature, version 1.2 will also let you drag-and-drop entire folders (directories) onto your Idea Pages! So if you already have a bunch of files and folders organized for a particular project, you can now import the whole bunch with a single action by dragging-and-dropping the top-level folder. (This benefits everyone, not just Mac users.)
Finally, in order to effectively allow users to share packages, we had to change the way Kerika sends files from one user to another: with version 1.2, these files will get zipped up and then chunked (i.e. broken into smaller pieces) before being sent, which should mean better network performance and improved privacy.

Zipping the files before sending them is a big change in the software, and it means that once we release version 1.2, all users will need to upgrade to the new version because it will not be possible for a version 1.1 user to correctly process files sent by a version 1.2 user.

We realize this is a disruptive change, and it isn't something we like to do on a regular basis, but adding these new features was important to a large segment of our user community. We would stress, however, that the need to upgrade doesn't mean you will lose any old Idea Pages or other data: all your old information will get imported automatically.

If you would like to get an early peek at this new version, please contact us.

TheFunded

2007-08-06T22:17:00.002-07:00

Just joined this web site, which restricts memberships to entrepreneurs. Apparently it's been around a while, but I just learned about it (and that's because we haven't really tried raising any money in the past ;-)).

Lots of inside dope on VCs, from the entrepreneurs point of view. Most VCs have a queasy relationship, at best, with this site: they hate the idea of getting ranked! Which kind of reminds me of another startup in town, called Avvo, which is pioneering the ranking of lawyers, and lawyers hate the idea of being rated just as much, or perhaps more, than VCs.

Avvo's database of licensed attorneys includes this distinguished gentleman, who is urged to log in and update his profile. I hope TheFunded is nearer the mark!

Clueless in Kansas

2007-08-05T13:05:00.000-07:00

The alligators at McKinsey

2007-08-05T11:35:00.000-07:00

A number of people I knew in high school and college joined McKinsey: smart, ambitious, and – I had always assumed – upright and moral people. Reading this story at Bloomberg makes me wonder just how they turned out...

Why we chose JXTA

2007-06-28T15:49:00.000-07:00

In my last blog posting, I talked about why we decided to build Kerika using Java, and how that experience turned out for us.

The other key decision that we made mid-way through our product development was to switch from a traditional client-server model targeting large enterprises to a more flexible, inexpensive peer-to-peer system that could be made available as a inexpensive subscription service.

We concluded that we had a better market opportunity among small professional services firms than with the Fortune 500, since the latter would have entailed much higher development costs, a much longer sales cycle, a much larger support organization, and much more competition. In other words, much of everything that we wanted to avoid!

For the peer-to-peer networking, we turned to JXTA, another open-source technology that had originally been developed by Sun Microsystems (under the guidance of the great Bill Joy, no less!) There were several reasons for using JXTA:

The overall architecture made a lot of sense: in fact, we had independently designed our own peer-to-peer architecture along the same lines before finding out about JXTA, such as using rendezvous and relay serversto implement a hybrid rather than pure peer-to-peer network.

A pure peer-to-peer network is rarely practical in collaboration scenarios, since communication cannot take place unless both parties are online at the same time. We wanted to connect people working in different time zones, or simply according to different work schedules, so a hybrid peer-to-peer architecture was important, with a storage server kicking in automatically when you need to send messages to a team member who isn't online.

The hybrid P2P architecture gives Kerika's users the best of both worlds: P2P's ability to quickly transfer large files directly from one computer to another, when both parties are online, and the store-and-forward reliability of email and other client-server systems.

JXTA was written entirely in Java, which meant we would have an easier integration job than if we had chosen a different protocol, such as Jabber, and the Java implementation also meant we could stay true to our cross-platform vision for Kerika.

JXTA looked like it could better handle large files and more diverse message types than other protocols, which was important for Kerika. JXTA's weakest point was in handling voice traffic, but this was not a design feature for Kerika so this weakness was not very relevant.

After hearing from our users, during our beta trials last year, that privacy was an important consideration, we went one step further and packaged up our storage server for use by our customer – at no additional cost. This enables our users to create private networks, i.e. a ring of trust that secures their data more thoroughly than they can get from any Web 2.0 free service like those from Google.

Why we chose Java

2007-06-28T13:37:00.000-07:00

We made a key decision early in Kerika's product development to use Java and develop a true cross-platform collaboration system, although it would undoubtedly have been cheaper and faster to build a plain old .NET application that ran only on Windows. There were two strategic reasons for choosing the harder, but ultimately more rewarding, path:

Our vision was always about bringing together distributed teams regardless of where people are located or what sort of computer they are using. This narrowed our choices to Java, Flash, SVG, C++ and C. (Neither Python nor Ruby would have given us the user interface richness we considered essential for Kerika's success – at least back in 2003 when we made our language choices – to have been serious contenders.)

We opted for Java because we believed that it was the richest cross-platform language available, one that would allow us to build an elegant user interface:
- Using C or C++ would have resulted a lot of platform-specifc coding for the graphics and file management: in other words, we wouldn't be building a cross-platform application, but rather building the same application repeatedly, and painfully, for each platform.
- Using Flash or SVG would likely have given us a great user interface, but there was, and remains, a dearth of programmers who are proficient in these platforms, which would have made recruiting a harder task, and, more importantly, there wasn't a rich ecosystem of third-party and open-source tools for Flash and SVG.
- Using the .NET platform would have resulted in Kerika looking like just another WinForm application – in other words, looking like all our clunky competitors!

We were also mindful of the need to compete with Groove, and since Groove was very much a Windows-centric application – even before they were acquired by Microsoft – we needed to find terrain that would favor us should we have to go head-to-head with Groove.

Although Ray Ozzie would occasionally make noises about creating a Mac version of Groove, we were fairly certain that this wouldn't happen, because the longer you develop a Windows-only application, the harder it becomes to retroactively make it a cross-platform software.

Our biggest concern as we started down the Java path was simple: was Java really going to be a build once, run everywhere application, or would it turn out to be a build once, debug everywhere application as skeptics warned us?

Our conclusion, after having written over 100,000 lines of Java: Java is really a build once, run everywhere platform!! We did find some minor glitches along the way, but these were almost always the consequence of two factors:

Using third-party tools, particularly open-source code, that hadn't been properly tested in the first place.

Trying to integrate platform-specific C or C++ code using the Java Native Interface(JNI).

Our own code, as well as code we got from more robust sources likes Piccolo, was worked just fine on multiple platforms. In fact, we were able to create a truly distributed team, with individuals programming on Windows, Mac or Linux according their preference, and then pull everything together as a single set of Jars. We do all our builds on a Mac, create installation packages for Windows and Linux, and then test all three versions simultaneously.

And it all just works...

Microsoft Entourage causing sign-up problems

2007-06-19T11:29:00.000-07:00

We have had sporadic reports from users who were unable to sign-up for Kerika, mainly because the confirmation email they were getting contained a bad Web link (URL). We have traced the problem to be coming from Microsoft's Entourage email client on the Mac.

For some reason, Entourage is trying to interpret some part of the Web link as a HTML display tag. In other words, trying to be too clever.

We will have to figure out a way to code around this problem...

Update June 21, 2007: we have fixed this problem!

Help Wanted

2007-06-18T10:18:00.001-07:00

Users who like our product, and particularly people who like our customer service, frequently ask us how they could help us in our efforts, and our answer is always the same: help us get the word out about Kerika, the world's greatest graphical Wiki application!

Much of our effort and resources continue to be expended towards product development and support – and, to some extent, legal services, e.g. our patent applications – which means we have little to devote to marketing. Our greatest challenge at the moment, therefore, is to get the word out, and that's how you can help!

The Rip Van Winkle effect in Kerika

2007-06-18T01:23:00.000-07:00

A user writes in:

Sometimes when wake my laptop I get a dialogue suggesting that Kerika is trying to connect to a gmail account. Can you say something about what is going on as it looks rather suspicious.

The dialog box looks like this:

Here's whats happening:

Remember, Kerika is a peer-to-peer application, which means that your machine connects directly to every other Kerika user who happens to be online. (This is similar to how other P2P applications work, like Skype and instant messaging.)
The way your computer finds every other Kerika user who happens to be online is simple: when you start up Kerika, it automatically checks in with the central rendezvous server that we maintain at our data center.
The rendezvous server lets your Kerika know who else is online, and how to reach them (i.e. their IP addresses). If you look at the Network Status area, on the lower-right corner of your Kerika application window, you will occasionally see these messages go by as your Kerika connects with other online users. However, the IP addresses of other Kerika users are never shown to you!

So, let's say you have been running Kerika for a while. While you were active, Kerika was keeping track of other users as they came online and left. But when your computer goes to sleep because of inactivity, things can go awry and it could end up waking in a confused state:

While your Kerika was asleep, some of the other Kerika users may have gone away. But your Kerika missed these goodbye messages while it was sleeping.
Also, the connection that your computer was maintaining with our rendezvous server was dropped because the rendezvous hadn't hear from your computer in a while and assumed that you had gone away.
So when your Kerika wakes up, it may find itself in a confused state, just like Rip Van Winkle waking up from his long sleep: things aren't as they were before he took his little nap!
Some users that he thought were around don't seem to be responding to him, and even the rendezvous server seems to have disappeared. Oh, dear! And like old Rip waking up, Kerika can sometimes be a little incoherent until she gets her bearings.
The best thing to do in this situation is to simply restart Kerika: that will quickly synch up your machine with the rest of the world.

These error messages are quite rare, and obviously not very helpful in this particular context. We can try to eliminate them in a future version of Kerika.

Update: our user wrote back to ask another good question:

Thanks. I'm intrigued how this scales. If you get a million or so customers online does my client end up caching a table with a million or so email address/ip address entries although the community I am sharing with might only be a few tens of people?

The answer is No, because of the way JXTA works: you can set up several rendezvous servers, each of which knows how to connect to the other rendezvous [OK, I admit it: I don't know what the plural of rendezvous is...], either directly or through another rendezvous. Right now we don't have a million or so users, so we have just a single rendezvous ;-) but as we scale up, we can add more rendezvous.

Another feature of JXTA that we haven't fully exploited yet is the ability to create private groups. Right now we have just one big private group for all Kerika users; in the future we could create more fine-grained groups that create mini-communities.

Marketing advice from Tulsa, Oklahoma...

2007-06-13T22:31:00.000-07:00

David Walker from the Tulsa Java Developers community very helpfully pointed out that we were doing a rather poor job of telling our Web site visitors that the Kerika software is actually available free for stand-alone use – we charge only for the value-added service that comes with being connected to other Kerika users:

Sharing your projects with other Kerika users, and all the good stuff that comes with using the world's first (?) graphical Wiki application: sharing content in context, sharing large files, keeping everyone on the same page, etc.
Sending project updates by email to people who don't use Kerika: which is one of the killer features in our new version.
Setting up a private network, which is another killer feature in v1.1 (we have people trying this out right now in the US and Europe)

We have updated the sign-up page to clarify this point. Thanks, David!

Shorter Demos = Better Demos (I hope!)

2007-06-09T21:48:00.001-07:00

We have a large number of Flash demos available, mostly because we hope these can serve as tutorials for users who want to learn more about a particular feature. These demos were all built using Wink, which is a fairly simple, almost low-tech tool for building Flash demos. (It is available free for Windows.)

Building demos is tremendously time-consuming: a 2-minute demo could take several hours to put together using Wink, if you want to do it well. When you are trying to showcase a collaboration tool like Kerika, part of the challenge is figuring out the exact storyline you want to have in a demo, and then setting up different machines to play their parts in developing this story.

For example, if you are showing how to share a project, you need to set up the project, set up the other machines to simulate other Kerika users, and then carefully walk through the process of capturing the action. You end up with a tremendous amount of screen captures because Wink, by default, captures 4 frames per second. And if you are not careful Wink's memory consumption can kill your PC altogether leaving you empty-handed!

As a result of frequent use I have become fairly adept at using Wink, and we have customized it somewhat to match Kerika's color palette and style. The problem of editing down the hundreds of frames (screen captures) to make a coherent, smooth presentation is still a very time-consuming one. It is possible that some of the more professional tools make some of this easier, but the top-end tools from companies like Macromedia are not only expensive, they can also be very intimidating for newbies.

After spending all these hours and days getting our demos ready, I hadn't really considered that perhaps our demos were too long-winded, in part because I had always considered them to be tutorials as much as marketing collateral. (And this was undoubtedly a mistake in hindsight because tutorials and marketing collateral are intended for very different audiences.)

It was only in the past week that I realized that our most important demo, the Overview, was way too long to serve as marketing collateral. It turned out to be the longest of all our demos since it clocked in at over 8 minutes.

I spent the past couple of days timing each demo's duration (which I had never really done before), and then editing them as ruthlessly as I could to make them shorter. I hope the results are worth the loss of frames: each demo is approximately half as long as it was before!

I have also created a new Intro demo which I hope will work better as marketing collateral, particularly for first-time visitors to our web site. This is a hacked-down version of the Overview demo, and it clocks in at 2 minutes and 45 seconds... (Do you think this is short enough?)

Adding Keynote and Pages files to Idea Pages

2007-06-08T19:53:00.000-07:00

We just found out about a new problem: if you add Keynote or Pages documents to Idea Pages, you cannot open them from within Kerika by double-clicking on them, in the way you can open other files (e.g. Excel spreadsheets). In fact, Kerika cannot handle Keynote (.key) or Pages (.pages) files very well, and unfortunately this is not a problem that we can't fix in the short-term. (This problem was reported by one of our users, who therefore qualifies for the bug bounty.)

Here are the gory details for those who might be interested:

Kerika's document management system was designed only to handle files. Some fileson a Mac, e.g. Keynote pages, are actually folders. When you add these to an Idea Page, you cannot open them by double-clicking them – as you could with other files, e.g. Excel spreadsheets.

We don't allow file folders to be added to Idea Pages because we don't have any good way of knowing when a "file" that's actually a folder has been updated. (We need to know that a file has been updated so that we can automatically send the new version to the rest of the team.)

You might think that knowing when a file has been updated is a simple matter: just take a look at the timestamp or the size of the file and see if it has changed. That's true in most cases, but not all, and the problem gets particularly difficult when you are trying to create a true cross-platform application like Kerika that provides the same level of functionality on Windows, Macs and Linux.

The problem is actually with Microsoft Office files on Windows, at least with Office XP (and possibly later editions). Microsoft Word, for example, uses a bit of padding when it saves your document. So if you make just a minor change to a document, e.g. add a word or two, the size of the file – as it shows up on disk – may not change at all because the extra words you added were accommodated within the extra padding that Word used the last time it saved the file.

With Microsoft Excel, on the other hand, there is a different problem: as soon as you open a spreadsheet using Excel, the timestamp on the file immediately changes – even if you haven't made any changes to the file. So if you open a spreadsheet and keep it open for a long time, during this time the file will appear to have been modified – at least from the viewpoint of the timestamp – even though you haven't made any changes yet.

As a result, you cannot rely upon either the timestamp or the size of the file to be sure that it has really changed since the last time you took a look at it – at least for Office XP documents, which are a big chunk of all the documents that our users deal with on a daily basis.

So Kerika does some more complicated stuff with digital signatures to figure out whether a file really has been modified, but this method would not apply very well to folders. Hence, the decision to not allow users to add folders to Idea Pages.

Fixing this problem is possible no doubt, but not something we can do in the short-term, which is why this has been added to the list of Known Problems. (And our intrepid bug finder gets the bug bounty!)

Saying goodbye to the girl...

2007-06-08T11:31:00.000-07:00

The picture of the little girl that featured in our "About Us" page is going to be replaced soon with something a lot less fun... We always liked the picture, because it seemed to capture a sense of fun and adventure and optimism, but it was becoming a bit of distraction (too many people asking too many irrelevant questions), so I guess we are going to have to look more "corporate" now :-(

In the Wikipedia

2007-06-04T13:56:00.000-07:00

There's an article on Kerika in Wikipedia; check it out.

Free Software, Free Beer and a Free Lunch

2007-06-01T10:07:00.000-07:00

The folks at GPL like to describe the open-source movement as being about providing "free software – free as in free speech, not free as in free beer".

And how should we describe the "free software" that we get from Web 2.0 hosted services? Would that be "free as in free lunch"? Only if you believe in free lunches:

Microsoft has begun combining personal data from the 263 million users of its free Hotmail email service – the biggest in the world – with information gained from monitoring their searches.

"We're in the early days of behavioral targeting but it's an idea whose time has come," says Simon Andrews, chief digital strategy officer for WPP Group's MindShare, a large buyer of ad time. Wall Street Journal

And we are not just picking on Microsoft...

Eric Schmidt, Google's chief executive, said last week that being able to acquire more personal data was a key element in the company's expansion plans. Financial Times

Or pretending to be the smartest guys around: Kerika has a very useful feature called the storage server: it automatically holds project updates for your absent team members. In other words, when your buddies are online, they get their updates directly from you, and when they are offline, these get stored on the server. Pretty cool, huh?

Cool maybe, but not smart enough: we found, during our beta trials last year, that a privacy backlash was already underway, and some people hated the idea that their content would sit on our servers, however briefly – even though we didn't serve up any advertisements, use cookies, or do anything else to track usage and behavior!

So we decided to create your own private networks: a "ring of trust" consisting of just your team's computers so that no one else gets hold of your content. Once you set up your private network, all your messages (project updates, files, etc.) go directly from one team member's computer to another: they don't go through any intermediaries, and if any of your buddies are offline, their messages are stored on your private server.

And what's more, we offer this free to all subscribers, even trial users. On the other hand, if you believe in free beer and free lunches, just sit back and relax, it won't hurt a bit...

We recognize that seeing ads based on the content of an email message can be unsettling at first. Our experience has been that this feeling recedes as users become more familiar with Gmail. Gmail's privacy policy.

Bug bounty

2007-05-31T14:37:00.000-07:00

We did about 3 months of testing on version 1.1 before announcing it to the public, but there are still a few bugs in there: some of which we know about, and some we haven't come across yet.

I have been offering a "bug bounty" to people who help us find bugs: 2 months of free Kerika service. The bug can be anything, from a design flaw (something turns out to be awkward to use) to a software bug (something doesn't work).

Today, for example, we found out from one of our German users that we have a bug in our registration process: we are not handling extended alphabetic characters, such as umlauts, properly. This isn't something we had found in our testing because we don't have non-English keyboards and it never occurred to us (typical geo-centric Americans!) to test extended characters even though these are very common in European languages.

(And for techie types who want to know how we fixed this problem: we are using UTF-8 encoding to make sure the Java code on the server can correctly read the XML input from the Web site's PHP sign-up code.)

UNIX: A Personal Retrospective

2007-05-27T10:37:00.001-07:00

I first started using UNIX at university back in 1980: it wasn't the first operating system that I had used – I had also programmed on an ICL 1909 and a IBM 360, but UNIX was definitely the first operating system that seemed to me to have a distinct identity and shape: something you could understand and get your head around.

UNIX had been developed at Bell Labs back when AT&T had neither interest nor mandate to get into the commercial software business, and so they made the software available free to the academic community. (In the old days, AT&T was guaranteed a 15% ROE by the government by virtue of being the national telephone monopoly, and as a result was constrained in terms of entering into new businesses.) One consequence of this lack of commercial interest by AT&T was that UNIX was essentially open-source from the very beginning.

The "open-source" aspect of UNIX in those pre-Internet days seems very quaint today: magnetic tapes containing the UNIX distribution and other goodies went around from one university to another. When a tape arrived, the smartest Comp Sci student around would grab the latest stuff off the tape, add any local contributions, and then send the tape on to another university.

Students and researchers would make little (or large) tools that they would dump onto the tape and pass along to another university. My personal favorite was "fred" (for "friendly editor"): a modified version of "vi" with an extended set of commands and improved UI.

Looking at the gigantic ball of code that is Windows today, what seems particularly remarkable is that in the early 1980s is that we had a very strict, highly circumscribed definition of an "operating system". Only the UNIX kernel was considered to be the OS; everything else, including the shell, was considered an add-on or tool. The kernel had to be mean, lean and clean at all times: a high-performance, highly reliable platform that would leave all the user interactions and functions to the applications and tools.

This provided a lot of flexibility: choosing between "vi" and "fred", or, at a more fundamental level, between the original shell and the new-fangled Korn shell was easy and non-destructive to your fellow user. It also provided a lot of stability, since it was difficult for any single application to crash the entire computer.

My first full-time job was as a UI developer at Bell Labs. All of our work was done on UNIX, using Vax 750s from Digital Equipment. I don't remember what their specs were, but given Moore's Law it is probably safe to assume that they collectively had less horsepower than my cellphone today.

Bell Labs was a great place to work if you were into UNIX and C coding. The atmosphere was very relaxed, more like a university campus than an office, and you had access to great talent. I still remember attending a lunch-time lecture by Richard Feynman; his opening remarks were: "I am going to assume that everyone here is familiar with advanced quantum mechanics..." A bunch of people immediately left the lecture.

And here's a piece of trivia that I picked up at Bell Labs: when Ken Thompson and Dennis Ritchie wanted to work on building a new operating system, they needed to come up with some sort of business justification for the project. At that time AT&T was filing patent applications at a furious rate – they were averaging one patent grant per business day! – so they had a critical need for a good typesetting program with which to lay out their patent applications.

Thompson and Ritchie proposed to build a new typesetting program called "roff" (which later became "troff"). This was approved. Thompson and Ritchie then proposed to build a new operating system to better support the new typesetting program. Since the typesetting program was considered essential for dealing with all those patent applications, they got the go-ahead to built UNIX.

For a while the official raison d'etre for UNIX was that it supported AT&T's patent filings. This quickly changed once people realized that UNIX was small, high-performing, and very stable: in other words, ideal for the new super-fast switches that AT&T was building.

So, even as we take sides in the great Microsoft vs Linux Patent Debate, it is worth remembering that it was AT&T's need to file patents that helped give birth to UNIX in the first place... (And without UNIX would we have Linux today?)

Tools for a Distributed Insurgency

2007-05-25T15:19:00.000-07:00

What might be good tools to support a "global distributed insurgency"?

There are two scenarios to consider: a public insurgency and a private one. A public insurgency acts in the open and reveals its tactics, strategies, doubts and confusion to all, including the adversary. A public insurgency makes it easier to recruit supporters and activists, and if enough people get involved the insurgency could quickly develop momentum.

The big disadvantage of a public insurgency, of course, is that the information sharing is entirely one-sided: the insurgency reveals everything while the adversary reveals nothing. Thus, we know that open-source software violates 235 of Microsoft's patents, but not if any Microsoft software incorporates open-source code.

Public insurgencies can be started a blogger's call to action, and the blog can subsequently act as a rallying point for a movement. Here are two political examples: (a) conservatives trying to kick a Republican Congressman off the House Appropriations Committee, and (b) liberals trying to stop funding for the Iraq war.

While blogs could help initiate an insurgency, they cannot guide them very well. There is often only a single blogger, with the rest of the world confined to commenting on individual postings (or other people's comments). It quickly becomes very difficult, if not altogether impossible, to follow the various conversational threads that exist in the stream of comments.

Another option would be to combine a blog with a Wiki, as the folks at Digital Tipping Point did with their "Sue Me First" Wiki. Wiki pages are good tool for public insurgencies, since they are easily accessible, open and inviting by design, and can accomodate a variety of projects.

But what if you wanted to create a private insurgency, one where you tried to bring together a distributed group of supporters to work on multiple, concurrent activities within a larger strategic context?

You could still use a blog as a recruiting tool and as a public rallying point for your supporters. For the actual work of the insurgency, you could create a forum with restricted permissions where people could post messages that are organized around topics. The problem with forums is that they are little more than shared email folders, which means that many of the disadvantages of email carry over, and some are even magnified:

There is no easy way to present the "big picture", at least in a living, malleable way. Visual representations are the most effective way of conveying strategy, which is why people tend to cluster around whiteboards during project discussions. You could, of course, create an image file depicting your strategy but there isn't any easy way for the rest of the team to modify and extend this picture.

It is possible to share documents, but not in a flexible way: forums, team sites, etc. invariably impose a check-in/check-out mechanism that makes it difficult for people to easily modify different documents.

Privacy becomes a bigger consideration: if you use a "free" hosted service, your team's content (messages, files) will get scanned by the hosting company in order to deliver targeted advertisements.

Which brings me, in a roundabout way, to Kerika… With Kerika you have the ability to share content in context, and to do so without spending a lot of money or compromising your privacy. If you set up a private server for your team, messages intended for offline team members are stored on your private server, rather than on Kerika's servers. This private server can be any computer that is reliably accessible by the rest of your team, which usually means having a fixed IP address. Now you have a "ring of trust" consisting of your personal laptop, your private server, and the computers of your team members.

Asymmetric Patent Warfare: The Wikipedia Model

2007-05-24T11:48:00.000-07:00

The recent proclamation by Microsoft that open-source software violates 235 of their patents has caused a considerable stir within the Linux community, particularly since Microsoft has declined to reveal just which patents are being violated. (These break down as follows: the Linux kernel violates 42 patents; Linux GUIs violate 65; Open Office violates 45; various open source e-mail applications violate 15; other open-source software programs violate an additional 68.)

Microsoft’s Horacio Gutierrez “refuses to identify specific patents or explain how they're being infringed, lest open-source advocates start filing challenges to them.” He also seems to have no plans to sue Linux vendors directly; instead, it looks like Microsoft’s customers themselves might be the targets since they are much less likely to counter-sue or challenge the validity of Microsoft’s patents.

A Linux vendor, on the other hand, would have no option but to fight to the death if they are sued in a big way by Microsoft, since business death, quite literally, is the alternative for the smaller vendors. The larger vendors (e.g. Sun, IBM), on the other hand, have enough patents of their own that they could mount a serious counter-attack.

Without debating the merits of open-source and software patents, let’s consider this problem from a warfare perspective – as a purely intellectual exercise. In this model, a patent could represent a devastating (nuclear?) weapon, since it could potentially wipe out another company (witness the problems faced by Vonage as a consequence of violating just two of Verizon’s patents). If our comparison is apt, it follows that the greatest utility of a patent likes in its potential to frighten your adversaries, since the actual use of a terrifying weapon invariably has unexpected consequences.

If patents are nuclear weapons, there is clearly more than one superpower since nearly all the large tech companies have amassed literally thousands of patents over the years. None of these superpowers have sued each other for patent infringements except in the most egregious cases, since no superpower really wants to trigger an all-out patent war that could rapidly spin out of control.

Instead, you can have proxy wars, where one side arms and encourages a third-party country to make a limited attack on the adversary, such as Microsoft’s encouragement of SCO to sue IBM for Linux’s alleged violation of SCO’s UNIX patents.

The great thing about proxy wars is that they are (a) deniable, (b) cheaper than the real thing, (c) irritating and distracting, if not altogether enfeebling, for the adversary, and (d) there is only collateral damage, borne by the proxy. Case in point: SCO, which is now a weaker company than it was before it sued IBM.

But in the post-Cold War era, can the so-called “Global War on Terror” (GWOT), where one superpower, backed by an uncertain and dwindling coalition of allies, fights a global insurgency, offer a model for a “Global War on Open Source” (GWOOS)?

The ideal response might be to avoid the war in the first place: either because it is bad karma (Jonathan Schwartz), because it is irrelevant (Mark Shuttleworth), or because it is pointless (Linus Torvalds).

But if Microsoft were to launch a GWOOS, how might the adversary react?

Perhaps with bravado: the folks at Digital Tipping Point have created a “Sue Me First” Wiki page where people can sign up, confess to Linux usage, and dare Microsoft to sue them for their sins. The goal here, obviously, is to flush out Microsoft’s patents so that they can be examined by others, and consequently challenged on the basis of prior art. This is the equivalent of burning an American flag in some town square in a distant land: you get some media coverage, cursory attention from your adversary, and become a temporary local hero.

A more intriguing scenario would be a “global distributed insurgency”, where a large number of individuals and groups, acting with only loose coordination between them, decide to launch a number of simultaneous attacks upon Microsoft’s patent portfolio. Here’s how this could play out:

Open-source advocates could create a simple set of Wiki pages for tracking a large number of Microsoft’s patents: perhaps one page per patent. Any individual could choose to create a page for a patent that he/she finds of interest.

Patent filings are frequently written in impenetrable jargon, so the person who creates a patent page would need to provide a good summary of the filing, highlighting its particular claims to novelty. Within a Wiki model the initial patent summary need only be good enough to attract other people to get involved; subsequent visitors to the page could provide improve the summary if needed.

Once a patent page has been set up, visitors could start adding references to prior art for that particular invention. Just as with the real Wikipedia, some patent pages are going to end up in better shape than others as people gravitate towards topics that are more mainstream.

Eventually, a core set of Wiki pages might be built that provide enough arguments for a lawyer involved with the open source movement to file a challenge against particular patents. The hard work of researching a particular technical subject would have been done by dozens (hundreds? thousands?) of visitors who could collectively prove that “given enough eyeballs, all patents have prior art.”

To take our GWOT analogy further, the particular patents that get targeted need not be directly related to the open-source conflict: the insurgents in a GWOOS could succeed simply if the technological superpower becomes hugely distracted by having to fight on so many fronts at the same time.

In the GWOT, various "interested parties" find it convenient to aid the insurgents in deniable ways, not necessarily because they they want the insurgents to win a particular battle, but simply because they want to hobble a shared adversary. Similarly, in a GWOOS we might find that among the many anonymous (or pseudonymous) contributors to the Wiki pages are agents of other tech companies that are competing with the superpower.

The GWOOS, once started, would be difficult to contain or terminate if enough open-source fans join in the battle. Faced with hundreds or thousands of individual combatants, with whom could the superpower negotiate a comprehensive peace?

If Mark Shuttleworth is correct in arguing that both Microsoft and Linux face a common enemy in “patent trolls”, the smarter strategy for Microsoft might be to avoid launching a GWOOS and instead join forces with the open-source community against a common enemy.

Caveat lector: the above discussion is intended to be an intellectual exercise; I am not taking sides on either the GWOT or the GWOOS. At Kerika we have a neutral attitude towards operating systems: our product runs on Macs, Windows and Linux.

"Cracking" Kerika

2007-05-21T10:05:00.001-07:00

Someone found a reference to an older version of Kerika (0.9.6) on a mysterious Web site that claims to offer "Free Download crack, serial, keygen, patch, nocd patch for Kerika 0.9.6", and wanted to know who these people were, and what it meant to "crack" Kerika.

I won't link to this site because I don't want to encourage such people, but this is basically a scam, although not a particular heinous one. Here's the background: one way for software vendors to distribute their software, particularly if it is free or has a free trial period, is through the use of PAD files.

If you want your software to get distributed by third-parties, the easiest way is to create a PAD file and upload it to the Association of Shareware Professionals (which, despite its name, actually handles more than just shareware). PAD files are a legitimate way to widely distribute software, but they can be abused by unscrupulous people because they are an open standard.

There are a large number of third-party Web sites that distribute Kerika using the PAD files; so many, in fact, that we can't even keep track of all of them. The vast majority are of these sites are legitimate, e.g. Download.com. A small handful, like the ones that claim to offer "free cracks" of Kerika 0.9.6, are obviously unethical.

The "warez" sites seem to attract users who are not just unethical (why were they searching for "free cracks" in the first place?), but also dumb: if something is already being offered free, why would you need to crack it?

Who's that girl?

2007-05-21T09:36:00.000-07:00

Someone emailed me today to ask:

I would like to get to know the people behind the Kerika website. The most puzzling so far: who is this little girl, and what are the objects in front of her? What does "The spirit of Kerika?" mean, that pops up over the picture?

Ahh... the mystery girl! Let's just say that she has provided a kind of cheerful, perpetual optimism that helped the Kerika team push forward during some of our toughest times. The picture was taken casually, when she was fooling around with someone's Mac with a built-in camera, and the light effects that you see are from Mac's Photo Booth software. She is holding are two stuffed animals (toys), but it's hard to make that out.

The picture captures our "spirit" (fun, optimistic, unconventional) better than a traditional mug-shot of the Founder/CEO/Grand Poobah (i.e., me) could ever manage, so that's why it's on our web site...

Apple Staff Pick (Whoo-Hoo!)

2007-05-20T13:26:00.000-07:00

The folks at Apple are listing Kerika 1.1 in their "Productivity & Tools" area, and what's particularly exciting is that we have made it as a "Staff Pick"!

Kerika on Linux!

2007-05-16T08:08:00.000-07:00

Finally! We are offering a Kerika packaging for Linux users. After wrestling with InstallJammer for many hours yesterday, I finally gave up and went with InstallBuilder. Try as I might, I just couldn't get InstallJammer to display our license agreement properly, and finally gave up late last night.

I tested it (briefly) on two machines:

An ancient Hewlett-Packard desktop that is dual-partitioned to run Windows XP and CentOS-4.
A Mac Book Pro running Ubuntu as a virtual operating system (using Parallels).

The Ubuntu testing went a lot easier: for some reason Kerika had trouble recognizing the double-clicks on CentOS. I played around with the mouse settings but I never got it working quite right. In general, Ubuntu was a friendlier Linux experience.

One other deficiency we found: for some reason dragging and dropping documents from the desktop (or other file folder) onto Idea Pages doesn't seem to work on Linux, so you need to use the Project Tools or the File menu to add documents. (But dragging and dropping Web Links (URLs) does work.)

In general we have a very limited ability to support the Linux version, which comes with a big "caveat emptor"...

Live from the battle zone

2007-05-14T13:47:00.000-07:00

While waiting in line at the local vehicle licensing office I was flipping through The Valley View, a local newspaper, when I came across its "crime beat" section. Here are some of the horrors of life in the Duvall-Carnation area, as reported by Riley Mizell:

April 27, Duvall: Neighbor’s hot tub noise causing lack of sleep – again.

April 27, Duvall: So this suspicious person was reported as standing on the street for a long time. About the time officers arrived, the guy was finished smoking his cigarette and was headed back inside.

April 28, Duvall: What went wrong with this relationship between Mother and son, that son would poke Mom in the mouth during an argument? Hopefully the officers were able to help the situation.

April 28, Carnation: Stolen dirt bike? Nope, husband sold it without wife knowing.

April 29, Duvall: The new Skate Park in Duvall was the place of choice for these three folks for using their drug of choice. Officers recovered the stuff and arrested the guys.

April 30, Duvall: Children weren’t home where they were supposed to be. Officers were called. Fortunately, about that time, the children were all done playing at a nearby park, and were back home. Perhaps they got a good family discussion about making sure parents knew where they were.

April 30, Duvall: This guy causing a disturbance was at least considerate enough that he was smashing his own car windshield, instead of his neighbors. Could be the intoxicated state had something to do with actions?

April 30, Duvall: Speeding semi-trucks were reported. Different location than the speeding dump trucks earlier in the week. Officers responded, but word must have gotten out, because everyone was on their best behavior.

Oh, the humanity!