When I explain that my expertise is in IT, people nod and think I am a technology guy. Then I go on to say I do software, networking, green/clean technologies, energy efficiency, cloud computing, embedded software, and the application of ICT to other areas, like smart grid. People get confused, and their attention goes out the window. When I feel like it, I even include network security, open source, and Japanese market entry strategies. This looks like the resume of a third-rate guy who is having a hard time getting employed. By this time, people look at me as if I were either a liar or a poor soul who does not know what focus means. But over many years, I actually got involved in all those areas. Despite the apparent lack of focus, one big benefit of such wide coverage is that when a new area emerges or an old one re-emerges, I can handle it without much difficulty. All I have to do is to combine some of my expertise in different fields to figure it out.

At the recent RSA conference, as I was rushing to the next appointment for a video interview with Akamai on the show floor, someone called my name. The crew I was with were walking ahead of me and the voice came from nearby. It was Larry Stefonic. Larry was senior VP sales for MySQL and, later, president of MySQL Japan, a vastly successful open source SQL database company. As you know, it was acquired by Sun, and Sun was acquired by Oracle. Therefore, MySQL is now part of Oracle. Larry hired me as a market scout for Japan. I tapped into the Japanese market, including promotion, business development, and sales lead generation for him.

While doing that, I learned a lot about open source and its merits. I also did similar work for JBoss at about the same time. Then, both MySQL and JBoss got sold and Larry disappeared. With that, I lost interest in open source for the moment and moved on. After I reconnected with Larry via LinkedIn, I realized he was in Montana and had started a new venture called yaSSL (yet another SSL), which is based there.  I knew SSL had become the standard for web browsers and small-footprint embedded systems. From 1995 to 1998, I was running a security product (firewall and VPN) business at an international company, so I have a good understanding of security concerns, such as filtering, authentication, authorization and encryption. But both security and open source were behind me, and I did not bother to take a close look at his company. Occasionally, I would see his posts in LinkedIn and Facebook and knew his company was doing fine.

Sorry about the long introduction before the meat of the discussion of yaSSL. It is an open source security (SSL) product company. A short but good summary of yaSSL is given here. For the SSL tutorial, go to the yaSSL site.  yaSSL is a combination open source and security company. Understanding it is a piece of cake for me. Its business model is very similar to what MySQL had for sure and has now. They provide their SSL products with two licenses: GPLv2 and commercial. If you do not know what that means, you can find an explanation on their site.  But in a nutshell, the commercial version is the traditional commercial license deal, while GPLv2 allows you to make a copy of the source (product) and any number of changes to the product, as long as you contribute your changes back to the project.

The advantages of open source over closed source are often cited. I used to listen to Larry's pitches on their merits. A partial list includes:

• Inexpensive because no license fee

• Easy to adapt to your own environment

• Market needs quickly reflected by community response

• Quick support by the community

• Debugged by a large number of community eyeballs

See four gentlemen whom I met at their booth at the RSA conference. yaSSL was founded by two people, Larry Stefonic and Todd Ouska, both pictured below with early employees John Safranke and Chris Conlon.

From left: John Safranek, Todd Ouska (cofounder), Larry Stefonic (cofounder), and Chris Conlon .

Their products are also geared towards embedded systems. Yes, I did embedded systems as well and know how tight their requirements are for executable footprint and memory sizes. Their products are listed here:

• CyaSSL is a C-language-based lightweight SSL library targeted for embedded and RTOS environments, primarily because of its small size, speed, portability, and feature set.

• yaSSL is a C++-language-based SSL library for developers more comfortable with that language.

• yaSSL Embedded Web Server is a fast, embeddable, and easy-to-configure web server with a strong focus on portability and security. It offers HTTPS support built in through the CyaSSL embedded SSL Library.

• yaSSH is a small, portable SSH implementation currently in its early phases targeted for use by embedded systems developers.

SSL and its improved version, Transport Layer Security, are IETF standards now.  There are, naturally, differences among the different versions of SSL and TLS. yaSSL supports SSL 3 as well as TLS 1.0, 1.1, and 1.2. Many copies exist over the Internet, and they are compatible with all the major versions.

Their competitive messages are well described on their booth banners.

There is a Wiki page for comparison of available TLS solutions, open source or not, in which yaSSL is listed along with open source and closed source solutions. 

Among the open source versions, CyaSSL (C version) is often compared with OpenSSL. You can find the comparison by contacting them at info@yassl.com. However, one thing that caught my attention is their footprint size. It ranges between 30 and 100 kB, and the runtime memory use ranges from 3 to 36 kB. This is very small. With these resource requirements, their product can be integrated into a tiny wireless sensor, and such sensors are considered the new culprits causing Big Data. As in any data transmission, data by those sensors must be encrypted for security reasons, especially when used for strategically important infrastructures like the power grid. With good security available, such sensors will be deployed more widely.

It was imperative that they make their software smaller to fit into a tiny sensor with limited power. I assume they used every method available for size reduction. When we look at current software development for larger systems like servers and workstations, including PCs and laptops, we take it for granted that infinite hardware resources are available, and convenience rather than efficiency or performance dictates our choices. Most web languages are script rather than compiled, taking more resources to execute. Executing script languages generally requires more powerful processors and more memory, and those consume more resources.

Green IT means two things: greening IT and greening other things by IT. Most discussions center on making hardware greener, but not software. If we can design and implement smaller and more efficient software with an algorithm that minimizes resource use, we can keep energy consumption to a minimum. I am not advocating that we write software in machine or assembly languages. But we can do a better job of developing software for energy efficiency. Because we throw more resources at convenience, I feel programming in nonembedded systems has lost a sense of efficiency. We can only attain so much energy efficiency by working simply on hardware alone. It is about time to pay more attention to software for energy efficiency. I am not talking about making other things more energy efficient but software itself. More discussion of this to come.