TheOpenForce.com

A few days ago, Gatsby, the company I work for, took the unusual precedent to condemn the military invasion of Ukraine by Russia. Why is a small tech company making such a statement? As has been often said, the only thing necessary for the triumph of evil is for good people to do nothing.

Ukraine is a country with a rich history of technology and entrepreneurship. There are tens of thousands of entrepreneurs, developers, designers, scientists and engineers employed in the technology industry. Ukraine has become part of the global technology industry. They have shown great leadership and innovation with companies such as Affirm, Gitlab, Grammarly, JustAnswers, PandaDoc, Preply, Sisense and many others.

Gatsby, though a small company, is also global, with employees and customers in many countries around the world. We are part of an open source movement that enables anyone to use our technology to build web sites.

Global technology and open source software enable the world to be a better place for everyone, providing opportunities for developers in every country. We believe in the forward progress of technology to enable people to develop better lives for themselves, their families and their communities.

Putin’s invasion of Ukraine is a threat not only to Ukraine but to worldwide democracy. The attack upon Ukraine is destroying the lives of millions of innocent people.

In the world of tech, we have witnessed the immense constructive power of open sharing of ideas, and voluntary collaboration. We have built models where people can disagree yet productively work together across the globe.

We believe in a world with a level playing field where anyone can aspire to become the best version of themselves. A civilization where ideas and opinions can clash but people respect each other.

The war initiated on 24 February 2022 by Russia against Ukraine is not only an attempt at subduing one nation, it is an assault on democracy. It is an ugly strike against the rule of law. As Martin Luther King reminded us: injustice anywhere is a threat to justice everywhere.

That is why we are now speaking up. What we are witnessing is an assault on everything we believe in. At risk is the very foundation that societal progress has been built on over the past 80 years. We cannot stand by and ignore these actions.

We are taking action today to condemn this invasion. We are making a donation to Unicef to support the people of Ukraine and I encourage others in our community to do the same by donating to one of the many organizations that are helping.

The future of democracy is playing out right now in the streets of Kyiv. It matters to each and every one of us. Do not look away. Remember the only thing necessary for the triumph of evil is for good people to do nothing.

Where to Donate

• Unicef Ukraine 
• Ukranian Red Cross Society
• Voices of Children
• Save the Children
• Ukraine Now
• Global Giving
• The UN Refugee Agency
• Tech To The Rescue 

Support in the Tech Community
We will update this list with additional statements of support over time.

• Snyk 
• Grammarly
• PubNub
• Grammarly
• HackerOne
• Apple
• Microsoft
• Cisco
• Index Ventures
• Drupal Association Statement of Support for Ukraine
• An open letter from Russian scientists and science journalists against the war with Ukraine

#TechForUkraine
#StopTheWar

It was twenty-five years ago today that Anders Hejlsberg and I got up on stage at the Software Development '95 conference and launched Delphi to the world. The joke was that all 1,500 of us were geeks who couldn't get a date even on Valentine's day. 

We knew Delphi was a good product. Maybe even a great one. Our beta testers loved it, the team was excited and we had a 32-bit version in the works for the upcoming Windows 95 OS that would be bigger, better and faster. But the scale of Delphi's success took us by surprise. The Borland booth was mobbed at the conference. Delphi, with the help of DavidI and Charlie Calvert, gave birth to an ecosystem of third party books, magazines, component libraries and more. I've met countless developers over the years who told me Delphi enabled them to learn Windows development, build their career, their business.

So what made Delphi so good? You gotta give credit to Anders. He is probably one of the ten best programmers in the world and certainly the best developer I've ever worked with. He had more than ten years of compiler experience under his belt when we built Delphi. He knew exactly what tradeoffs mattered in language design to balance programmer productivity with machine performance. Delphi compiled to machine code at the speed of 35,000 lines per minute on a 90 mhz pentium. I have no idea how fast that is on today's machine. But you could load a demo program, hit the run button and by the time you clapped your hands together it was running. And I clapped my hands together ever time I gave a demo, just to make the point. 

As Anders pointed out that night on stage, Delphi was written in Delphi. So the team that built Delphi (and it really was a team: Anders, Gary, Chuck, Dave, Allen, Hank, Ray, Marc, Danny, Charlie) used it every single day. We made it great because Delphi was the tool that we wanted to use. It was pretty mind-blowing when Anders loaded the Delphi project source code into Delphi and compiled itself. 

