Pivotal Labs, in collaboration with VentureArchetypes (www.venturearchetypes.com), hosted an entrepreneur panel discussion on March 20, 2008.

(Details on the panel can be found at "Monetization Strategies for Startups: Great idea, but how will it make money?")

We had a great turnout and a fantastic panel. Enjoy the podcast.

Thank you again to our panelists:

• Katherine Barr of Mohr Davidow Ventures
• Ken Gullicksen of Morgenthaler Ventures
• Alex Le of Serious Business
• Nate Pagel of podaddies
• Peter Rip of Crosslink Capital

And our course, thanks to our attendees.

Podcast and Photos

• Panel Discussion
  Note: We've tried to clean up the audio as best we could. We are sorry if there levels aren't balanced.
• Photos on SmugMug
  (If there is a password required, it is 'va')

Following up from my previous post on the same topic, I'd like to clarify a few points that hopefully address several of the comments on the post.

While the title of the post may be provocative, I am not asserting that Ruby/Rails will be the only framework; I generally don't believe there needs to be a single framework or in similar absolutes. (For more on this, see my post "Framework Wars: Now all Restaurants are Taco Bell") The following sentence in the post captures the scope of my position:

I think Ruby/Rails can and will replace Java as the language and platform of choice for software development in the enterprise and will similarly establish itself as the premier option for Web 2.0, cementing the bridge between both markets.

Java has the largest market share, estimated between 20% and 30%, depending on your source. (One example, though there are others, can be found in the following article "Programming Language Trends." ) Basically, I think Rails will have the largest market share; as Java is currently the default option for software projects (especially in enterprise), I think Ruby/Rails will be the new default. But as with Java, other frameworks will still thrive and will be more appropriate in various cases. I think this shift will take place over the next two to five years.

There are three critical questions that need to be addressed:

• Is Java's position vulnerable?
• Is Rails technically viable?
• Why Rails, as opposed to another framework?

Java Vulnerability

The majority of my previous post on this subject addressed Java vulnerability; I think PHP was a disruptive innovation that changed the economics of software development. It is hard to justify a software project as requiring $10 million, more than 20 developers and a few years when a similar application was just created by two developers in six months.

PHP delivered the first blow that has made Java vulnerable, as stakeholders are increasing pressure and questioning of the costs of development. However, Java is general purpose langauge and there is a considerable investment in existing applications and infrastructure. While vulnerable, a successor needs to have similar flexibility.

Rails Viability

Rails is not without its problems, as I noted in the previous post:

There is much work to be done on Rails though. There are scalability issues and integration patterns are immature (on average, at least).

Scalability is the most frequently cited criticism of Rails. (I will reference the two related topics of scalability and performance simply as scalability.) It should be noted that for enterprise, which is the primary target audience regarding the claims in this post, most applications do not have more than a few thousand users and scalability is not much of an issue. However, scalability for a popular consumer web application and an internal IT application is very different. I am not trying to simply dismiss the scalability questions, but I think it is only one factor and a broad set of issues affects technology selections.

Twitter is probably the largest Rails application and there has been much discussion of Twitter's scaling challenges, though the Twitter team continues to improve the situation. Similarly, Facebook is hailed as an example of PHP scaling. While there is no Rails app (to my knowledge), which has scaled to Facebook traffic, Facebook and Twitter are not common scenarios. In these cases, the elected platform will only help or hinder to a degree; the decisions of its developers and how they use their technology options will have the overwhelming impact.

Rails scales horizontally, similarly to PHP, though perhaps not as efficiently in its use of hardware. That said, I think Rails is commonly criticized for scalability problems because it is unfortunately easy to make naive decisions, which still follow Rails conventions, but cause scale problems at low user or page volume. Is this a fundamental failing of Rails? Yes and no. On one hand, you can make decisions with any framework that will cause scalability problems early. However, part of the promise of Rails is that if you follow the conventions, you will be okay.

Scalability is not quite the black, unknown art that it used to be. Most of the patterns and approaches to achieve high scalability are well understood. Java had significant scalability and performance problems in its youth that were addressed. Today, some massively scaled applications are written with Java. Currently, there are Ruby and Rails initiatives that are working on improving performance and scalability, from Rubinius to various ActiveRecord improvements. I expect to see major Rails scalability improvements in the coming year. As an example, the Facebook application Friends for Sale is a Rails app with 300 million views a month.

Why Rails?

