Infovark

It was just more than a year ago that Gordon and I started Infovark. It’s hard to believe it’s been that long since we left world of enterprise systems consulting to build our own product. We’ve learned a lot about writing code, marketing products, and running a software startup. It’s experience we couldn’t have gotten working anywhere else, for anyone else. It’s been hard, hard work. It’s also been a lot of fun.

You might have noticed that the rate at which we post to this blog has slowed lately. That’s because, in anticipation of our one year anniversary, we’ve been planning for the next year, which will bring lots of changes. We’ll conduct a public beta and launch our first product. We’ll set up a satellite office in Australia for Gordon. We’ll establish our revenue model and pricing. And we’ll do all of these things while remaining engaged in the Enterprise 2.0 community.

We started Infovark because we had a particular itch to scratch. We felt that many of the solutions being sold to business professionals failed to deliver on improved productivity or collaboration grounds. We felt like there were tools and technologies that could help, if you could put them together in the right way. We felt that doing so might require totally new approaches, ones that broke with old habits and legacy thinking. And we knew that was going to be a hard sell.

So we’ve been reaching out to a few folks. Some will help us with interface design, some with business development, some with performance and testing. Gordon will catch up with some of his mates in Australia that might want to pitch in. I’ll be looking for talent here in the U.S. But good people and good ideas come from everywhere. We aim to be the smallest, most innovative global company you’ve ever seen. We want to change the world of work for the better.

So here’s to the coming year!

Enterprise 2.0 case studies are hard to find, so I pay attention whenever someone posts interesting findings on the Internet. Jack Vinson published his notes on social bookmarking in the enterprise talk given by Laurie Damianos of MITRE at the Boston KM conference. It’s worth a read. From the study:

“Many of the terms used by users are not in the official taxonomy, and work is underway to expand the formal taxonomy to represent things according to how people expect to find them.”

A corporate taxonomy based on what actually happens, instead of what is supposed to happen? 

That could be useful…

While browsing the feed from Content Management Connection, I noticed that Oscar Berg re-blogged David Wineberger’s notes on the nature of openness taken at a seminar given by James Boyle.

The gist of the talk (and the notes) is that people routinely overestimate the risks of transparency and undervalue the benefits of openness. It’s a hard habit to break. We assume that increased control will lead to increased security. But there are situations where the reverse is true.

Which is more secure from a group of second-graders: A cookie in plain view on the breakfast table or one in a ceramic jar on the kitchen counter?

Psychologists have done this experiment. The cookie lying out in the open is the most secure. Everyone can see if it’s missing or if someone took a bite out of it. If one of the kids takes it all the others will know — and at least one will probably tattle. Only if all the children work together can they get the cookie and get away with it. That requires the children to work together closely and divide the spoils fairly.

The cookie in the jar is actually less secure because any one of the children might be able to sneak it without the others knowing. (And now you know why most jars of candy are clear glass or plastic!)

Information is Brain Candy

The same logic that drives the cookie experiment is the logic that makes sunshine laws, open source software, and Wikipedia work.

Security is often the first concern raised by organizations implementing collaboration tools. But openness can actually lead to better security.

Paul Graham posted a Fundraising Survival Guide for start ups to his website. It’s a subject that’s been on my mind a lot lately.

When we started Infovark, we had roughly enough money to get through the first year. We did a fairly good job of budgeting, all things considered. We’ll be able to stretch our initial round further than planned, basically because we hired a few specialists under contract rather than another full time employee. We were also pleasantly surprised at the number of high quality software development tools you can get for free or at reasonable cost. (Microsoft’s Empower for ISVs was a particular boost.)

But when you’re a startup, the clock is always ticking. I can hear it now: “Time is money is time is money….” This is the mantra of the founder. It’s what gives us sleepless nights. It leads to fear and indecision. The search for additional funding can obscure the real goal of starting the company: building something useful — and having fun while doing it.

Infovark has by far been the best work experience of my life. Not merely because the Burrow is conveniently located in my basement — though it’s nice not to fight traffic — but because I’ve finally gotten a chance to create a product from scratch. I’ve never had the chance to do that before, and I’ve been learning a lot in the process. (That’s entrepreneur shorthand for making more mistakes faster than ever before.)

I’m really excited about this stage of the project. We’ve gotten an initial round of feedback from our alpha testers, and we’re mapping out the plan to get us to beta. But I can also hear the clock ticking…

That means at some stage — probably sooner than we’d like — we’ll have to leave the Burrow in search of funding. It’s a scary prospect for introverted software engineers. We’ll have to explain what we’re building, why we’re building it, and why you ought to invest in it. That means we’ll have to define why people will want to buy it and how much it will cost for them to get a copy. These are yet more things to add to our long, growing list of things that aren’t writing code. Except that getting funding is far from trivial, as Paul Graham points out. It’s a matter of survival.