« December 2005 | Main | February 2006 »

January 24, 2006

Why the Web is great for a Web software company...and its customers

We all know that the web is fantastic: Think of life before google, yahoo,
mapquest, vacationstogo or expedia, cnn.com --- versus now. The differences
are so obvious that no case needs to be made for the web being great. But I
was thinking about how the web has made life great for someone in my
position helping to manage a company with a web-based software product.
The web -- and web-based software -- offers many benefits.

Let me explain:

--- The most obvious is that a 100% web-based software product can be
deployed at a customer site by installing it on one central organizational
server. No client software is needed as all functions are accessible via
the user's standard browser. Why is this great for a web software company?
It makes the job of deploying the product to a local company or a global
company the same:

Just put the web-based software on a webserver, and anyone with the
appropriate privileges, anywhere on the web, can access it. No client
software is needed.

This is a big deal for my product's users -- which makes it a big
deal for me.

--- The software can be demo'd to many people at once. This is what got me
thinking about this topic: We did a 'webinar' a few days ago to 250 people
interested in helpdesk automation. Webinars are displacing its predecessor,
the seminar. Years ago, you needed to rent a big room, send out invites,
serve lunch or coffee and donuts - and you might sometimes get a
reasonable audience. Managing an event like this was difficult and very
expensive, but it was always possible that no one would come (:. Webinars
have changed this. Nowadays, prospects can come to this week's webinar, or to
next week's webinar instead if something important comes up.

And what if a good thing happened -- too many people came: In the old days,
there would chaos and standing room only. Webinars allow you to scale, all
while reaching people in the comfort of their most convenient (and comfortable)
office environment.

--- Web software can be easily demo'd *custom* to anyone, anywhere. Last
year I gave a demo to a group of people from one company -- some of them
high-level executives -- at a company in North America, Asia, and Europe --
simultaneously. They logged in to a Live Meeting session from their
desktops, we got on a shared phone line, and I showed them a customized
demo on how to use the product for their needs. This was set up in minutes.

Again compare this to the old days:

We would have flown out to some central location, had to have been there
when they were all in town, and given the demo in person. Coordination,
cost, and time lost were all way larger.

A corollary to this is that the need for traveling salesmen and demo-givers
is greatly reduced. This means that the cost structure of the software
manufacturer is less than it used to be, which in turn means that the prices
charged for software can be less than in the pre-web days. So the customers
can pay less, which also allows companies who could not afford the product
in the bad-old days to buy it. Volume goes up for the software manufacturer;
Everyone wins!

--- The software can be run at the customer site or hosted anywhere. In the
pre-web days, the software had to be installed on each and every machine at
the customer premises in order to provide users with access to the
application. There was no other way to do it. Now, customers who are not
part of the IT Department, and who need the software as a service, can have
it hosted anywhere. This allows software developers like me to host their
web-based applications, eliminating the hard costs of purchasing the related
IT infrastructure as well as respective expense to install, set-up and
maintain them. This is a tremendous benefit.

--- Checking stuff out can be really easy from anywhere. I went on a
wonderful cruise during the first week of January. From the ship, which had
Internet service, I could read my email from the web, read support issues --
looking for anything which needed my personal attention - read development
issues too, commenting as needed, all via the web interface. In just a few
hours during the week, I could see what was going on, and in a few cases I
could even help - all while being in the middle of the ocean and far away
from the office. Again, if I contrast that to years ago, the web has made
life way easier, and we are more efficient, all of us.

In every case, our costs have gone down, we are more efficient, and we and
our customers reap the benefit. The Web is great.

Mark

P.S. If you have comments on this or any other blog entries, please email me at msk@unipress.com

January 17, 2006

Thoughts on FootPrints Version 1

People sometimes ask me, "How did you get started with FootPrints back
in the late 90's?"

I had a chance to think about this last week while I was away on
vacation for a few days in a nice warm climate.

The story goes back to the early 1990's, when I was approached by a 'friend
of a friend' who had written a Source Code Manager for Sun Unix called
'SCM.' For those of you who use Unix or Linux, SCM was like SCCS or RCS,
but with many more features to manage multiple people working on source
code. We looked at SCM, liked it, and decided to work with the author
to package it for multiple Unix machines (in addition to Sun), and to make a
professional package out of it. The author had originally written SCM for
one of his own clients. After a while they asked him to provide a
Modification Request (MR) system, to track changes - outside the source
code - in a separate database. This MR system had commands like mrRegister,
mrList, mrDetails, mrChange, etc. Sound familiar? If you've looked in the
binary (bin) directories of FootPrints, you will still see commands with
names like this, even today, although over the years we have almost
completely changed them.

Both the SCM and MR systems were very useful, but sales were not great.
There were a lot of reasons: They were primarily commandline tools, with a
very minimal X-Windows frontend, and no Windows support. The Source Code
tools available from other software companies of that time for Unix and
Windows had gotten very sophisticated. It was a crowded market. And Unix
was also starting to lose significant developer marketshare to Windows
(and later Linux). And while UniPress was doing well selling our other
tools and products, we were disappointed that these excellent tools were
not taking off.

Skip forward to the mid 1990's. The Internet was starting to emerge.
We wanted UniPress to become seriously involved in what we knew would
become a world-changing trend -- the web. The big question, and it was a
VERY BIG question, was what web-based application should we create?

After a short period of reflection, we decided to make a web-based
helpdesk / issue-tracking system. A web-based helpdesk would be an ideal
way to utilize the benefits of the Internet in conjunction with a
critical organizational application: The system would offer
instantaneous, worldwide comunication AT NO COST TO THE USERS, could
permit collaboration, and be designed for extreme ease-of-use. It could
even have an 'end-user/customer portal' for self-service.

We could use the MR programs we already had to do the database backend,
and would create the necessary screen-oriented programs to handle the user
interface.

We chose Perl as the language to develop the Web frontend, and to handle
everything but the database backend. If we used Microsoft tools we wouldn't
be able to sell to the Unix Webserver market (which was very important
at that time), and if we used java from Sun we wouldn't be able to sell
to the Windows Server market. We wanted our application to run on the
widest possible array of platforms. A Perl compiler was available on all
platforms, and our Perl code would need only modest changes for different
platforms.

We started work in early 1995, and Version 1 of Footprints was completed in
late 1996. While very basic compared to Version 7, it was very useful, it
was 100% web based, and it was a great base for future development. Many
early customers used it for general issue tracking of all sorts, but it
became clear early on that most people who tried it were looking for a
Helpdesk. So much of our development was put into features for that
direction, even in Versions 2 and 3.

Most important, we made a few basic decisions in that first release
which have turned out to be excellent in retrospect: Administration
is done via web screens, not through programming. Multiple projects,
allowing people to create different applications in FootPrints, are
builtin to the base product. And one code base in Perl for Windows,
Unix and Linux versions gave us cross-platform capability for all
types of Servers.

Would we have done some things differently if I could roll the clock back?
Certainly. But the strategic and architectural decisions made in the early
days in have held up well.