The Delphi project was not an easy one though. It came at a tough time in Borland's history. The company was sued by Lotus in 1990, acquired Ashton Tate in 1991. By 1993, the company essentially sold off Quattro Pro and Paradox to Novell after Microsoft decimated the standalone spreadsheet and end-user database market. Oh yeah, and the founder and CEO, Philippe Kahn left to create Starfish Software a month before we launched. Philippe helped protect Delphi as a skunkworks project when we started and he coined the codename VBK (ahem) which none of us liked, but all of us believed in. 

We knew if Borland was to stay relevant in developer tools, we needed to build something better than Visual Basic. We never saw Delphi as VB Killer, but certainly a VB Kompetitor. How would we compete with that behemoth? Well, we weren't cocky, but we also weren't afraid of Microsoft. We had to make Windows programming easy enough that a DOS programmer could do it. And in that regard, our prior efforts with Turbo Pascal 7, missed the mark. Borland had a couple of other internal efforts that never saw light of day (Monet, anyone?) and at some point, Gary, Anders and I came to the realization, someone had to make it happen, and that someone was us. Having a native code compiler meant that Delphi would have a huge performance advantage over interpreters. It also meant Delphi developers would be able to create their own reusable objects without having to learn a different language. That gave us huge extensibility. 

We also learned there was another change on the horizon and that became our opportunity. Borland VP Rob Dickerson had highlighted the need for the company to build a client/server development system. Again, we looked around and we realized Paradox wasn't going to do it, dBase wasn't good enough, C++ was too hard. And so I put up my hand and convinced Gary and Anders not only did we need to make Windows development easy, we had to take on Client/Server development at the same time. Luckily they agreed, not knowing what Client/Server development meant. I didn't either, but I trusted we would figure it out. Ultimately this became our biggest differentiator in the market. While our performance over VB could be 2-3x faster, compared to SQL Windows or PowerBuilder, Delphi was 5-50x faster, and sometimes 800x faster. 

When we first started, we thought the project might take a year, but that Client/Server stuff was a lot harder than we expected. One of the developers working on that area eventually left the company and when Chuck and Anders looked at his code they just about barfed. That cost us about six months. I'm pretty sure every single person working on the project came to see me and said: "Can't we forget that Client/Server thing and just ship the desktop Windows version?" But my answer was always the same. I drew a curve of what Delphi desktop revenues would be. Then I drew a second line for Client/Server below the first one but growing at a steeper angle, eventually eclipsing the desktop revenues. I don't know if anyone believed me (and I honestly didn't know if I believed it myself) but it put an end to the discussion.  

I knew that the Client/Server product was more important strategically for the company because it would expand our market beyond Borland's traditional base. Ironically, at some point my boss VP Paul Gross asked why we were working on the desktop product, suggesting we skip that completely. I told him Delphi desktop revenues would be $30 million in the first year (a number I made up on the spot) and he nodded and said "good point."  

Delphi's first year revenues were $70 million (far higher than we'd expected) and grew from there. That's about $118 million, adjusted for inflation. And the Client/Server revenues really did eclipse the desktop revenues in the second year. To say Delphi saved Borland was not an overstatement. 

We also made a good bet on shipping a 16-bit version of Delphi first, rather than jumping straight to 32-bit. It was a safe assumption that Microsoft would slip Chicago (Windows 95). So we had a stable 16-bit compiler and operating system and could work on that without having to worry about the ground moving beneath our feet. We were fortunate to get the 32-bit compiler under development in parallel, shipping it just about 12 months later as Windows 95 was gaining market share. Delphi 2.0 boosted performance another 3-4x giving us an even bigger lead.

When we built Delphi we never thought it would last so long or have as much impact as it did. We were grateful for the support and feedback from our customers and third party developers. While we weren't obsessed with press coverage and awards, we were happy that it helped get the word out. I still have the Jolt Cola award on my bookcase. I figured if Delphi lasted to version 3.0, that meant we did a good job. But twenty-five years? Who could have guessed?

Looking back on Delphi 1.0, much of those two years is a blur of sixty hour weeks, late evenings and occasional setbacks. But the memories that stand out were about the team. We were committed to building something great, something that we would use. Gary and Anders (and Chuck, and Danny...) all had great taste. So there was a kind of aesthetic to the product. It's hard to explain, but we knew it as "it works the way you hope it would." Delphi wasn't just fast, it avoided the limitations of many Rapid Application Development (RAD) tools that ran out of gas when you pushed hard. 

