Bug bounty

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

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

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

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

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?

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!)

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!

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

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!

Page Trash (or Recycle Bin, in Windows-lingo)

Continuing with our recap of the improvements and innovations in version 1.1...

We have introduced a "page trash/recycle bin" which lets people on a project team use Kerika as a kind of "graphical wiki" (a term that I first heard from an early user and contributer, Daniel Brookshier).

Now, anyone can delete any item on an shared Idea Page, and that item will disappear from view for everyone else on the project team. And if anyone else on the team feels like the item really does belong on the page after all, they can restore it from the page trash. Hence, the term "graphical wiki".

This new feature is part of the overall move towards making sure everyone is on the same page all the time, which is a big change from older versions of Kerika that left it to each person on the team to decide how their copy of a shared page was arranged.

Easier zooming

Older versions of Kerika had a feature called the "Navigator" that showed up in the Tools menu. This let you zoom in and out of large pages, as well as pan across pages.

The Navigator is gone with version 1.1; instead we have added some tiny buttons to the lower-left corner of the Workspace to make it easier to zoom in and out. More importantly, we have added a "Scale to Fit" button which automatically resizes a large Idea Page so that all of its contents can be shown within the Kerika window.

These new features make it a lot easier to deal with large Idea Pages, which can be handy when you are switching back and forth between a large monitor and a smaller laptop or notebook screen.

Is everyone on the same page now?

One of the many changes that went into version 1.1: if you move an item around on an Idea Page (project) that you are sharing with other people, this change is reflected in the view that everyone on the team has when they look at that page.

In the previous version, if you rearranged items on a page to better suit your convenience, we didn't change the views that your team mates had of that same page. This was one of those bright ideas that worked a lot better in theory than in practice. The original concept was that we would provide maximum flexibility to every person on the project team: each person could re-arrange a shared page to reflect their personal tastes, without disrupting the views of other people on the team.

In practice, however, this just lead to confusion. We found that it was in fact far more convenient if everyone on the team had the exact same view of the same shared page. This is particularly true if you are using Kerika for Scrum-style projects, where you might have created a project page full of sticky notes to keep track of a product backlog.

Anyway... with version 1.1, everyone gets to see the same view of the same page at all times! And thanks to this improvement, we could eliminate the old "Remote View" tool which doesn't serve any purpose any more.

Kerika on Linux: a step closer...

I was finally able to get Kerika running on Linux, albeit in an unusual way! First, I installed Parallels on my Mac. The new version of Parallels is excellent: I had tried an earlier version back in December and found it hard going, but the new build (3188) is very easy to use. Next, I installed Ubuntu's Feisty Fawn release of Linux. My first attempt ran into some problems, so I went online and found a very helpful article that walked me through every single step in a fairly idiot-proof way.

With Ubuntu Linux running as a virtual machine on my Mac, I was able to get Kerika up and running, as you can see:


I still don't have a good installation package sorted out; for this test I copied the jars over into a folder and started Kerika using a terminal window. Nonetheless, I am very pleased with the results: I know that Kerika basically works on Linux, so that gives me an incentive to push ahead with selecting an installation package. I didn't do a lot of testing, but I did notice that drag-and-drop didn't seem to work with documents: I had to use the Project Tools toolbar to add files to an Idea Page. (And I haven't tested yet whether drag-and-drop of Web links works or not.)

How cool is this?

Check this out: the Windows XP version of Kerika running on a Mac, thanks to Parallels!

The installation went pretty smoothly: the only glitch was Kerika complained about not finding a DLL called "msvcr71.dll", which I think had to do with an earlier mistake I made in installing Parallels. This was easy to fix however, by downloading the missing DLL from DLL-files.com.

Free-standing lines and arrows

Another new feature with version 1.1: you can draw lines and arrows freely on an Idea Page; they are no longer limited to connecting shapes as with previous versions of the software.

This new feature will make it easier to draw tables on Idea Pages, e.g. for laying out Scrum-style projects where you want to keep track of a tasks grouped as product backlogs, work backlogs, Sprint backlogs, etc.

