At the end of 2016, I ceased to be an employee of UnboundID and became an employee of Ping Identity. Ping acquired UnboundID in early August of 2016, but most UnboundID staff remained employees of that company through the end of the year (mostly for bookkeeping convenience). As a co-founder, I was with UnboundID from the beginning. Here is our story.

Once upon a time, Sun Microsystems had the best LDAP directory server on the market. The 5.1 and 5.2 releases of the Directory Server Enterprise Edition (DSEE) product, which introduced multi-master replication and 64-bit support, respectively, were very exciting.

But then for some reason, Sun’s directory server engineering team seemed to contract a chronic case of inertia, in which everyone was content to rest on their laurels. It certainly wasn’t because the product had reached perfection, nor from a lack of ideas for improvement. After a while, I became frustrated with the lack of progress, and I wrote a hundred-plus-page document (which became known as the “directory manifesto”) that was full of things that we could do to improve the product. It had plenty of low-hanging fruit that would address pain points that customers were experiencing and lots of bigger ideas to help ensure our continued dominance of the high-end directory server market. But to no avail.

Eventually, I was able to nag the right people long enough to let me start working on a new directory server that was intended to be a DSEE replacement. And thus I became the first developer working on what would become OpenDS. Sun was committed to open sourcing all their software, from Solaris to Java to all of their enterprise software, and before long, we released OpenDS under the same CDDL license that they initially created for OpenSolaris.

At that time, Sun’s Directory Server engineering team was mostly split between Austin, Texas and Grenoble, France. In 2007, someone got the idea that it would be good to have it headquartered all in one place, and Grenoble was chosen as that one place. As a result, the five U.S. employees most closely connected with OpenDS were laid off: director of engineering Steve Shoaff, marketing lead Don Bowen, engineering manager David Ely, open source community manager Trey Drake, and myself as architect.

It didn’t take the five of us long to decide that we wanted to create a new company developing on top of the OpenDS codebase. We were still passionate about the product and excited about the opportunities that it could afford, and we planned to contribute back to the open source community. We even followed through on that with a handful of commits within a couple of weeks of the layoff. But then some nastiness arose between us and Sun’s management that I don’t want to get into here, and it became clear that we were no longer welcome participants.

So by the time we founded UnboundID (on December 17, 2007), we were to be competing against Sun. We’d comply with the terms of the open source license when altering existing code, but newly-created files would be our own private intellectual property, as allowed by the CDDL. We would, of course, also go head-to-head with other directory server vendors, like Oracle (who bought Sun within a few months of our departure), IBM, Microsoft, and CA. And we’d be up against open source offerings like OpenLDAP and the 389 Directory Server. We should’ve had no chance. And yet we were shockingly optimistic. We had a lot of ideas, a lot of drive, and dare I say a pretty good amount of talent.

Upon officially forming the company, David, Trey, and I worked furiously to make improvements to the codebase. We made dramatic improvements in performance, concurrency, and scalability. We added killer features, like support for transactions, filtered logging, change subscriptions, data transformations, data integrity checksums, and some new controls and extended operations. We made the server easier to manage by improving the out-of-the-box configuration, refined the command-line and interactive text-based interfaces, and added a web-based administration console.

We also created a new Java-based API for interacting with LDAP servers, because the existing options sucked. Before we released the UnboundID LDAP SDK for Java, you could basically choose between the horrible, confusing clunkiness of JNDI (where LDAP support is bolted on as an afterthought), or the buggy and no-longer-maintained Netscape Directory API. We wanted to create an API that made it easy to write applications that could take full advantage of any LDAP server, including the enhanced functionality we were building into our own software.

While David, Trey, and I were churning out the code, Steve and Don were working to sell it. And they did. Amazingly, we got our first customer within a matter of months: a large network equipment provider that supplied telephone companies with the equipment used to run their data centers. They loved our software, our enthusiasm, our ability to react quickly, and our willingness to put our source code in escrow so they wouldn’t be screwed if we went out of business. And before long, a number of big telcos were kicking the tires on our stuff and salivating at the idea of a modern, high-powered, feature-rich, and administrator-friendly directory service.

This first customer was a huge win for us. They resold our software and provided first-line support, which helped alleviate any downstream concerns about our viability. They declared our software to be carrier-grade, which served as validation to other potential customers in other industries. And it was also nice to be able to start getting a paycheck.

Plus, we were able to leverage this deal to get good terms on an initial round of funding from an investor. We were able to hire more people (many of whom were former colleagues from Sun who were all too happy to jump ship from their new Oracle overlords), and we started working on new products. David took on the Synchronization Server, and I started on the Directory Proxy Server.

The Synchronization Server provides a way to mirror the contents of two or more data repositories, so that changes made in one system appear in the other systems, usually in a matter of milliseconds. It can do one-way or bidirectional synchronization. It can synchronize all the data or just a configurable subset. And you can connect to a number of different types of repositories, including LDAP directory servers (both UnboundID and non-UnboundID), relational databases, NoSQL databases, and more (plus an API for developing your own support for additional types of data stores). It’s ideal for migrating data from your existing repository into the UnboundID Directory Server, and for keeping both infrastructures in sync for whatever length of time is necessary to complete the migration, or indefinitely if you want to keep both systems up and running.

