Affero General Public License - AGPL

Jul 27, 2008 – 10:58 by Ryan

There are a lot of open source licenses available. Based on what you want to accomplish, choosing the correct license is important. What people don’t commonly understand is the difference between open source and the freedom to do whatever you want with the source. There has been a bit of controversy surrounding the Affero General Public License so we decided to do a bit of research on the license.

In a nutshell, the core concept behind AGPL is that if your applications links to an AGPL licensed library and you make your product/service available via a network service, then your application must also be open source.

We reviewed the following pages in our research:

• GPLv3 and Software as a Service
• GNU Affero Genenal Public License
• Affero General Public License (Wikipedia)
• Network Service (Wikipedia)
• Application Service Provider (Wikipedia)
• GNU General Public License (Wikipedia)
• Google’s festering problem with the AGPL
• The AGPL in Simple Words

Image courtesy of the Free Software Foundation.

Sphere: Related Content

Posted in Research | No Comments »

Is Google Doing Something Evil?

Jun 23, 2008 – 21:24 by Ryan

We have to preface this post by stating that we love Google Apps. We’ve been using Google Apps at Deft Labs for almost two years and have had a fantastic experience. It’s an excellent product for the price. Everyone pays $50 per user per year for a slew of business tools (a fantastic browser-based e-mail tool, group calendar, e-mail lists, browser-based office suite, etc.). This breaks down to ~$0.14 per day per user. Microsoft Office will run you ~$0.18 per day per user if you buy one new $260 license every four years. Additionally, if you stop using Google Apps after two years, you would have only spent ~$0.14 per user per day versus the ~$0.36 you would’ve paid for Microsoft Office. If you factor in the e-mail server hosting expense, you’re looking at a cost per user per day that is an order of magnitude higher when using Microsoft Office.

Productivity Gains

What’s difficult for most people is the switch to a purely web-based solution. For years, people have been using the same interface for their office tools. When you introduce a new tool you can expect to suffer an initial productivity setback. After your users have adjusted to the new tool, you should see a significant productivity gain. Google runs their highly successful business on the same tools.

Inbox Zero

One of the most important productivity gains we discovered with Google Apps is the concept of Inbox Zero. The basic premise of Inbox Zero is that you only have action items in your e-mail inbox. Everything else is archived or organized by a limited set of labels. One of the major setbacks of Outlook is search. There really is no comparison to the e-mail search capabilities of Google Apps. Even amongst thousands and thousands of e-mails, it’s easy to find the one you’re looking for. In Outlook, people tend to compensate for poor search capabilities by archiving their e-mail in (often) scores and scores of nested folders. The overhead associated with organizing and accessing data in this manner can often be overwhelming. SAI recently released a similar post describing the cost of compulsive e-mail monitoring.

What Evil?

Alright, now we have to justify our title :-) Recently, we went to renew our Google Apps account and when we were presented with the checkout screen we weren’t able to adjust the number of user accounts. This was on the confirmation page before the checkout (i.e., billing) page. Next, we thought about what e-commerce sites on the Internet don’t allow customers to modify the quantity of their order before checkout, and we couldn’t think of one. After clicking around for a minute or so we weren’t able to figure out how to change the quantity. Eventually, we sent a message to customer support and a day or so later they cheerfully responded with a link to a help page. After reading ten or so FAQs entries we found the section we needed to solve the problem.

photo credit: dreamerofm

Help Pages?

A not-so-radical theory in user interface design is that help pages are a list of failures. Sometimes they’re intentional but most of the time they document strange scenarios/functionality that isn’t intuitive to the majority of users. Looking at this issue, it’s obvious to us that modifying the quantity of your order should be apparent to everyone. The real question we had to think about is does Google not understand that modifying your order before checkout needs to be obvious or did they intentionally make it difficult in hopes that they would experience a rebate effect (i.e., if you require the customer to go out of their way then they probably won’t make the effort to do so, even if money is involved).

If you consider that Google has 92% of the web-based productivity market then you realize the amount of money that could be collected by making a quantity change difficult. One pleasant surprise is that they pushed our renewal date back a few days to allow us to compensate for the customer support interaction :-)

Sphere: Related Content

Posted in Reviews | No Comments »