Get the picture?

Another improvement with version 1.1: now, when you drag and drop a picture onto a page, the picture shows up as an image rather than as an icon. This isn't a completely new feature: it was there in previous versions but the default setting was to show pictures as icons rather than as images. Now, by default pictures show up as images, and it is easier to change your preferences to show either images or icons.

(Another bad decision successfully reversed!)

Simpler Notifications, but far from bug-free

The Notifications system is simpler, but far from bug-free. Earlier versions of Kerika tried to sort out notifications by category: all the project changes went into one category, all the document changes in another, and so on.

This was a good idea, as ideas go, but we didn't do a very good job of implementing it. There were two big problems that made the whole process kind of ugly:

• The process of sorting out the notifications didn't work very well, and when it did work, it didn't necessarily match the user's perceptions or expectations. For example, if a document gets added to an Idea Page, should it show up in the projects category, the documents category, or both?
• The UI didn't work very well: after a while the list of notifications got to be so long that the pop-up display was hard to use.

The new Notifications system is a step in the right direction, even if it isn't quite perfect. We have consolidated all the notifications into a single icon, which effectively side-steps the problem of categorizing them into project changes, document changes, etc. One big advantage of this is a cleaner appearance: fewer buttons and indicators on the screen to distract you from your work.

Unfortunately, we still have some work to do in terms of filtering out the excessive number of notifications that get sent. This isn't as easy as it might sound; as I explained in my last blog post, under the covers the Kerika software still manages permissions at the level of individual objects. When you add someone to a project team, you are actually adding that person to the permissions lists of each item on that page. Each of these events triggers its own notification, which leads to a lot of noise. And some unfinished business on our part...

A new concept: Collections of Projects

One consequence of allowing users to share entire projects, rather than just individual items on pages, was that we needed a good way to present these shared projects to the rest of the team. The concept we came up with is that of "Collections", which are basically like super-folders of projects.

Kerika comes 3 built-in (Work, School and Play), and you can of course create your own. When someone shares a project with you, Kerika creates a Collection on your computer that matches the sender's Collection. The next time that person shares another project with you, using the same Collection, this new project automatically gets filed for you within your "remote copy" of the sender's Collection. This makes it easy for you to stay in synch with other people who are adding you to their projects.