I've done a lot of interesting things in the last twenty-five years, but Delphi is the product I'm most proud of. It was a magical time in our lives when we were experienced enough to do good work and young and foolish enough to bite off more than we could chew. We solved some hard problems that mattered in a market that we understood and the market responded. It shaped my thinking about how to build products in ways that I continue to use and teach to this day.

I'm grateful to Anders and Gary that we took on the project. Gary is the best engineering manager I have ever worked with and I was glad to get to work with him again at MySQL. Anders, of course, has gone on to do even greater things architecting C#, .Net and TypeScript. I'm proud of the many developers, writers, and testers, product managers and marketers (Lance, Diane, Ben, you were awesome), who built on the early success of Delphi 1.0 to create a legacy that has withstood the test of time.

And thank God we finally got that darned Language Reference Manual out. 

Got a recollection of Delphi 1.0 or a story about Anders, Gary or me? Post a comment below...

• Delphi Informant: Birth of Delphi
• Danny Thorpe: Why The Name Delphi?
• Anders Hejslberg: .EXE Interview 

This article appeared in Delphi Informant magazine in April 1996 discussing the development of Delphi 1.0.

One of the most fun things I’ve done in my career is to help build the “1.0” version of Delphi. Okay, 2.0 was pretty fun too, but, as they say, there’s nothing quite like the first time.

When we started building Delphi 1.0, it was hard slogging. A lot of the tools out there, like PowerBuilder, SQL Windows, and Visual Basic were pretty good. Long before we even had a prototype up and running, I was on the road talking to developers to understand the problems they were facing. Most of them were pretty happy. I remember particularly thinking that the VB corporate users by and large were just the happiest bunch of developers I’d ever met. Heck, they were even having fun! I remember one particular meeting with about a dozen developers from a major airline. They told a not uncommon story of how a senior VP had decreed that they would use Visual Basic after he prototyped an application on a weekend. The developer told me that he didn’t want to have any association with — ugh — Basic, but after trying it out for a while, he changed his mind.

Another time, I was meeting with a development team at a Wall Street foreign exchange. They showed me this tremendously impressive application for monitoring currencies — written in SQL Windows. It was beautiful. I thought, “Oh no, another satisfied customer. Time to move on.” So after a demonstration I asked how they liked the application. His answer: “It’s a dog.” The response time was simply too long to even be considered for production use. After all, Wall Street practically defines the phrase “Time is money.”

I saw these scenarios repeated in meeting after meeting, city after city. On the surface, customers seemed pleased with the productivity gains of “Rapid Application Development” tools. But as I delved further, I found the love affair often came to a bitter end when they tried to move from prototype to production. I found lots of spaghetti code out there, and DLLs written in C to make up for performance bottlenecks in applications written in PowerBuilder, SQL Windows, and VB.

It was some nine months into the two years of the development of Delphi 1.0 before we showed it to potential customers. There were two reasons for that. First of all, Delphi was an underground project that was truly secret. Heck, for the first year we had more code names than beta testers! Secondly, and perhaps more importantly, I wanted to make sure we understood customers problems rather than simply gauging a reaction to a demonstration. That way we could ensure we were building the right product, rather than fine tuning the wrong one.

When we finally started showing Delphi to customers, the reaction was dramatic. After all, we were solving the problems they had told us about. Our mantra: “Performance, Reuse, RAD, and Scalability.” This helped us to not only define the product, but to communicate the benefits to the customer.

Oddly enough, one of the problems we faced was how to name the product. As Jerry Coffey pointed out in this column [“Symposium,” Delphi Informant, January 1996], we were experimenting with all kinds of names. Although we had early on decided that “Pascal” should not be included in the name since it wasn’t really meaningful except to long-time fans, we really hadn’t made much progress on the name until a few months before its release.

Leading contenders included “Visual AppBuilder” (luckily, it was taken) “Application Architect” (too much like a CASE tool), “Client Builder” (sounds like a sales prospecting package), “Object Vision” (ahh, we used that already, didn’t we?) and just about every combination of the words “Visual”, “Power”, “SQL”, “Application”, “Object”, and “Builder” (“Visual Power SQL Application Object Builder” anyone?)

As we were in the late stages of selecting a name, whenever I’d do a presentation, whether to potential customers, sales reps, or third party vendors, I’d always ask them what they thought of the proposed names like “AppBuilder.” Invariably, the response was lukewarm. Then they’d ask, “Why don’t you just call it Delphi?” So in the end, we did.