Cloud Infrastructure Blueprint

May 28, 2008 – 22:38 by Ryan

As cloud platforms and services start to make their way to the market, we think it’s becoming obvious how the industry will play out. To understand the future, it’s important to look at the past.

Best of Breed

Stand alone providers who offer services provided by clouds are going to find it difficult to survive on their own. Currently, enterprises have way too many Internet service vendors. The situation is reminiscent of the software industry in 2000. For a long time enterprises found themselves taking a best-of-breed approach with regard to software vendor selection. This worked for a while, but eventually products mature, prices align and competitive differences dwindle.

A good example of this is the competition between J2EE container providers. For a few years, BEA provided a stronger J2EE container than IBM, JRun, JBoss, ATG, SilverStream and others. The competing products eventually matured and the industry was commoditized. This placed customers in an awkward position when justifying the expenses related to maintaining numerous software vendors. SilverStream went to Novell, BEA went to Oracle, JBoss went to Red Hat and JRun went to Adobe (by way of a sale to Macromedia).

The Stack

Eventually, the software “stack” was born. Software publishers started consolidating and now you can get just about everything you need from a single vendor. Of course some companies still take the best-of-breed approach in their vendor selection process, but when you make a lot of separate purchases you miss the economies of scale that a single large transaction can bring. Most software publishers offer sizable discounts on non-core products when you buy the complete stack.

In a nutshell, the same consolidation we witnessed in the software industry is about to hit the cloud/platform space.

Blueprint

The name of the game is efficiency and this can only be achieved through service consolidation. The following is a list of services/functionality we think are essential for cloud platforms providers:

• Storage – The ability to transparently increase your storage capabilities. This is going to be a tough nut to crack. If company A has a disk IO read requirement of 400 MBps, they may have issues with the current services available. Currently, cloud storage models are based on bytes transferred in and out of the cloud and the amount of storage available. Eventually, you’ll be able to pay extra for high throughput.

• Message Bus – The ability to reliably communicate between applications and distributed nodes using a common interface.

• Network Isolation – Most companies don’t believe in encrypting everything that hits the wire. This results in potential security issues for applications sitting on the same network. This may be a difficult problem for cloud vendors to solve (consider each of the nodes your app runs on may be on a separate subnet).

• Database – This is obvious, but what is not is the death of RDBS technology. It doesn’t make sense for companies to continue using this technology much longer. The costs associated with writing applications that require multiple programming languages are high. OO databases are starting to mature and the reduction in bookkeeping and development costs will drive people to this technology. Google, Amazon and others have already released OO database services. Google added a SQL interface to their OO database for legacy users/apps.

• Job Scheduling – Some applications need to run at scheduled times.

• Load Balancing – HTTP load balancing should be transparent.

• Resource Scheduling – Clouds need to provide consistent performance for all types of applications. For non-web based applications this means that they need to dedicate specific disk, memory and CPU resources. Additionally, the cloud must detect when an application needs additional resources and dynamically allocate those resources. This is easy for most standard HTTP applications but is a more difficult problem when looking at data processing/computational applications.

• Parallel/Grid Processing – Let’s say we need to analyze the HTTP logs we collected over the last year. This can be dispatched to a single machine but it would take forever to run. The ability to transparently process data in parallel is essential for the enterprise adoption of cloud platforms.

• Network Capacity – Some applications are optimized and can easily max out a 1 Gb network connection. Most cloud platforms use shared or virtualized resources. This can make it difficult to isolate network capacity. The release of 10 Gb networking technology (with 100Gb technology on the way) will drastically change the way applications are designed. Engineers will have significantly fewer restrictions when developing distributed systems. The primary focus with network capacity is on the LAN level. It’s assumed that the cloud platform has enough network capacity to handle their customer’s WAN requirements.

• Caching – This should be transparent for data store access. Users need the ability to create complex transient data structures that support distributed access.

• Advertising – Complete campaign management and fulfillment from a single vendor is essential. This includes email, text, banner, video, outdoor, IPTV, etc. The recent consolidation in the industry indicates that this is already underway.

• Web Analytics - Currently, there are a variety of stand alone companies who provide this service. We think these companies will be forced to sell/merge into the cloud platforms.

