A new version of Tweed is available! (v.0.9.7)

Bug Fixes

• Tapping notification banner/dashboard does not load app
• Show loading spinner on refresh
• User Profile tap target was extending past photo
• several memory leaks

Features

• Shorten Urls button in compose tweet scene (urls over 30 char)
• Auto-refresh of active card (3 minutes for refresh, displays banner when there are new tweets)
• Auto-refresh will show New Tweets marker to separate newly loaded tweets from existing tweets in timeline
• Manual refresh (via button) preserves timeline and loads new tweets above existing tweets
• Conversations - icon indicates a message is "in reply to" and popup menu action shows thread
• Home timeline is checked in notifications
• Popup menu action to add marker to tweet timeline -- useful for keep track of read/unread tweets.
• Show client/source of tweets

Markers

You can place a marker (will appear above tweet) on any timeline -- they are saved and reloaded with the timeline. If you mark another tweet, the marker will move. To remove the marker completely, tap unmark from the tweet menu for the tweet with the marker.

There is a bug we just discovered (after we gave Palm the release for review): if you have a marker on a timeline and then tap "Load More" the marker position is not displayed correctly. It is stored correctly, so if you leave the timeline and return to it, it is then displayed correctly. (We will fix this soon -- we didn't want to block the other features since we discovered this it morning.)

Photos

So, we know photo upload/integration is missing.

Here's the scoop on photo integration. There isn't direct support for photo upload in the Palm Mojo SDK, yet.

It is definitely coming, though given the incredible demand for photo integration in Tweed (everyone wants it yesterday, or more precisely, at launch), we realize it won't be ready soon enough.

So, we are working with Palm on alternatives and options that will deliver the ability to tweet photos from Tweed.

We understand it is frustrating, but please know it is a HUGE priority for us and we are actively working on it.

We hope to have something in the coming weeks.

Let us know your feedback either @tweed on Twitter, tweed-support@pivotallabs.com or http://tinyurl.com/satisfaction-tweed

We are happy to announce Tweed, a twitter client for the Palm® Pre™ and Palm webOS™

Check out http://tweed.pivotallabs.com for info, screenshots and a video.

Follow us on Twitter @tweed

Today's the big day: the Palm® Pre™ has launched.

We've been happy to be partner with Palm and we've been working very hard towards this day.

We are happy to have several applications in the App Catalog:

• AP Mobile
• mobile by Citysearch
• LikeMe
• and our own Tweed, a Twitter client

When the Mojo™ SDK is publicly available, we will be releasing various open-source tools to aid development:

• Jasmine: BDD testing framework
• Pockets: various libraries and utilities for Palm webOS development

Ian McFarland and I did an interview with John Cox of Network World for his recent article on Palm's webOS.

You can read the article at:

http://www.networkworld.com/news/2009/041709-palm-pre-webos-lives-up-to-claims.html

Ian McFarland and I spoke to Priya Ganapati of Wired this morning about the Palm Pre, webOS and Mojo Application Framework. It was a follow-on interview to Mitch Allen's Webcast this morning. (Check http://developer.palm.com for the webcast; it will be posted soon.)

Check out the Wired blog post at:

http://blog.wired.com/gadgets/2009/02/palm-energizes.html

Palm shook up the mobile world at CES 2009 when they announced the Palm® Prē™ and webOS™. And while webOS™ defines new possibilities for the mobile experience, it is the possibilities for the developer that sold us and led us to pursue a partnership with Palm.

You can create a great application with many platforms, but it can be far from easy for the developer; at times I swear I hear circus music as I jump through an endless array of hoops, in an effort to build my application.

The Mojo Application Framework is built for the developer, just as a BMW is built for the driver. (Not that the passengers get a bad deal either.) Most mobile platforms frustrate me as they seem like the state of the art in desktop development circa the 1990's. With Mojo, the development experience is more like using Rails or Django and less like using C++.

Pivotal plans to bring our practices to developing with the Mojo framework, such as Continuous Integration, and Test/Behavior Driven Development. Expect to see a variety of open source tools from us to support these efforts.

Gizmodo's Brian Lam recently wrote, "Palm dropped their new smartphone and their new operating system on us, and it is maybe the most interesting phone I have seen this decade."[1] Though the Palm Pre definitely evokes intense gadget lust, webOS and the Mojo Application Framework combine as one of the most interesting development platforms that I have seen in some time.

[1] http://i.gizmodo.com/5127040/catching-up-dear-ces-diary-day-one

The Tracker Story...

Pivotal Labs is a consulting shop and not a product company, so it might seem odd for us to release a product like Tracker. We didn't build Tracker for the sake of building a product; we needed it.

State of the art: index cards

We've been doing agile software development before terms like "Agile" and "XP" existed. Over the years we've made numerous attempts to use the variety of software project management applications available, from Microsoft Project to the more current agile-specific products.

We kept returning to index cards, sometimes augmented with a patchwork of wikis and spreadsheets. We followed the agile planning tools out there, but each attempt to adopt an one resulted in frustration. Configuration and data entry were a constant expense. User interfaces were clunky and had too much back and forth navigation. The workflows were inefficient and the overhead was high. (We kept hearing circus music in our heads, with all the hoops we were jumping through.) The usage cost never seemed sustainable. It always felt like we were working for the product, instead of it working for us.

But we needed something...

As our business grew, so did our frustration; index cards were far from ideal but the alternatives were worse. And at the same time, we were just starting to look at a promising new technology, Ruby on Rails. So we decided to build our own tool.

We started working on Tracker in late 2006. Its beginnings were very humble. All we needed was to have a backlog and be able to easily prioritize. We created simple story editing and built drag-and-drop prioritization and we were ready to start the switch from index cards. (These simple features gave us parity with index cards, with the bonus of having the backlog online.)

Who gets excited by project management software?

We started using Tracker on all of our client projects. We continually improved and tweaked the application, integrating our experience and feedback. And we started to find that it really transformed both the transparency and the flow of development.

Tracker quickly developed a following among client developers who had used it when working with us, too. We would routinely received requests for accounts: "I used Tracker at my last job. Can I have an account to use in my new one?"

We would always accommodate these word-of-mouth, friends and family type requests. Entire client organizations, beyond our projects, started using Tracker. The interest continued to grow and with much greater enthusiasm. We kept getting emails saying things like, "Please let me pay for Tracker; I can't live without it."

So we decided to make Tracker publicly available. We launched the public beta at RailsConf 2008. Over 10% of the attendees signed up that week.

Why Tracker is Special

We had three key insights at the outset that made Tracker work:

1. the user interface needed to be simple.
2. The project status and backlog needed to be easily (always) available.
3. You shouldn't have to constantly plan iterations.

The first point is simply about good UI design, but it's amazing how many tools out there get this wrong.

The last point is more subtle. In agile processes, particularly XP, there is a concept called velocity. The basic idea is that you assign a point cost to stories and the sum of the point costs of completed stories in a given iteration is the velocity. You then use the velocity to project how much you will be able to get done in each future iteration. As teams start to gel, they exhibit a strong central tendency to get a consistent amount done each week, and this velocity becomes extremely predictive and reliable.

Traditionally, after completing an iteration, you would re-plan each subsequent iteration, adjusting for the actual rate of progress. This can also be onerous, but it's critical, as it is allows you to project when each milestone will be reached. The feedback needs to be taken into account so better-informed decisions can be made.

The solution is the emergent iteration. Pivotal Tracker automatically (and in real-time) tracks story completions, iterations and velocity and will dynamically adjust iteration backlogs based on actual progress; Tracker does the grunt work and your project schedule is always up-to-date.

The Tracker Philosophy

Tracker embraces simplicity. It should make managing projects easy, rather than make its users slaves to maintaining the plan. It should give every user of the system more information back than they put in.

Tracker doesn't have a huge list of features, because it tries to stay true to its core purpose. (Remember, it exists partly because of our frustration with the bloated alternatives.)

At times, Tracker appears opinionated as it can place strict limits on how you manage your project. But this is a consequence of its focus and the interdependence of features; the sum of Tracker is far greater than its parts.

While we don't always get it right, we try to make sure each additional feature or product change adds a lot of value and makes users' work easier.

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.