Danny Thorpe, then on the QA team, now currently part of the R&D group, had came up with the original code name “Delphi” since it was to be a client/server tool connecting to the likes of Oracle among others. We had to come up with a code name for our first beta test and everyone felt that Delphi was acceptable. We had many later code names for internal use, external use, different countries, and at one point, I must admit, I randomly made up a new code name for every presentation, so that if there ever was a leak, we’d know from where it came.

Delphi 2.0 has come a long way since then. Our original goal was to address a few of the usability issues and also migrate to a 32-bit compiler and take advantage of platform features like OLE automation, OCXes, etc. Along the way, we introduced several major innovations like Data Module Objects and Visual Form Inheritance that increased code reuse.

The 32-bit compiler itself was actually started way back when the original 16-bit version of Delphi was started. At the time it seemed like a safe bet that “Chicago” (Windows 95) would slip out of 1994 and that Windows 3.1 would still be a viable development platform for Delphi 1.0. We were able to have most of the VCL ported to 32-bits and running with the new compiler prior to the release of Delphi 1.0. So we were quite confident that the architecture would ensure compatibility with most code from Delphi 1.0, assuming it wasn’t dependent on 16-bit data assembler, data structures, or unsupported API functions.

Although it’s a bit too early to announce plans for the next version of Delphi, we’re certainly working on a number of fronts to further reduce the amount of code folks need to write, and make it easier to support very large projects.

Zack Urlocker is Director of Delphi Product Management at Borland International. The views expressed here are his own. He can be reached on CompuServe at 76217,1053.
(Well not anymore!)

by Danny Thorpe

This article originally appeared on the Borland museum website. 

"Delphi" started out as a beta codename for a closely guarded skunkworks project at Borland: a next-generation visual development environment for Windows based on Borland's Object Pascal programming language. The codename hatched in mid 1993, after the development team had been through about 6 months of deep research, proof-of-concept exercises, and market analysis. Members of the then Pascal development team were hanging around R&D Manager Gary Whizin's office brainstorming clever codenames to use for the new product. It was not a large office, but it was not a large team either - about 10 people between R&D, QA, Pubs, and Marketing. It would have been odd not to see Anders Heilsberg, Chuck Jazdzewski, Allen Bauer, Zack Urlocker, Richard Nelson, myself, and several other regulars jawing away on some topic or another in Gary's office. For the codename jam sessions, there may have been some overflow into the hallway.

Borland has a long history of "unusual" codenames, some with catchy slogans or backgrounds that tie the odd name to the market or product focus. A codename should have no obvious connection to the product, so that if an eavesdropper overhears the name in conversation it won't be too obvious what product is being discussed. The difference between an everyday disposable codename a great codename is the pithy passphrase behind it. The most memorable for me was the codename for Quattro Pro 4.0: "Budda". Why? It was to assume the Lotus position!

So we were sitting in Gary's office, kicking around weird and wacky codename possibilities. The strategic decision to make database tools and connectivity a central part of the new Pascal product had been made only a few days before, so Gary was keen on having a codename that played up the new database focus of the proposed product, and of its development team. The database shift was no small matter - I remember having grave reservations about "polluting" the Pascal tools with database arcana that took me almost a year to shake off. It was a big gamble for Borland, but it was very carefully measured, planned, and implemented. In hindsight, making Delphi a database product was exactly what was needed to break Borland's Pascal tools out of the Visual Basic - C++ market squeeze play and set Delphi head and shoulders above traditional Windows development tools.
Gary kept coming back to the codename "Oracle", referring to SQL connectivity to Oracle servers. "Oracle" didn't fly with the group, though. Aside from the obvious confusion with the same-name company and server product, the name itself implied server stuff, whereas the product we were building was (at that time) a client building tool, a way to talk to Oracle and other servers.

How do you talk to an oracle? "The Oracle at Delphi" was the word association that popped into my head. So I offered up "Delphi": If you want to talk to [the] Oracle, go to Delphi.
The suggestion wasn't an instant hit. It's an old name, an old place, a pagan temple in the ruins of a dead civilization. Not exactly an inspiring association for a new product! As some press articles later noted, the Delphic Oracle was particularly infamous for giving out cryptic or double-edged answers - not a great association for a data management tool. Asking a question of the oracle was free to all, but having the oracle's answer interpreted and explained (compiled?) cost a pretty drachma. (The marketing guys liked that part)
Overall, though, the "Delphi" codename had a classier ring to it than the sea of spent puns that littered the room. Pascal is a classic programming language, so it just felt fitting somehow to associate a Pascal-based development tool with a classical Greek image. And as Greek mythologies go, the temple at Delphi is one of the least incestuous, murderous, or tragic ancient Greek icons you'll find.