• CDN – Content delivery should be as simple and transparent as possible. Cloud platforms can transparently provide this service to their customers. Expect to see a lot of consolidation in this space over the next two years. The jewel in the industry is Panther Express ☺

• Email/Communication – Providing a single corporate UI to your employees is essential. Switching UIs results in a context switch and requires a brief period for the user to adjust to the alternate environment. Integrating web-based email access with the rest of software/services customers use to run their business will further increase the efficiency of their employees.

• Core Service APIs – Embedding new applications in a cloud needs to be fast and easy. Providing a common API/framework is critical. Imagine customer A uses service B provided by company X. Customer A already has an application management console provided by the cloud. They need to be able to configure service B using their existing admin tools. Pluggable admin tools should resemble Facebook’s development environment.

• Content Management - Companies need to be able to organize, publish and track their content. This needs to support all common media formats.

• DNS/Registrar – Nobody wants to think about the plumbing nor do they want to maintain multiple accounts to manage this functionality. Using DNS provided by a single ISP doesn’t make sense from a reliability standpoint. ISP networks and services are much too xenophobic. Cloud platforms need to be 100% fault tolerant. An outage no longer impacts one company, it impacts thousands.

• ERP Tools – All companies need a few basic tools no matter what industry they’re in (e.g., time tracking, contact lists/corporate directories, issue tracking, project management, documents, spreadsheets, billing, etc.).

• Monitoring/Alerts - Users need to be notified when conditions change. These attributes must be configurable.

• Service Billing – Clouds will provide great environments for mashup development. A clean billing and tracking solution is necessary so that services can be used without adding additional vendors to your list of partners.

Serious Clouds

Looking at the functionality list above, it’s obvious what Google, Amazon and others have been thinking about for a while.

A serious cloud platform will require a lot of custom development, but it’s still really early in the game. However, developing ALL of the systems/applications listed is a bit unrealistic. The best approach to creating a company that can compete with Google, IBM and Microsoft is to make a slew of acquisitions and integrate the applications. Most of the applications can continue to operate in relative backend silos with a completely integrated UI. The problem is that the return on investment will not be realized for some time. Enterprises are only beginning to look at moving to cloud platforms.

The golden age for platforms is not too far away and everyone and their brother will be looking for a pick and an axe.

Sphere: Related Content

Posted in Research | 4 Comments »

Google’s App Engine

Apr 23, 2008 – 20:46 by Ryan

Recently, we’ve been researching cloud computing so we decided to take a look at Google’s App Engine. We had hoped to write this earlier, but it was some time before we received access from Google to use App Engine :-) We’re excited to see cloud computing move forward but, as usual, we’re digging through the hype.

Data Access

Data access appears to be well implemented. Users have the option to create Google Query Language (GQL) or object-based queries. GQL is essentially a scaled down version of SQL (currently, GQL does not support join statements). The GQL extension is handy, but we expect most people to use the object query interfaces. We were pleasantly surprised when we saw that App Engine supports transactions.

Configuration

The configuration files for App Engine use YAML. While this is cool from a geeky staindpoint, XML would’ve been a better choice for the masses. Hopefully, Google will add a nice web UI down the road that removes the need to edit these ugly configuration files.

Local Development

We like the local development SDK, although it needs a lot of work. When we added an error to our “hello world” application, we were a bit frightened. The stack trace was scary and the first 90% of the message related to App Engine SDK (dev_appserver.py). After scrolling to the very bottom of the page, we found our problem:

Runtime Language

Google’s App Engine only supports Python right now. However, there is a placeholder in the primary configuration file (app.yaml) that keeps the window open for additional language support down the road. We’re not huge Python fans, but they should be able to easily integrate just about any language into the cloud in the future.

Pricing

Details about how much Google will charge for the service haven’t been released yet. The free account only allows 500 MB of storage so it seems as if their model is to make money on storage and CPU. Their bandwidth prices are pretty good… they offer 10GB in and out per day for free. We shall see how they do in their quiet entry into the CDN industry. Perhaps this will be the product that pushes Akamai to sue Google over patent 6,108,703.

Missing

The main component that is missing is an advanced UI. Google lets you perform some basic operations in their administration interface but it’s not even close to a robust environment. We expected a really slick browser-based editor from Google.