(A little trivia: when we were implementing this new concept, we originally referred to each Collection as a Home, but no matter how hard I tried I couldn't get used to referring to "mulitple Homes" which just seemed like an oxymoron to me. So we switched to the term Collections but kept the old icon of a little house/home.)

A new model for sharing projects

We made a large strategic error with our first version of Kerika: we decided to allow users to share individual items on a page rather than the entire page. This was one of those ideas that sounded really great in theory but bombed in practice: everyone that we talked to during the prototyping and market research stages of Kerika liked the theoretical advantages of the original model, which allowed for very precise control over what you shared, and with whom.

As a result, our original model (which is still buried deep in the Kerika code), managed access permissions at the individual object-level, which was very fine-grained indeed. So much so that after attaching a note to a document you could share the note differently than the way you shared the document itself!

This was an expensive error on our part, because the original coding was very difficult, time-consuming and error-prone. Soon after we got our original beta versions in the hands of some early users (starting around Dec 2005), we realized quickly most people simply couldn't handle this level of low-level setting of permissions. In reality, most people simply wanted to share an entire project, with all of its constituent pages, documents, shapes, notes, etc., with their team mates.

Reversing this decision took a huge amount of effort on our part, which is why version 1.1 took so long to get done, because we had to create another layer of permissions control that allowed users to manipulate projects rather than individual objects. The original low-level controls are still there; it's just that you don't see them any more because the Share Project button does a lot of processing in the background to take care of all the permissions on individual items.

So here we are... with version 1.1 you can share an entire project with one action, rather than sharing individual items one-by-one. One consequence of this new model is that whenever you add a new item to a shared project, e.g. you add a new document to an Idea Page that you are sharing, this new item will automatically get shared with the rest of the team. (In the old model you had to take two actions: first add the document, and then share the document.)

What do you think? Is the new model better than the old? Does anyone really miss the old capability of sharing items one-by-one?

Where's the Linux version of Kerika

We haven't released a Linux version yet of Kerika, but it's not for lack of trying...

I have been playing with a bunch of different installation programs, and haven't finished deciding which is the best one yet. (And I would love to get suggestions!).

Also, I am having some trouble testing Kerika on my Centos Linux installation at home. The double-click operation, which is essential for Kerika, doesn't seem to work quite right: about 90% of the time the double-click doesn't get recognized properly by the application. I can't figure out why: whether my mouse settings are bad, whether my hardware is crappy (I am running Centos on a dual-partitioned HP desktop that is really, really low-end), or whether there is a Kerika bug.

When I get some spare time next week I am going to try running Ubuntu as a virtual OS on my Mac, using Parallels, and see if I get better hardware performance which should help eliminate hardware as a potential source of trouble. Also, it might help eliminate Centos as a potential source of problems. All of this assumes, of course, that running Ubuntu on a Mac using Parallels doesn't introduce its own set of hassles...

The new sign-up process

We have made some important changes in the sign-up process, some of which was, frankly, long overdue.

Previous versions of Kerika let you provide any email address which you could use to create your new user profile, and a small percentage of our users provided what were clearly fake email addresses. Since the process of creating a new user profile took place at the local computer, not our central server, we didn't have any easy way of checking whether someone had provided a legitimate email address or not.

This was something we have been wanting to fix for a long time, but it took us a while to get around to it because we had to first build a user database that we could manage centrally, and also build a subscription system. Meanwhile, there were a number of changes to the Kerika user interface that we wanted to implement because of feedback we got last year from our initial set of users.

The net result: everything took longer than expected!

So, here's how the new sign-up process works:

1. You need to sign up at our Web site, which takes about 10 seconds since all we ask for is your name and email address.
2. We send a confirmation email to the address you provided. This is a lot like signing up for other Web sites and services: the confirmation email contains a special Web link that you need to click on in order to complete the sign-up process. This helps ensure that people provided their own, real email addresses when they signed up.
3. Once you click on the Web link contained in your confirmation email, you get taken to your personal account page. This page contains your personal License Key, which is a long, random string of numbers and letters. (Techies will recognize this as a GUID.)
   

You can download the software at any time, but you need the License Key in order to set up your new user profile. When you start up Kerika, you will be asked to enter the License Key, which you can enter (with or without the dashes, and in upper- or lower-case). Note: the license key doesn't use the letter "O", so if you see something that looks like the letter "O", that's actually the number zero.

Once you enter the License Key, Kerika finishes setting up your user profile, and you can start using the software. You get a 30-day free trial, after which you need to buy a monthly subscription.

One very important point to remember: don't pass on your License Key to anyone else; otherwise they will be able to impersonate you online and possibly steal your project data!

Finally... Version 1.1 is here!

At long last, and after much effort, Version 1.1 is finally available!

This new version has a number of improvements over the last version, which is now a year old. I will talk about each enhancement one-by-one in successive blog posts; here is a quick summary:

• The sign-up process is different: we have introduced a couple of long-overdue steps, such as sending confirmation emails and introducing the concept of a License Key.
• The never-ending-free-beta is over: now you can get a 30-day free trial, after which you need to sign up as a subscriber.
• Sharing projects is a whole lot easier: sharing is now done at the project level, rather than at the level of individual items on a page (which most people found too difficult).
• There is a very cool new feature: if you want to share a project with people who don't use Kerika, they can get their project updates by email.
• Adding pictures to pages is improved.
• You can now set up private networks, if you don't want to use Kerika's storage servers.
• Each page now has its own trash, so if someone on the team deletes an item, anyone else can restore it (just like with Wikis).

We got the new version up about a week ago, and didn't really publicize it because we wanted to spend some more time shaking out the bugs – and getting the web site in better shape – but we have already gotten some early feedback from the folks over at Vimukti who have been trying out the product.