* This article was published by the IEEE Computer, December 2001 issue (PDF proof here). © Copyright 2001 IEEE - All rights reserved.

The story of how open source software helped launch a for-profit business.

by

David A. E. Wall, Yozons Inc.

Like so many tech startups, Yozons was founded when my partners and I came up with an idea that we believed would be a huge success. Our unique process for incorporating public key cryptography in a way that could easily be used by any businessperson was sure to revolutionize the document-driven economy, a "killer app" for electronic signatures and the last mile for the paperless office.

The only trouble is we didn't have sufficient capital to build the business.

If you've lived through the founding of a company before, you know that was a serious problem. Money talks – you know what walks.

Undeterred, we immediately documented our special process and filed a provisional patent, giving us a critical year to raise money, develop the technology, raise more money, and then get the final patent application submitted. A year may seem like a long time, but time flies when you're busy designing, developing, fundraising, marketing, hiring, dealing with legal issues, configuring networks and forging strategic partnerships.

After the dreamy eyes of billions in revenues and a monster market cap in five years gave way to the reality that the stock market bubble burst was going to make raising capital brutal, that businesses need capital to grow, we decided that we'd have to figure out how to bootstrap the company. Our calculations showed that we needed at least $200 grand to build the software on a shoestring budget. This meant using open source software to avoid the license fees, keeping our source completely separate from the open source code, and using highly portable coding techniques so we could deploy on "real" gear later.

How do you find money when most investors were losing all of their tech bets? Family, friends and a prayer, of course.

All three answered. First a friend came through, then came family and a few angel investors who chipped in until we exceeded our goal, letting us get started six months after the idea was hatched.

In order to build a viable web services business, we needed to use tools that would let us scale from a single server on up to potentially thousands of servers to handle the projected loads. But if you've recently priced Solaris or NT, an Oracle database, BEA Weblogic, iPlanet or RSA Security's crypto toolkits, you know that deep pockets are a must. And if the base software is so expensive, it will negatively impact our ability to sell a reasonably priced web service as well as dramatically increase the licensing costs for our customers. After all, it's a lot harder to make money on technology when the stack it rides on costs $200,000 for a moderately sized system. Today, ROI calculations are all important, and open source is the savior for enabling sophisticated applications to be built at a price point that allows a reasonable return on investment.

I've dabbled in open source projects with Linux, GNU and Apache since about 1995. But everything beyond that was research, download, build, test and compare. Maybe some of my findings will help others, though from what I gather from the many developer lists I subscribe to, the debate continues over which of the many projects are "the best." Of course, we all know that there's really no such thing as "best," and in the end, "good enough" is the real requirement and goal to achieve.

Because of my significant experience with Java technologies, I decided to build this system using Java. It is highly portable and new systems can be built rapidly.

Fortunately, Java is a free download for Windows, Linux and Solaris. I decided on using Sun's JDK 1.3 and VA Linux's Intel-based servers running their version of RedHat Linux. The last one ended with a mixed result: I'm stuck with hardware that works fine but is unsupported since VA Linux recently announced they've abandoned their roots to become a software-only company.

The web server seemed pretty obvious. I picked Apache because it is stable, robust, secure and well known. What's nice is that our service requires high levels of security, with SSL a must, and the folks at OpenSSL have a fine implementation that plugs into Apache using ModSSL. The build was straightforward, and there was no cost other than the hardware and Thawte digital certificates for the production servers.

But web services require dynamic web pages, so the next choice was for an application server. Fortunately, the Apache project came to the rescue on several Java fronts. First, they offer the Jakarta project, which includes Tomcat for our Java ServerPages and servlet environment. Next, they offer an XML parser and a SOAP implementation that we needed for our remote APIs. With these in place, we could serve up secure, dynamic web pages.

The next focus was on the database. I'd read much about MySQL, and it did seem to be a super fast database. They'd just added transaction support, but it was a new combination that I fretted might not yet be ready for prime time.

Fortunately, PostgreSQL came to the rescue. It's a seriously good database with a workable, though not entirely compliant, JDBC interface. Their support for transactions, even performance across queries and updates, good locking rules, online backups, and support for large binary objects was critical. The latest version removed a row limitation that I can't believe wasn't an impossible barrier for earlier production systems.

We did have a couple of minor snafus with PostgreSQL. First, binary objects are not well supported via JDBC, and it's important to run a "contributed" utility to cleanup orphaned objects. Second, having to run "vacuum" periodically is a pain, though I understand it's being addressed soon. Third, the JDBC library doesn't support small binary objects, but we got around that by base-64 encoding them and storing in a text field. We have a lot of small objects in our application for encryption keys, secure hash results for things like passwords and encrypted credit card numbers. Finally, timestamps in many programming environments have a resolution of milliseconds, but we couldn't get JDBC to accurately store anything higher than centiseconds. Normally, that's unlikely to be a problem, but if you use timestamps as part of a digital signature or secure hash, missing bits are a real problem.

At this point, we had a free set of software that worked extremely well and allowed us to build a sophisticated web application. Unfortunately, we needed more to support Yozons' highly distributed architecture.

In order for our application to be able to run on multiple, distributed servers, we needed a way to reliably transfer messages among them all. For that, we needed a transactional messaging platform with guaranteed delivery, preferably one that implemented the Java Messaging Service APIs. What I found was not open source, but at least it was free (as a startup, "free beer" may be more important than "free speech").

We found SwiftMQ's federated router architecture provided a highly scalable message routing platform that has proven to be fast and reliable. With the ability to connect remote routers over SSL, secure messaging is possible even over the Internet. While not open source, they have a community of users who can help with configuration issues, and bug fixes and new features have been coming out periodically.