Also noticeably absent is the ability to run scheduled/cron jobs.

Vendor Lock-In

There is huge potential for vendor lock-in with App Engine. Google has open sourced all of the App Engine APIs, but if large tech companies don’t support/implement the platform then it’s little more than a defense to ward off lock-in criticism. AppDrop has already released an alpha implementation but without support from an IBM, Red Hat or Novell, it probably won’t gain much traction.

Competition

Google’s App Engine release formally kicks off the third chapter of the Internet’s evolution. There are already several startups working feverishly on cloud platforms and we expect lots of exciting news this summer about new companies trying to compete in the space. Of course there will be a lot of companies who washout, but the more people involved, the more innovation we’ll see.

Overall

If App Engine had been released by a startup, we would’ve given the product five stars. However, Google employs nearly 17,000 people and is worth roughly $174 billion. We’re happy that there are cloud platforms coming to market but expected more from Google.

We had the opportunity to play with the 10gen alpha, and so far, App Engine has some ground to cover to compete in the cloud space. Of course, having the most recognized brand in the world goes a long way ;-)

Sphere: Related Content

Posted in Research, Reviews | 2 Comments »

WordPress 2.5

Apr 16, 2008 – 22:51 by Ryan

We decided to take the plunge and upgrade to WordPress 2.5. Despite the many prompts to upgrade in the WordPress administration tool, we decided to wait a few weeks to before upgrading the application.

The process was easy but definitely required more typing than we expected. With over 15 plugins installed, we were surprised that everything but PhotoDropper worked after the upgrade.

The 2.5 admin tool is a pleasant surprise. The interface is fresh, clean and simple. There are some things we would change surrounding wide computer screens but, they’re minor inconveniences.

We moved from Blogger to WordPress about two months ago and so far we’re very happy with the product (and the price - free).

The three step upgrade process is available on the WordPress site. The entire upgrade process took about 20 minutes :-)

Update: PhotoDropper fixed their plugin and it works great.

Sphere: Related Content

Posted in Reviews | No Comments »

Gazing Into The Clouds

Apr 7, 2008 – 10:58 by Ryan

photo credit: Lodewijk van den Broek

Cloud computing is garnering a lot of attention lately. There are wild rumors and announcements about Google, Microsoft, IBM and others entering the space. Additionally, startups like 10gen and Heroku also appear to be working on the same problem.

Cloud computing will be a fast and drastic shift that will initially result in a lot of innovation on the Internet. Companies will no longer have to worry about plumbing when they decide to build web applications. Additionally, the barrier to entry to build sophisticated web applications will be significantly decreased.

In the next couple of years we expect to see a lot of cloud infrastructure deployed. Cloud platforms should be the fuel for the next tech boom. Of course we think it will be at least two years before cloud platforms are the norm (outside of startups).

Why?

Cloud computing is an essential evolution for the Internet. Power and space costs for server hosting are consistently increasing and in the not-so-distant future, it will be difficult to justify Internet infrastructure if it’s not fully utilized. For example, a server that is 10% utilized does not consume that much less energy than a server running at 100% utilization.

Multi-core CPU technology and virtualization are the primary drivers behind cloud computing. With the upcoming availability of eight- core chips, you’re now able to pack 16+ CPUs in a single 1U server. Virtualization isn’t really a new concept, but the ability to run inexpensive or free virtualization software on commodity hardware makes the technology accessible to more companies.

Development Costs

The costs to develop, deploy, scale and maintain applications should be drastically reduced when using cloud platforms. Communal services and libraries on a platform will reduce the amount of code that must be written to develop sophisticated applications.

Job Security

If you’re a system or network admin you may want to consider taking some classes. Cloud computing will drastically reduce the number of admin jobs because these positions will be outsourced to the cloud platforms. Engineers should also take note. The number of engineers needed to write applications will also be reduced. Most platforms will build sophisticated development environments that will allow engineers to use more visual tools to quickly assemble/extend applications.

It looks like 10gen is hiring if you’re in the market.

photo credit: L-plate big cheese

The Long Haul

The problem with cloud computing comes down the road. If there aren’t constant improvements/extensions to cloud platforms, there will be a lull in innovation. We predict that in a few years there will be several primary platform providers. Hopefully, the competition between these companies will be sufficient to force the platforms to innovate.