We went through a lot of codenames during the development of that 1.0 product, coining a different codename for each press or corporate briefing of the beta product. This was an effort to limit rumors and allow us to track the source of leaks. The last thing we wanted was for you-know-who to get wind of what we were up to. Through all these disposable codenames, the Delphi codename stuck. Towards the end of the development cycle, marketing started using the Delphi codename across all prepress and corporate briefings, and as the codename for the final beta releases. That got the rumor mills talking to each other, and the tools industry was abuzz with talk about this secret project at Borland codenamed "Delphi". J.D. Hildebrand wrote a whole editorial in Windows Tech Journal about the "Delphi buzz" months before the product was launched. (paraphrased: "I can't tell you what it is, but I can tell you this: Delphi is going to change our lives.")

When it came time to pick a retail product name, the nominations were less than inspiring.. The "functional" name, a name that describes what the product actually does and is therefore much easier to market and sell, would have been AppBuilder. This name actually still appears in some IDE internal class names, such as the class name of the IDE main window. (R&D caved in to the functional name pressures and set about implementing it early) But AppBuilder didn't light up people's imagination. It didn't work well internationally - functional names are only functional in their language of origin.

Thankfully, a few months before Delphi was scheduled for release Novell shipped their own product called Visual AppBuilder. There was much rejoicing in the Borland halls, for at last the "AppBuilder" debate was laid to rest. With the functional name taken out of the running, suggestions started coming from all quarters to use the Delphi codename as the product name.

Delphi wasn't home-free yet. The lead marketing person had legitimate concerns about the extra effort that would be required to build name recognition in the marketplace for an "iconic" (opposite of functional) product name, so he requested a vote of the development team. There was only one vote against (guess who?). Much to our chagrin, someone came to the conclusion that the development team's views were not an accurate representation of the marketplace ("sample error" was the phrase I heard), and pressed for a survey of the beta testers. When that poll didn't produce the result he wanted, the survey was broadened again to include Borland's international subsidiaries, press, market analysts, stock analysts, corporate accounts, software retailers, and probably a few K-Mart shoppers. It became a bit of a comedy: the harder people tried to dismiss "Delphi" for the product name, the more it gained support.