Assuming Java is vulnerable and technical viability isn't an obstacle, why Rails and not another framework? I think there are two other commonly cited alternatives: PHP and Pyhon/Django.

As I noted earlier, PHP is responsible, in my opinion, for first exposing Java's vulnerability to be replaced at the market share leader. However, I think it is hard to use PHP for general purposes beyond web applications and this inhibits its adoption in enterprise. For example, I can't imagine a socket-based message queue in PHP.

Another challenge for PHP, in my opinion, is that sustainable development is not as easily achieved as it is with Ruby. Automated testing is more flexible in Ruby/Rails and I think the abstraction/plugin architecture of Rails leads to more maintainable applications. (I know of a PHP application, whose developer is quite talented and decided to port from PHP to Rails. The Rails version had only 9% lines of code of the PHP version. While it can be dangerous to draw conclusions based solely on LOC, an application that is 9% the size of the original is easier to maintain and is more flexible.) While such design patterns are possible in PHP, I don't think they are employed in the average case and I think the average case influences market adoption.

Python and Django are commonly compared to Ruby and Rails. A simple google search of "rails vs. django" yields numerous articles. Ignoring zealot rants on both sides, I think most balanced discussions conclude both platforms can enable productive development teams and the creation of compelling applications. I don't think technical comparisons inform why Rails has the edge in gaining market share, but market trends themselves.

Consider the following data that I collected by searching on two popular job sites:

From Monster: Rails - 267 jobs, Django - 143 jobs
From Hot Jobs: Rails - 25 jobs, Django - 8 jobs

I offer these data examples only to convey that I think more developers/stakeholders are taking the Rails plunge than Django. As Pivotal and others have experienced, there are multiples to be gained in productivity gains. I am not claiming Django can't offer similar productivity gains, but I think it would have to offer even multiples over Rails to get significant numbers of stakeholders or developers to shift from Java to Ruby and then to Django. I haven't heard anyone claim Django offers productivity multiples over Rails.

Whether you believe the current Rails attention is based on merit or hype, as more and more organizations adopt Ruby/Rails, a synergistic, self-sustaining cycle takes hold and this is the primary consideration in my opinion. As referenced in my last post, Geoffrey Moore, in "Crossing the Chasm", discusses the adoption curve of technology. He notes that there is a gap in the adoption curve between a relatively small market of early adopters and the huge mass market. Crossing this "chasm" depends on keeping up with market demand and addressing any issues that hinder adoption. This is can be daunting for any organization, but Rails can leverage a strong and motivated community. Rather than a single organization with a few developers trying to bridge any gaps, there are many developers in multiple organizations (and independents) actively working to improve Rails. A few examples (that are also already achieving good results) include Engine Yard, Rubinius, jRuby, and Glassfish.

I close with the short version of my argument:

Ruby on Rails will replace Java as the programming language and platform with dominant market share. Java is vulnerable because alternatives such as PHP have proven viable for application development with dramatically lower costs. While Rails has its shortcomings, concerns such as scalability continue to improve; Rails is not unlike other early-technologies in this regard (consider Java in 1996-98). While other platforms may offer similar productivity benefits to Rails, such as Django, Ruby/Rails is growing in popularity and adoption. This growth can lead to positive, self-sustaining feedback cycle as each phase of Rails adoption improves Rails and encourages more Rails adoption.

Enterprise's interest and adoption of Web 2.0 technologies grows each day. Much has been and is being written on this trend; simply google "web 2.0 enterprise" and you will have lots to read. My interest is the significance and impact of this trend.

I think enterprise systems have historically worshipped data: ERP, CRM, knowledge management, and data warehousing are applications that capture, mine and organize data. While of course such information is important, data and the "system" tend to be the first class citizens at the expense of the interests of users (i.e. people).

By contrast, I think Web 2.0 applications are people-centric. Social networking has informed many new models of how to organize information and anchor it to people. The data exists to support the person, whereas the reverse feels true at times in enterprise. Furthermore, user experience and satisfaction are emphasized, if for no other reason than pragmatic market survival. Enterprise software rarely makes user satisfaction a primary goal.

I think enterprise software will evolve to reorient data modeling around people and focus on the quality of user experience. The legacy of being data-centric is based on the assumption that workers are more productive if provided better information. While I don't challenge that assumption, I think the implementation of said principle has presumed volume and completeness of information was the key. I think Web 2.0 has shown that data accessibility, which is driven by data structure and usability, is more important.