Vendor lock-in is potentially a huge problem. If you’re only able to run your applications on one platform, you’re essentially stuck with your cloud vendor. We think that the WordPress model will prevail. WordPress’s blogging software is free to download, modify and use. Additionally, WordPress offers a hosted platform which provides free and paid services based on usage and functionality.

More Info

Here are some interesting links we found while researching this post:

• Cloud Computing - Wikipedia
• How Cloud & Utility Computing Are Different
• When Do The SaaS Acquisition Games Begin?
• Rumor: Microsoft about to unveil web-apps strategy
• Rumors of Signs and Portents Concerning Freeish Google Cloud
• The three kinds of platforms you meet on the Internet
• I Want a New Platform
• The Information Factories

Sphere: Related Content

Posted in Research | 4 Comments »

Browser-Based Web Development

Apr 2, 2008 – 11:50 by Ryan

For the last few decades, there have been two primary methods for developing software. The first is the remote model where engineers write software on a networked server. Typically, an engineer will open a remote terminal session and use either Vim or Emacs to edit source files. The other, and more popular model (currently), is local development. An engineer pulls a copy of the source to a local computer and periodically push changes back to a central repository. Both models of development work and each style has its own strengths and weaknesses. Researching both models, it is clear that a new method for development is on the horizon — browser-based web development.

Local Development Issues

Local development has issues with intellectual property (IP). Companies do not want to expose all their IP to engineers, nor do they want to provide a simple way of moving that information from one computer to another.

From a practical standpoint, centralizing a team of engineers on a web-based editor simplifies development needs and reduces the costs associated with local/native editors. Open source local editors still have costs surrounding developer setup time and synchronization of configuration amongst team members.

Browser-based source editing reduces the risk of environmental differences. When engineers write code on a local machine the likelihood that all computers will remain in sync with the production servers is decreased.

Remote Development Issues

Granting engineers shell access on a remote server can open up a host of security issues. An organization must thoroughly (and continuously) audit the security of their servers to make sure they’re not susceptible to exploitation.

Remote server development has been out of style for a few years because of the tools available. Vim and Emacs are incredibly powerful tools that include most of the functionality (as well as a lot of additional tools) found in modern IDEs. However, the learning curve for these editors can be overwhelming for some engineers.

The Future

Expect to start using browser-based editors in the next several years. If you’re a Vi user, don’t worry, there is already a JavaScript version available :-)

Happy coding!

Sphere: Related Content

Posted in Research | No Comments »

FeedBurner: Broken or Biased?

Mar 25, 2008 – 08:31 by Ryan

After our post yesterday on Google and The Sushi Chefs we were shocked to discover that we didn’t have any RSS subscribers. According to our analytics data, the article was incredibly popular.

According to FeedBurner, everyone has unsubscribed (including everyone at Deft Labs)! We’re sure this is simply a glitch but it’s not the first time we’ve seen major errors with the service. We’re grateful that FeedBurner is there to provide feed syndication (and you can’t beat the price - free), but we’re a bit concerned about their quality of the service right now.

For those who don’t know, FeedBurner was acquired by Google in May of 2007 for $100 million.

Update: Two hours later, it appears as if they’ve fixed the problem :-)

Sphere: Related Content

Posted in Analysis | 2 Comments »

Google and The Sushi Chefs

Mar 23, 2008 – 13:55 by Ryan

Earlier this month, Kevin P. Ryan and Henry Blodget from AlleyCorp discussed Google’s recent market decline and what this means for the company. It is Ryan’s opinion that Google will be forced to reduce their workforce. This will be the real test of Google’s conviction to give back to their employees. The founders and early investors have amassed billions of dollars from the success of the company and now it’s time to see how they handle this situation.

photo credit: pittaya

From a practical business standpoint, Kevin may be right. Based on the recent loses, Google may face an investor coup d’etat if they don’t reduce their expenses. Below is Google’s six month chart:

Landing Where?

If Google does reduce their headcount, where will the engineers go? The majority of Google’s infrastructure is proprietary, so a lot of the tools/libraries that engineers have been exposed to won’t be too practical in the market (what do you mean you don’t have Bigtable?). Of course you can argue that a talented engineer is useful anywhere, however experience with software/technology that is in widespread distribution might be more valuable to some hiring managers.

