Eclipse Will Not Be the AppWiki IDE

I have just browsed through the presentations in the recent EclipseCon 2005. I am ever more convinced this is not the way to go in general for Internet applications. The same reasons apply. Eclipse will be limited to applications for the techies. For us, I think our application will be layered like:

• At the bottom are the Java components exposed as jar files, configuration files (properties or XML).
• On top of which are views exposed in Eclipse to these components so that you can easily develop the components, configure them, change their aspects, compose more complex components, etc.
• On top of which is really the user-facing IDE: the AppWiki environment. Our users don't need to know Eclipse. They go to this one site to build, compose, integrate, test, deploy, run and potentially collect their revenue. The dev, stage, prod environments are one and the same (with some isolation). The IDE and the application are one and the same, too.
  

Tim's Business Model for Open Source

Tim O'Reiley gave a great presentation at EclipseCon 2005. He argued for business models for an industry shaped by open source. Here are the main points:

Architect your software in such a way that it can be used easily as a component of a larger system. Use a license that does not hinder such a combination. Keep your software modular, and make certain that you document all of the interfaces.

This fits very well with REST. Or make your service usable by a user (human) or by another service (code).

Release early and release often. Set up mechanisms for users to submit bugs and patches. Promote your most active users into roles of greater responsibility.

We have seen Atlassian do this, which has been pretty successful.

Focus your development efforts on speed of testing, assembly, and integration so that your users can always have the best components that the marketplace has to offer.

Yes, integration and composition!

Do not package up new features into monolithic releases, but instead add them on a regular basis as part of the normal user experience. Engage your users as real-time testers, and instrument the service so that you know how people use the new features.

Yes, the perpetual beta.

Use Linux, Apache, and other open source components running on commodity PC hardware as the basis for
any internet service. Arrange these components in fault-tolerant arrays, with
management tools that minimize the number of required sysadmins.

Don't forget to use hosting too. These days the hardware cost for starting up is quite low.

Don’t restrict your “architecture of participation” to software development. Involve your users both implicitly and explicitly in adding value to your application.

Yes, let users help themselves and add value to the services.

Use the power of the computer to monetize niches that formerly were too small to be commercial.

There is gold in the Long Tail.

Owning a unique, hard-torecreate source of data may lead to an Intelstyle single-source competitive advantage.

This is a significant point to ponder on. It is what evdb is trying to do, owning the events data and service.

And other fine points.

WWC: World-Wide Composition

Today evdb went beta. It's very buggy right now. But there is already a lot of buzz behind it. It got me thinking again. Apparently it's just another calendar site with some small but significant improvements over things like when.com (anybody remembers that?):

• RSS: A simple way to publish and aggregate events and their updates.
• Tagging: A simple way for organization and taxonomy.
  
• A REST API: This is the most significant. That's why Jon Udell is talking about from open source to open service to open information.

We will soon see the advent of World-Wide Composition made possible by REST. In the previous post I talked about the 4 parts of a page, content, layout, style and behavior. Also remember the active URI scheme (basically a way to nest URIs) used in NetKernel. Any given page on the web can be built by composing from 4 different URLs for the 4 parts.

http://pageserver?content@http://...html+
laytout@http://....css+style@http://...css+behavior@http://...js

Call it service composition or what not, it's composition on the scale of the whole web. What does it have to do with evdb? I envision in the not so distant future, there will be one best of breed player in each application category just like evdb for calendaring. When anyone wants to build a new application, s/he just needs to compose it from combining the pieces from these various services: calendar from evdb, search from Google, shopping from Amazon, payment from PayPal, etc. This may even be possible with one (long) URL.

Now scale down the individual pieces. Is this another angle of the AppWiki concept? I think so.

Separation of Content and Others

A recent project made me think seriously about separating content from layout, style and behavior. A page should be divided into:

• Content: the text
• Layout: columns, banners, menus and their positioning, etc.
  
• Style: font, size, color, etc.
• Behaivor: anything involving JavaScript

Content is updated most often by people who don't have need to have any knowledge of HTML, design or JavaScript. Layout and Style are usually done by web designers who are good at CSS. Behavior is usually done by a real techie. The seperation makes it easy to evolve the 4 parts independently.

Other discussion of the same topic:

• Separation of content and behavior
• Separation: The Web Designer's Dilemma
  

Darcs: Distributed Version Control

Just discovered Darcs, a distributed/decentralized version control system. It sounds very interesting. Here is a comparison of it with Subversion, an enhanced CVS that most people are moving towards:

Every working copy of the repository is a fully functional repository. Several (indeed most) of the advantages of darcs over subversion fall out of this. If your "server" gets messed up for whatever reason, your users can still push/pull/e-mail patches amongst themselves. This also means that fixing your server can be as easy as running "darcs get" from one of the working copies, and then a "darcs push" to make sure everyone's patches are in the new central repository. It is also trivial to mirror your central repository in several places. To really be out of commission.

There are certainly advantages of Subversion over Darcs. Why is this interesting? Because we are looking for a solution to support our application that works seamlessly when online (when central server is available) or offline (when not). If we don't use it directly, we can probably learn some lessons from Darcs.

Google OS

Here is another intriguing piece which puts Google and AJAX together to project a future of thin client replacement of Microsoft software. It makes perfect sense.

I thought we were on a collision course to Microsoft. Now this post suggests we are on the same collision course to Google. Or are we really? In one sense, yes. It's my ultimate vision that Ajax type of applications will replace (mostly) Office type of software. On the other hand, the thick client is probably not going away. So our vision of seamless local/remote integration should play well to both assumptions: 1) the client is still going to be powerful and sophisticated, probably with a multi-core Pentium M processor, oodles of memory and storage, a 2-week (fuel cell) battery life on one charge, etc.; 2) AJAX (rich thin client) applications will be the norm. Also, Google may be in the business of building AJAX applications and may not be in the business of making it easy to build such applications for millions (the software long tail). But we are.

Paul Graham: Great Hackers

Still reading. But this is right on:

Companies like Cisco are proud that everyone there has a cubicle, even the CEO. But they're not so advanced as they think; obviously they still view office space as a badge of rank. Note too that Cisco is famous for doing very little product development in house. They get new technology by buying the startups that created it-- where presumably the hackers did have somewhere quiet to work.

Giving hackers a great environment to work is the cheapest investment you can have for a great software company. The first thing I didn't like when arriving at Cisco was the small cubicle size, compared to the AOL size that was already reduced from the Netscape size.

More comments to follow.

Paul Graham: How to Start a Startup

Paul Graham (of Viaweb (which was acquired by Yahoo! and became Yahoo! Store) fame) has a very easy-to-read essay on how to start a startup. His three key ingredients of a successful startup are:

1. Good people.
2. Good product.
3. Good control on spending.

For point 1 I quote:

What do I mean by good people? One of the best tricks I learned during our startup was a rule for deciding who to hire. Could you describe the person as an animal? It might be hard to translate that into another language, but I think everyone in the US knows what it means. It means someone who takes their work a little too seriously; someone who does what they do so well that they pass right through professional and cross over into obsessive.

You know what, Emad and I have been called obsessive about Cornerstone Framework before at Cisco. This is a good sign :). Though we learned showing obsession about our own work may not be the best to do in all situations.

Will add more comments when I finish reading it.