"Delphi" has a classical ring to it. It has a consistent meaning/word association worldwide in all languages. It has no embarrassing vulgar slang meanings in other languages (that I'm aware of). Most of all, the marketing guys had done a marvelous job of building up market anticipation and buzz around the "Delphi" name. The market was primed and ravenous for this thing called "Delphi".

And that, boys and girls, is how the Delphi product got its name.

Danny Thorpe  joined Borland in 1990 around the same time I did. He worked on the QA Team for Turbo Pascal and later as part of the original Delphi team. Danny came up with the Delphi name and later worked on key parts of the compiler, VCL library and IDE.   

I must have read a dozen books about the founding of Apple Computer over the years, so when co-founder Steve Wozniak wrote his autobiography iWoz a few years back, I made a mental note of it, but never got around to reading it. Woz and I happened to be speaking at the same conference last week. They say you should never meet your heroes, but meeting Wozniak was a real honor. He is one of the most talented engineers and nicest guys I've met. His onstage interview was a bit scattered (imagine opening a faucet of Woz), but it was great to hear him speak about his experiences in designing the Apple II computer, how Basic and Visicalc helped turn the Apple II into a platform, the importance of privacy in social media, etc. 

iWoz is co-written with veteran PC Week reporter Gina Smith though told in Woz's unique style. Smith spent over a thousand hours interviewing Woz and then transcribing and reviewing the interviews and suffering through numerous Woz pranks. Woz's sense of humor and lightness come through in spades.

Although Woz was less a part of Apple than Steve Jobs in later years, those who know the history know that Apple would not have existed without Woz. The Apple II computer effectively created the personal computer revolution. It was first all-in-one design, the first computer that you could plug in and use. The Apple II+ was the first computer I bought and I still have one in my closet. It works perfectly 40 years later.

With the average iPhone app today weighing in at 100mb or more, it's hard to appreciate how much work went into creating software that could run on a 48k machine running at 1Mhz. It was Woz and other early apple employees like Randy Wigginton, Chris Espinosa, Bill Fernandez, Daniel Kottke, who labored to make that Apple II a reality. Woz, gave some of these early employees shares of stock worth tens of millions of dollars out of his own pocket when Jobs refused. 

For those interested in the history of Apple, this book is a unique opportunity to hear it from the guy who built it. You get everything from selling blue boxes with Steve Jobs to how he built what became the Integrated Woz Machine (IWM) disk controller for the Apple II and Mac.

Here are a few excerpts from the Q&A with Woz:

• Amazon: iWoz
• Wikipedia: Steve Wozniak, Apple II, Apple II+
• Byte Interview: History of Apple Part 1, Part 2
• Press coverage: NY Times, Wired

Stephen O'Grady at RedMonk has launched a new Podcast called Hark. In his second episode, he and Agile programming guru Kent Beck have a thoughtful discussion around the ideas in O'Grady's book "The Software Paradox."  Even though software is "eating the world" and become more widespread and strategic, its economic value appears to be declining rapidly. Certainly, we've seen a shift in the industry from traditional on-premise software commercialization to distribution models like open source, and software-as-a-service, with vastly different business models.

Simply put, the software industry is undergoing a significant disruption that is reshaping the economics of the industry and rendering older "tried and true" business models obsolete. And at a level that strikes closer to home for many, it's also reshaping employment models and careers. Although the parallels are not perfect, the software industry is going through a transformation much like the publishing industry or the music industry. (And we all know how well that turned out for writers and musicians!)

I would argue this has transformation has been going on for at least ten years already since the emergence of successful open source companies. In the early days of MySQL, Marten Mickos regularly talked about how his goal was to disrupt the database industry taking it from $9 billion in revenue to $3 billion, and then capturing a third of that. While this was possibly more bravado than business plan, it was based on the fact that MySQL was 90% cheaper than Oracle. (And for many, MySQL was 100% cheaper --after all, it was under a GPL license and free for most users.)

While we built a solid business with MySQL, growing it to just short of $100m in revenue and selling it to Sun for $1 billion cash in 2008, the long term impact of MySQL was far higher outside the database industry. MySQL, Linux and other open source infrastructure software spawned thousands of businesses that simply would not have been economically possible under traditional commercial licensing fees. We routinely met founders of companies that said their business was enabled in part because of the dramatically lower cost of building an IT infrastructure. So at least some of the value that MySQL disrupted was captured not by traditional software companies, but by newer companies like Facebook, Google, Skype, Craigslist, Priceline and the like. And many of those businesses also happened to be disruptive, which is why software is eating the world. 

Not surprisingly, there have been very few home runs in the open source business, at least as measured by revenues or exits. Red Hat, JBoss, Pentaho have all been successful as businesses and have had good payouts for their investors. But many more open source projects have had widespread popularity with remarkably little economic value generated. And that is precisely the nature of the Paradox. 

And as Mickos has recently noted "The bad news is: it's almost impossible to make money on open source. The good news: it has happened many times."  But at this point it's hard to say what the future successful models for software commercialization might be, but it's certainly not going to be the traditional on-premise up-front license model. And I don't think open source, in all its various forms, is likely to generate a large number of economic home runs. There are definitely a handful of promising companies like Acquia, CloudEra, DataStax, MuleSoft, PuppetLabs, SugarCRM and the like, but they may be more the exception than the rule. (If I missed other rapidly growing open source companies, let me know in the comments below.)

Likely we will see more divergence over time with more value realized in other forms, whether it's service-based models, cloud-based businesses, advertising, data aggregation or perhaps something as-of-yet to be invented.

It's a fascinating topic with more questions than answers at this point.  And I'm sure we'll see more discussion on this topic at the Monktoberfest conference in October. 

The Hark podcast is available on iTunes, SoundCloud or wherever you get your downloads.

• Redmonk: Main site, Monktoberfest, Stephen O'Grady, James Governor
• Hark Podcast: iTunes, SoundCloud, Stitcher, Redmonk, Android, Twitter
• Amazon: The Software Paradox

There is a good article over at Re-Code by ex-Microsoft VP Steven Sinofsky called "The Four Stages of Disruption".  It describes the evolution of products and markets through disruption, drawing from Sinofsky's own insights and also building on the work of Everett Rogers ("The Diffusion of Innovations") and Clayton Christensen ("The Innovator's Dilemma.")  There are few software industry execs with as much experience in shipping billion dollar software products as Sinofsky.  And he understands how brutal it can be to manage large teams.  In my view, Sinofsky is always worth reading, though he can be a bit, ah, verbose at times.

There are dozens of examples of disruptive technologies and products. And the reactions (or inactions) of incumbents are legendary. One example that illustrates this point would be the introduction of the “PC as a server.” This has all of the hallmarks of disruption. The first customers to begin to use PCs as servers — for application workloads such as file sharing, or early client/server development — ran into incredible challenges relative to the mini/mainframe computing model. While new PCs were far more flexible and less expensive, they lacked the reliability, horsepower and tooling to supplant existing models. Those in the mini/mainframe world could remain comfortable observing the lack of those traits, almost dismissing PC servers as not “real servers,” while they continued on their path further distancing themselves from the capabilities of PC servers, refining their products and businesses for a growing base of customers. PCs as servers were simply toys.

At the same time, PC servers began to evolve and demonstrate richer models for application development (rich client front-ends), lower cost and scalable databases, and better economics for new application development. With the rapidly increasing demand for computing solutions to business problems, this wave of PC servers fit the bill. Soon the number of new applications written in this new way began to dwarf development on “real servers,” and the once-important servers became legacy relative to PC-based servers for those making the bet or shift. PC servers would soon begin to transition from disruption to broad adoption, but first the value proposition needed to be completed.

Sinofsky makes a number of good observations on how markets and products evolve through disruption.  But there is a certain irony to reading about disruption by a Microsoft exec.  Is Microsoft a disruptor or a disruptee?  I'd say Microsoft has been on both sides of the disruption equation.

In the early days, Microsoft was a pioneering company that created vast new markets where none existed.  If Microsoft products were not initially the best in their categories, their persistence and steady release cycles gave them the features they needed to beat competitors in just about every category in which they competed, whether operating systems, applications, or networking software.  There were some notable exceptions, such as Microsoft's failure to beat Quicken in personal finance software.  But in general, Microsoft was the 800 pound gorilla in the market and few were brave or foolish enough to tackle them head on.  

The most clear example of Microsoft being a disruptor was it's entry into "back office" markets for server software as Sinofsky described.  The "Wintel" combination of Windows server software and Intel X86 architecture had a profound effect on redefining the server market.  It enabled large corporate Enterprise customers to move server workloads off expensive proprietary Unix systems for a fraction of the price.  You could argue that SQL Server was not as good as Oracle or that NT was not as good as Unix, but for many users it was "good enough."  And Microsoft was smart enough to add Enterprise DNA to the company to help them build this new class of software.  I'm sure in some cases the incumbents saw what Microsoft was doing, but dismissed it's solution as mere "toys."  And by the criteria of the incumbents that was exactly so.  

But where did all that disruption mojo go in recent years?  The emergence of smartphones and cloud-based software left Microsoft flat-footed.  New versions of Windows have been acknowledged failures.  It's rebooted it's mobile and cloud offerings several times.  And in the last couple of years there's been a steady stream of departures from the executive suite including Sinofsky, Bob Muglia, Hank Vigil, Craig Mundie, Ray Ozzie, Robbie Bach, J Allard, and soon Steve Ballmer.

In the mean time, Apple, Google, Amazon, Salesforce, Box and others have been the innovators coming up with new cloud-based offerings and products that have disrupted incumbents including Microsoft, HP, Dell and others.  

So what do you make of Sinofsky's article?  How is it disruptors get disrupted?  Let me know in the comments.

• Re-Code: The Four Stages of Disruption
• Amazon: The Innovator's Dilemma

Although I took most of the summer off, I did spend some time with various San Francisco business incubators including Heavybit (which focuses on infrastructure and tools) and Hub Ventures (focused on technology with social good).  And I'm familiar with probably another half dozen incubators in the SF Bay Area where I either know people or have spoken at or attended various panels.   

Of course, you would expect San Francisco to have lots of incubators.  But what's surprising to me is just how many business incubators and accelerator programs there are in North America --several hundred it seems. Not to mention numerous incubators in Europe and Asia.  And each one seems to have a couple of dozen promising tech startups.  While the costs of starting a company have fallen dramatically with open source, SaaS and cloud technology, I'm not sure the odds of success have risen.  If anything, the low-bar to creating companies is making the early stage startup market even more competitive.  Every good idea seems to spawn more than it's share of copycats and wannabe's.

While there are real benefits from the mentorship and connections you can make at a good incubator, it seems that the rush to create many tech companies has spawned some pretty lousy incubators.  David Cohen of TechStars recently posted "A Horrifying Accelerator Story You'll Need to Read Twice" that tells the tale of an unnamed incubator from the perspective of a participating startup company.  Short version: lots of promises, psychotic drama and bushel of lies: 

A month later, we’d seen or heard from the founders of the top-billed startup exactly zero times and there had been exactly zero sessions for learning... By the end of the 4 months, their total time invested was 45 minutes with the accelerator. It was very strange given the outline for the program included a very specific syllabus with promises of luminary speakers, tech for non-tech founders, and more. None of it happened.

If you're giving up equity make sure you do your homework before choosing to go with any incubator.  And in particular, speak to companies who are at or have graduated from the program and find out whether the promises of mentorship, investor connections and demo days paid off.  Did they launch their product or service?  Did they get funding?  Are they making money?  While everyone knows most startups have long odds and won't make it in the long run, it's worth remembering that it's probably also true for many of the incubators themselves.  

• HeavyBit: Main site, Program, Companies
• Hub Ventures: Main site, Program, Companies
• Seedcamp: Main site, Program, Companies
• GigaOm: What History Teaches Us About Startup Incubators

A few months back, I wrote a guest editorial over at VentureBeat called "How to Protect Yourself from a Twitter-Fueled PR Disaster".  Somehow, I forgot to do a cross-post.  Here's an excerpt:

Facebook, Twitter, YouTube, Yammer, Flickr have changed the world. What started out as a way to hunt down old high school pals has revolutionized how we communicate with friends, family, and businesses. On the business side, a few retweets, and a single offhand comment can spark a PR disaster. Papa John’s realized this when a photo of a racist comment on a receipt blew up on Twitter within minutes. Both Verizon and Bank of America had to scrap newly proposed user fees after customers waged a full-blown protest via social media. And we all know how Netflix got an earful when it sprung a new pricing structure on its customers.

The point is, in the customer service realm, where customers’ interactions with a company are now incredibly public and visible, social media has created a newly empowered “collective” customer. Customers, not companies, are controlling how customer service policies are created and implemented...

Perhaps the best way for corporations to leverage social media is to regularly solicit customer feedback through online surveys and customer satisfaction ratings. These and related inexpensive tools give you invaluable information about customer perceptions and needs. Armed with this, you can create the best solutions and staff customer service teams at times when they’re needed the most.

You can read the full article at VentureBeat. 

Last fall, before I joined Zendesk, I took a role as an Executive-in-Residence at Scale Venture Partners. A lot of people asked me about this, so I've written an article at GigaOm that describes my thought process and what I ended up working on.

While there are as many variations on the EIR position as there are venture firms, there are two flavors, generally speaking: Entrepreneur-in-Residence and Executive-in-Residence. Most firms have some experience with Entrepreneur-in-Residence programs. Essentially, they give office space, coffee and food to a proven entrepreneur so he or she can spend a few months researching or prototyping a new product or service...

I’m not the inventor type, and I didn’t want to just “hang out” at a venture firm to look at their portfolio companies, so I proposed doing a specific research assignment with Scale Venture Partners. Scale typically invests in late-stage Series B or Series C companies, which made it a good fit. I am good at scaling companies, but I don’t know that I’m any better at predicting which Series A investments will thrive than anyone else.

The key area of my research was to analyze some specific developments around Software-as-a-Service (SaaS), big data and NoSQL. This entailed studying the technologies in this area, understanding the optimal use cases and speaking to a broad range of customers and prospects to see what was actually happening in the marketplace and what patterns were starting to emerge. I also worked with the senior partners at Scale to determine how to keep them up-to-date with my findings and how the results would fit into their overall software investment strategy. The important takeaway was that a venture firm is not a research house. At the end of the day, they would measure the success of this effort by whether it helped them make better investments.

While I could have done my research on my own, it was helpful to have an office to go to, access to research materials and introductions from the Venture partners to companies that were using some of the new technologies. While I was primarily focused on pursuing my research, I also gave the investors my perspective on a couple of portfolio companies.

Working as an EIR was one of the most interesting projects I've done.  While it was a short, concentrated time, it exposed me to some new ways of thinking about managing the growth of a software company and how to think like an investor.  The contacts I made were also invaluable.

You can read the full article over at GigaOm or a slightly expanded version at Scale Venture Partners' site.  The full version also includes some tips for those who are thinking about an EIR role and how to determine the best match with your own needs.  

Zack Urlocker is Chief Operating Officer at Zendesk, a cloud-based help desk provider.  He was previously the Executive Vice President of Products at MySQL where he was responsible for Engineering and Marketing and helped grow the company to $100 million in revenue.  Urlocker is an investor, advisor and board member to several software companies.  He's also an occasional marathon runner and blues guitarist.