Recreating the culture at Google will also be difficult. A company like Google, which has amassed so much wealth in such a short period of time, can afford to be more liberal in their employee benefits and productivity expectations.

We imagine a lot of cashed-out Googlers will end up hiring engineers for startups.

The Chefs

Having enjoyed the luxurious Google cafe several times over the last year, we decided that the litmus test for the wellbeing of the entire company is the sushi chefs. The state of the union for the 16,805 person company worth somewhere in the neighborhood of $135.86 billion is directly related to the employment of the sushi chefs at the various campuses. Having witnessed several less than stellar quarters at DoubleClick, we understand the difficulty that must come with justifying sushi chefs to ravenous investors.

A personal note to the sushi chefs: We like cream cheese with our asparagus roles. It’s a cheesy lowbrow taste acquired at an inexpensive Sushi restaurant on Khao San Road in Bangkok, but we just can’t shake it. But, in all honesty… we’re pulling for you!

photo credit: rick

Sphere: Related Content

Posted in Analysis | No Comments »

Yahoo! User Interface Libraries

Feb 28, 2008 – 17:14 by Ryan

We are always on the hunt for web technologies that add functionality and decrease development time. We have been tracking The Yahoo! User Interface Libraries (YUI) for a while and are finally ready to slap on the Deft Labs seal of approval :-)

photo credit: V.P.Tz.

Paradigm Shift

For more than a decade engineers have been debating about which technologies are best suited for dynamic HTML page development. Typically, a developer would fall into the PHP, Java, Microsoft, Perl, Python or Ruby camp. All the platforms have similar tools, strengths and weaknesses when it comes to dynamic page development.

Something a lot of developers haven’t fully grasped is that the future will not include much in the way of server-side Html generation. The Internet makes a lot more sense when HTML clients are developed exclusively in JavaScript/static HTML. The paradigm of client-side HTML generation definitely isn’t new but the tools available are finally maturing.

Review

Over the last year we researched Dojo, GWT, script.aculo.us, Prototype, and YUI. All the frameworks have numerous strengths and weaknesses but we found YUI to be the best in show. To make our decision, we looked at:

• Documentation
• Available Libraries/Functionality
• Sample Code
• Styling Attributes
• Developer Adoption
• Code Performance
• Reliability
• Project Progress
• Content Distribution

We found that when all aspects were considered in each framework, YUI was the best solution for us.

Content Distribution

The beautiful part about client-side HTML rendering is that your client can be deployed globally on a CDN. Requests for dynamic content will still be sent to your servers via AJAX but the amount of data transfered for each action/request is drastically reduced. Additionally, you can cache data on a CDN in the form of JSON encoded data structures/files.

An added bonus of using the YUI is that you are able to piggyback on their content delivery network. This provides lower bandwidth costs, geographic distribution but most importantly caching in the browser. Yahoo! also uses YUI so there is a good chance the libraries will already be cached in the user’s browser (thus decreasing the time to load the page).

SEO Issues

One of the primary issues with an all JavaScript UI is Search Engine Optimization (SEO). Most bots or crawlers are not smart enough (yet) to render JavaScript UIs. This creates a problem when user’s are trying to find a piece of content through a search engine. Until the crawler technologies catch up, there is a simple way around this problem. You can identify the user agent in the request and display a separate/simple page. For example, if the request detects a crawler then you can display your content in a bot friendly format.

Of course the links provided to the bot must be translated when the user agent is indicative of a user. To assist you in keeping track of the crawlers you can use the data provided by the Browser Compatibility Project. The basic flow of this looks like:

If you’re using Apache you can accomplish this using the rewrite module.

Another way to simplify things for crawlers is to create a Sitemap file with all of your pseudo crawler links. If you only have several pages that need to be indexed then you can always use the <noscript> tag.

Cost

Currently, there aren’t any fees tied to using YUI. However, we think that Yahoo! will eventually start charging for the content distribution. It makes sense for Yahoo! to create a loyal developer base first.

License

The source for YUI is freely available under a BSD style license.

Happy Coding!

Sphere: Related Content

Posted in Reviews | 2 Comments »