Application integration has been challenging in enterprise. At times it was just expensive and in other cases simply didn't work. Technologies like CORBA or DCOM and the more recent SOA/ESB/SOAP approach, while ranging in adoption, haven't delivered great results, in my opinion. But most IT shops have tried to implement these standards nevertheless.

Mashups have demonstrated application integration can be relatively cheap and simple. Where numerous enterprise integration have spent tens of millions of dollars for mediocre results, it is fairly common place for Web 2.0 applications to share data, expose API's and leverage other applications based on modest effort. REST, JSON and simple XML/HTTP APIs are proving more effective and attractive than the presumed standards of SOAP in enterprise.

Integration has always been a pain point in enterprise and I think Web 2.0's approach can provide some insight for tactics that make it more economically and technically viable.

Many enterprise IT groups and ISV's are already looking to exploit and borrow Web 2.0 technologies and experience. While I think this will result in lower development costs, better applications and probably higher productivity, I don't think the trend will simply consist of enterprise visiting the land of Web 2.0 and bringing back trinkets from its travels.

I think the line between consumer Web 2.0 and enterprise will blur and fade, though not completely. Many of the same people who are users of enterprise software at work, are users of Web 2.0 at home. And they already use the same applications in both arenas; Google Maps and Wikipedia are just two examples of such applications.

Many sales groups already use LinkedIn to generate and pursue leads. (The salesforce.com AppExchange has applications to integrate with LinkedIn.) Google Apps is frequently used by office workgroups to collaborate on documents instead of using Microsoft Office.

Ten years ago email was typically a discrete application; at the millennium "Send As Attachment" functionality was commonplace in applications. Web 2.0 technologies such as RSS feeds are already being integrated into many applications and I imagine the ubiquity of other Web 2.0 elements will continue. I think we are quickly approaching a world where the tools used at work and at play will frequently be the same.

I believe that Ruby on Rails hallmarks the next era in software development. But before I explain the scope and significance of my claim, a little background and history of software development is necessary.

The C programming language marked a new generation for software development. It was a high-level language, compared to assembly, which made software development a viable investment on an unprecedented scale at the time. Unix was developed with C and it created new opportunities for computing; new markets and potential beneficiaries of technology were born with the advent of Unix. (While there were other languages at the time that also opened new markets for computing, such as Pascal, I am using C as the "poster child" for this era.)

But application development was very expensive with C. There were many bugs, sustainable development was hard and overall the costs made it difficult to realize a return on technology investments. (Unix, because of the scale of its adoption, made the return worth the pains and costs.) Many tried to develop various applications and found it daunting and not economically viable with C.

Java brought on the next revolution. As the next generation, higher level language, Java caused a new market to explode: enterprise development. Before Java, IT development was fairly limited to few companies with very large budgets. While there have been many incredibly expensive Java projects, the number of participants in computing erupted; even small organizations with a few employees invested in IT projects.

While Java development had a lower cost profile compared to C, it still was high. This culminated in the mid to late 1990's with the Standish Group's Chaos Report(first published in 1995). This landmark report noted that 5/6 software projects fail. It also described a variety of other disturbing statistics. In short, many organizations were investing in software and most of those investments failed miserably.

The rise in outsourcing in the late 1990's and early 2000 was in response to the economic environment of software depicted by the Chaos Report. I think most of the industry was throwing up their hands -- "If we can't figure out how to build software, let's make projects cost less and make a portfolio management play."

But outsourcing proved not to be a panacea. In a somewhat parallel track from enterprise, and in the aftermath of the Web 1.0 bubble, a new interest in consumer oriented applications took hold early this decade. PHP marked another new era in software development.

The LAMP stack (Linux, Apache, MySql, PHP) offered a new paradigm for development. Thousands of small, focused web-based applications sprang up. Two developers in a few months were accomplishing what twenty developers couldn't achieve in a year. Pragmatism drove ideas and it was being demonstrated that small teams could be incredibly productive in short time frames. The economics of development changed once again.

But PHP has problems. First, it is limited to website development. This makes it hard to adopt for general enterprise software, as integration can't be effectively done with PHP. Second, it has provided a great option for first version websites, but at least in my opinion, PHP does not provide for a robust language/environment for sustainable software development; this is a must for enterprise.

The breadth and volume of topics to which software is being applied is growing. This creates tremendous pressure for the economics of software to be manageable. Furthermore, the line between enterprise software and consumer-oriented web 2.0 is getting more and more blurry. I think the market needs and demands a technology option that can be used by both markets and is economically viable.

