Q&A with some of our users

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

1. 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.
   
   
2. 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.


3. 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.


4. 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.


5. 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

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:

1. 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!
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.)
3. 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

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

The alligators at McKinsey

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

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:

1. 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.


2. 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.


3. 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

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:

1. 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!


2. 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:

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


2. 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

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

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

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.