As its name implies, the Directory Proxy Server is an LDAP proxy server. In the simplest deployments, it allows you to achieve better performance and higher availability through load balancing and advanced health checking techniques. In larger deployments, you can use entry balancing to transparently split data up into multiple sets (much like database sharding) for even greater scalability. It can also transform requests and responses as they pass between clients and backend directory servers, and you can do this on a per-application basis in case some clients have different expectations for how the data should look or how the server should behave.

We continued to grow. We sold more software. We gained more customers. We hired more employees. We wrote more code. But sadly, we also suffered some losses. Trey decided it was time for him to move on, so he left the company. But even more tragically, Don Bowen passed away in late 2009. He’d been diagnosed with brain cancer a mere three days after we founded the company, and somehow he continued to make incredible contributions toward our success for over a year and a half. I met Don in my first job out of college, at Caterpillar, where he introduced me to the world of LDAP. Within a few months, he’d gotten an offer to join the Baltimore-based startup (initially called B2B Communications, but later renamed TidePoint Corporation) and he took me with him. When that went south, we went our separate ways, only to meet up again when we both joined Sun at about the same time. We were friends as well as colleagues, and a tremendous amount of who I am today is because of Don.

And the work goes on. As more customers migrated from existing environments and deployed into new environments, we realized that we needed to provide public interfaces to allow our software to be customized, so we created the Server SDK. Our server products had always been very extensible and componentized, but before the Server SDK, we were the only ones who could take advantage of that. The Server SDK made it possible for customers to write their own extensions to customize the behavior of the server, from intercepting and altering operation requests and responses, to creating new loggers, password validators, extended operations, SASL mechanisms, sync sources and destinations, proxy transformations, and more. The initial intention was to only make the Server SDK available to customers who’d gone through at least some kind of training (it allows you to run custom code inside the server, so there’s a chance that a buggy extension could make the server unusable), and I really wish we’d stuck to that more than we did. But for the most part, it was a hit with customers, and an even bigger hit with the sales engineers helping them evaluate and then migrate to our software.

We also introduced a couple of additional server products: the Analytics Engine and the Data Broker. The Analytics Engine (formerly called the Metrics Engine) provides simple, graphical access to all kinds of historical information about the operation of the server broken down in all kinds of ways (e.g., the number of requests per second of each operation type, and a breakdown of their result codes and processing times), along with metrics from the underlying system like CPU, disk, and network utilization. The Data Broker provides several REST-based interfaces to interact with the environment, including support for OAuth 2 and OpenID Connect (for authentication, authorization, and federation), and SCIM (for data access). As much as I love LDAP and will continue to tout its superiority over HTTP, the kids these days are all about the web APIs, so we must oblige.

But even as we worked on new products, the Directory Server continued to grow and improve. I am particularly passionate about security, so that’s been a big focus of mine over the last several years. We added support for data encryption, several two-factor authentication mechanisms, more password storage schemes and password validators, sensitive attributes, retired passwords, password reset tokens, improved account lockout, signed logs, and more. But we also added a lot of non-security-related features, like JSON support, alarms and gauges, soft deletes, assured replication, and indexing improvements. It’s gotten faster, easier to use and administer, and just plain better.

On the whole, we’ve had an unbelievable run. We did have one down year with less-than-stellar sales, but for all other years, we reached or exceeded our goals. That continued through 2016, which was one of our best years ever (even if you ignore the whole “our company was bought” thing). We certainly weren’t floundering, and we weren’t really even looking to be acquired. We had partnered with Ping Identity on a number of deals in the past, as each company’s software complemented the other’s very well without too much overlap. And then Ping was acquired by Vista Equity Partners, who were looking for other opportunities to get into identity management, and then people started talking and it all sort of became a three-way deal, with the UnboundID acquisition by Ping Identity following Ping’s own acquisition within a couple of weeks.

So what’s next for the bigger, better Ping Identity? I can’t get into any specifics, but we’ve got a lot of great things in the works. Most of the UnboundID staff, and I believe all of the technical staff, are continuing on into Ping. Some people are changing roles (many moving up, others moving laterally), but my job isn’t really changing all that much. I’m still writing code, and hope that continues far into the future. Some of our product names have changed (for example, it’s now the Ping Identity Directory Server rather than the UnboundID Directory Server), and some haven’t (it’s still the UnboundID LDAP SDK for Java), but we’re still working to ensure that they remain the best products out there. So I need to get back to work.

---

P.S. I know that the only people I mentioned by name in this walk down memory lane are the UnboundID founders. I certainly don’t mean to imply that we’re the only ones responsible for or vital to the company’s success. There are so many other people that made big contributions to the company that I can’t list them all without fear of leaving someone out, without fear of mentioning someone who’d rather be left out, and without fear of making this long post even longer. So let me just say that if you worked for UnboundID in any capacity, you have my sincerest thanks.