This brings us to Ruby on Rails. Ruby is an elegant and mature programming language. Object-oriented geeks tend to love it and feel empowered to create software with it. It is also a disruptive innovation (as described by Clayton Christensen) that changes the economics of software; Rails brought forth a new vision: opinionated, convention based platforms can dramatically reduce the cost of development. I think Ruby/Rails can and will replace Java as the language and platform of choice for software development in the enterprise and will similarly establish itself as the premier option for Web 2.0, cementing the bridge between both markets.

There is much work to be done on Rails though. There are scalability issues and integration patterns are immature (on average, at least). But compare Ruby/Rails to where Java was in the 1990s and I think Ruby/Rails is much further ahead in its technology and adoption lifecycle.

And what about the alternatives like Python and Django? There is some debate over this question and that can be a series of posts by itself. For the moment, I will address this with the following observation: at Pivotal we have many developers who know Ruby and Java and the same developers are several times more productive in Ruby. In this comparison, my money is more on Ruby compared to Python than Rails compared to Django; I can't see how we can be as productive with Python as we are with Ruby.

The momentum of Rails is not be underestimated. Geoffrey Moore, in "Crossing the Chasm", describes how markets need, elect and will support a market leader. The need for manageable software development costs, both in terms of upfront and sustained development, create tremendous pressure, that combined with the current momentum of Rails, will drive forward the adoption and development of a rich Ruby/Rails ecosystem. As Rails becomes more and more established, its position is harder and harder to derail. (Sorry, I couldn't resist the pun.) Think about Apple's iPod: it isn't enough to offer a better mp3 player as the market has invested in an iPod ecosystem of speakers, docks, cases, etc. Similarly, Rail's position only continues to be secured.

In short, as is the case with many things, economics will dictate the needs of software and will establish the supremacy of Ruby and Rails.

Pivotal Labs, in collaboration with VentureArchetypes (www.venturearchetypes.com), hosted an entrepreneur panel discussion on October 23, 2007.

(For the impatient, you can jump to the end for podcast links of the event.)

You've Launched, Now What?

We had four fantastic panelists:

• Chris Law is co-founder and VP Product of Aggregate Knowledge, a leader in the new field of "collective discovery" that creates automated behavior recommendations for websites. Since starting up in 2006, AK has raised $25m from Kleiner Perkins, DAG, and First Round Capital.
• Jeremy Verba is CEO of Piczo, a leading online site for teenagers that has grown virally to 10 million unique visitors generating 2 billion views a month. The company has raised $18m over three rounds from Sierra, Catamount, Mangrove, and USVP.
• Prashant Shah is Managing Director at Hummer Winblad, the first venture capital fund to invest exclusively in software companies. HW has just closed a new fund with $225m of new "dry powder" to invest. At HW, Prashant is seeking investments on the business side of the web/software market.
• Mark Fernandes is Managing Director at Sierra Ventures, which invests broadly across communications, software, and Internet related companies. Mark's focus at Sierra is on consumer Internet and infrastructure software.

The audience were primarily entrepreneurs and a few investors. A few comments we received include:

Thanks

We'd like to thank our panelists; they had great insights and were incredibly down-to-earth. We'd also like to thank our audience members. Besides their great questions, their participation in the pre/post panel discussions and mingling made it a wonderful night.

What's Next?

We are planning to host more of these events. We'd love to hear your feedback or comments.

Podcast and Photos

The evening's podcast is available in two parts: the panel discussion and the audience Q&A.

• Panel Discussion
• Audience Question and Answer: Note: Due to microphone proximity, some audience questions were inaudible. The audio for these brief sections was omitted for the sake of continuity. In most cases, our moderator repeated these questions or hopefully the response will provide enough context for the original question.
• Photos on Flickr

Software development is full of framework wars: passionate debates about technology choices that unfortunately degenerate into winning and losing, rather than understanding benefits, risks, and suitability for contexts.

I have unfortunately found myself embroiled in more than one such battle and haven't always been a balanced contributor. What amazes me though is the common drive towards absolute resolution, the quest to find the "right answer."

There is a scene in the movie Demolition Man that I think offers a good perspective on these issues. At one point, Sylvester Stallone's character is confused by an invitation to dine at Taco Bell. Sandra Bullock's character notes that there were restaurant wars, and "Now all restaurants are Taco Bell."

Nothing against Taco Bell specifically, but do you want to live in a world where the only restaurant option is Taco Bell?

A common corollary argument in such framework debates is that the industry, or some relevant subset community, is embracing and standardizing on some particular platform, and as such, this is offered as justification for following suit.

While this line of thought sometimes has merits, its important to consider the Taco Bell scenario: if all restaurants are Taco Bell, sometimes its preferable to make dinner at home.

Do you laugh everyday at your job? If not, why? I think too many people become complacent at their job and accept being bored, frustrated or just generally not happy.

Laughter is not the only benchmark though. I think you should also ask, "Did I learn something today?".

I am not advocating resignation on the first laugh-free day nor should the work environment become a comedy club or a playroom. But I want employees who take their own professional development and satisfaction seriously and demand a "yes" to both questions. It is a character marker of the employee and one of the organization.

I've worked in situations where I could answer yes in some cases and no in others. While obvious, I can't overstate the difference for my own productivity and general mental health when I could answer yes. And don't assume you have to be lucky to either structure such an organization (for the employer) or find one (for the employee). The companies are out there and if you can't change your organization to accommodate such satisfaction, then what can your organization do?

These two simple questions are a good litmus test assessing your current employment, or for the employer, the quality of your work environment. I suggest asking the question every day over the next week and then review your answers.

So, did you laugh today? What did you learn today?

Congratulations to Bring Light! They recently launched and we want to thank Drew of Bring Light, Ruby Red Labs and all the Pivots who worked hard to make it a successful launch.

Bring Light connects charities with the communities that support them. Effective philanthropy really benefits from collective action and Bring Light hopes to leverage the Internet to match the passion, commitment and interests of individuals with worthwhile causes.

Pivotal Labs has been privileged to help Bring Light make a difference.

Alex adds:

And kudos on a killer article in the SJ Mercury News! (Cute picture too!)

In an earlier post, I discussed high concept and how it can focus an entrepeneur. High concepts can be utilized in various scopes, from large scale strategy to the operational goals of individual business units. And they don't have to be clever mashups of existing ideas.

In the early 1960's, President John Kennedy called on the United States to put a man on the moon by the end of the decade. Aside from any political implications of this, this dream rallied the development and funding of science programs, education and technical innovation. Many think this established the United States' technical foundation and had numerous benefits for the country. It also focussed on the dream; would asking for $9 billion for space exploration have been as effective? This high concept was simple, compelling and served as a simple litmus test for aligning many efforts.

Many software engineering divisions are plagued by operational problems that result in quality and maintenance problems. Their group leader could put forth the following goal: "We should be able to push an application to production within 8 hours from source code check-in." Automated testing, continuous integration and integrating QA upstream are process mechanisms that could all contribute to this goal. Many may support these ideas, some will not and others may suggest alternatives. But the high concept can help separate the goal from implementation, purpose from politics.

High concept is not a panacea; some ideas are non-starters. (I wouldn't go see a movie based on "Signorney Weaver, Kevin Bacon and King Kong on the moon" nor do I think "YouTube on wristwatches" should be funded.) But a simple compelling vision can be a powerful tool to align the efforts of your organization, rally enthusiasm and leverage collective brainpower.

Many software developers are overly sensitive to performance and spend a lot of time and effort considering the performance of their code design. While I understand their concerns and that they don't want to be negligent, their efforts are generally inefficient and sometimes misguided.

Performance bottlenecks are commonly not where you would have expected them to be. A lot of upfront effort can be wasted on poor assumptions and planning.

Many respond to this argument by doing even more preemptive optimization design and planning, so as to correctly identify the bottleneck. This is rarely as efficient as simply implementing the original feature, profiling it, and then tune or address the actual bottlenecks.

There are certain contexts where some preemptive optimization is appropriate, such as network drivers or low-level protocol implementations. But in the majority of cases, there is no need. Overall, the balance of concern is wrong, in my opinion. Some advance thought for performance, so long as it doesn't disrupt your progress, probably won't impact productivity much.

Unfortunately, I've been in many conversations where someone played the "performance card" and derailed any discussion or progress while that tangent had to be addressed. This is an example of a larger, more troubling problem in software development.

There are many areas of presumed conventional wisdom than few are willing to challenge. This combined with the typical myopia most developers experience, whereas they see the problem they want to solve as opposed to the one that is there, is one of the main risks to success for software projects. Also, if the conventional wisdom and status quo was so correct in software, why are there so many failed projects, blown schedules and budgets, and quality and sustainability problems in the software industry?