At this point, we had everything for a scalable, distributed web services platform – at no cost to the startup, and with no added licensing costs for our customers.

In order to offer e-signatures and guarantee the privacy of the business documents being routed through the Yozons network, we needed superior encryption. We found a wonderful Java Cryptography Extension (JCE) implementation from Bouncy Castle. The name is odd, but they not only offer a wide set of standard cryptography, including Blowfish, Rijndael and TripleDES, they also provide public key cryptography through their RSA asymmetric ciphers and digital signature capabilities. They are the only open source JCE implementation we found that had support for X.509 digital certificates.

The Sun JCE provider provides RSA for digital signing, but it doesn't allow you to encrypt, and that was a requirement for Yozons because our distributed processes needed to be able to securely communicate with each other to ensure that no rogue process attempts to join the network.

Finally, we had everything needed to build a secure messaging service with e-signatures on a distributed architecture. But how were we going to have multiple developers at multiple locations write code without causing lots of pain and lost updates?

Fortunately, the open source community had an easy answer since distributed development is a cornerstone of its success. We chose CVS, WinCVS and OpenSSH. CVS provides a reliable, distributed file repository for source code and binaries. WinCVS provided an easy-to-use interface for Windows developers. And OpenSSH provides secure terminal and file transfer access for both interactive work as well as for securing communications to the CVS repository.

Of course, there's a bunch of software that's needed to complete a working web service, but is not tied to software development. Again, the open source community came to the play a significant role in helping us out.

Yozons is a heavy user of email, providing alerts and sending return receipts when documents are read or signed. JavaMail provided the programmatic interface, but Sendmail provided the SMTP server that did the work of delivering the email. For our domain name server, we stuck with the venerable Bind. Both have worked without any problems. Sendmail and Bind have a history of security issues, so we decided to run them on their own server to help ensure our application did not fall victim to an attack on them. The recent outbreak of the Code Red worm hurt a lot of sites running Microsoft software, but we were not affected at all, showing once again that open source software saves time and money over competitors in the commercial world.

Providing accurate timestamps on messages, documents and e-signatures is a critical feature of Yozons. The network time protocol fit the bill, and timeSync offered an easily configured, automated NTP solution that ensures our clocks remain highly accurate and synchronized.

When it came time to secure the web servers from intrusion, we looked over a few firewall appliances, but the costs were prohibitive. Fortunately, Linux's ipchains offers a firewall for inbound as well as outbound traffic, and even provides for network address translation to allow us to run our application separated from the Internet on a private network behind yet another firewall. Coupled with Tripwire and Snort, which detect unexpected modifications to files and analyze logs for intrusions, turning off all Internet services that are not needed, removing all unneeded user accounts, and ensuring high quality passwords for the accounts that remain, Linux has shown to be very secure and robust.

In the end, the open source community of developers has been wonderful for our startup. The savings in up-front costs, the highly reliable and feature rich software, and the excellent support networks allow us to be successful in providing a reasonably priced secure document delivery and e-signature solution to our business clients.

While we are happy that we can easily run our software on Solaris, iPlanet, Oracle and BEA for those clients that demand it, we're more than happy with the results we've gotten from the hard work and dedication of many untold open source contributors.

+++

David A. E. Wall is a founder and chief software architect for Yozons Inc., a Seattle-based startup focused on providing e-signature and secure document delivery web services. Mr. Wall has been a professional software developer since 1984, starting with punch cards and Cobol-68 on a mainframe and continuing through to web services in Java and XML on distributed Linux, Windows and Solaris servers.

Some startup lessons we learned

Despite the fear, uncertainty and doubt cast by Microsoft, open source licenses are not inherently evil. But if your software is proprietary, then it's important that you understand the open source licenses being used. If not, follow "safe open source" practices: 1) don't incorporate any open source code directly into your code; 2) don't modify the source code to fit your proprietary needs; and 3) if at all possible, don't even download and compile the source code so you're not tempted to do either of the previous two. Many open source projects provide binaries, and many follow a lenient BSD license, but many more use the stricter GPL, so it's important to ensure that your proprietary code is always separate and distinct from the open source code. Of course, depending on your revenue model, releasing your code as open source may work fine for you.

Prototype development is a must, but don't try to build the real thing until you've got the money to get it built, deployed and then marketed.

Techies often don't understand marketing and sales, but they are incredibly hard to get right, are generally 180 degrees different from engineering activities, and are easily more important to a business's success than the development effort itself. Sounds like heresy to a developer's ear, but the reality is that customers won't come just because you build it.

But it's also true that the product is key. I saw a well-funded startup fail despite a fantastic marketing and sales staff – they were the reason they could sell so many investors on the idea – but their technologists were weak. Focused more on the tools they'd like to use than on building what the founder's vision was, the technology was never built, so those great sales folks never got to show anything more than slideware.

All open source projects are not the same. Some are too small, some have died from lack of continued support, and some suffer from quality problems. There's nothing new here, though, since the same can be said for commercial vendors. The key is to pick the ones that match your needs and have an active user community. But at least you can rest assured that if the open source project does die, you have the source code. And if you stick with standards APIs, switching to another project or even a commercial vendor will be much less painful.

Lastly, if you expect to license your software to large corporations, you must allow it to run on their hardware and software stacks, even if the price is prohibitive to your own organization. Despite the fact that the open source solutions may be more than adequate and often run better than their commercial counterparts, expect that they are much less likely to risk their positions by bucking the status quo.