Skip to main content

Google lights a Campfire...

This week Google launched their App Engine Platform to add their hand to the collection of products and services provided by large and small providers of web frameworks. As a developer of just such a framework still in steath, the announcement is not a surprise (if it is to any of the other guys they may have a few things more to worry about) but with this announcement Google also announced a few "proof of concept" applications built using their App Engine. To demonstrate the ability to build apps quickly, three of their developers are said to have worked on their "spare time" to create a free web group chat application called HuddleChat very much like the service provided by 37Signals Campfire product. I am quite familiar with Campfire as in my initial research for developing a collaboration API in my framework 2 years ago I came across their website. The product serves a simple purpose of allowing a team of individuals to come together and converse in a chat room while sharing files collaboratively. It is precisely this simplicity that has made the product vulnerable, the technology needed to create such an app makes it simple to reproduce with other technologies. There is very little in the way of innovative distinction in the Campfire product that can prevent others from copying the functionality. Also, as far as I know the product implementation may not have any patents behind its technology. True enough, Google's Huddle chat is inspring some controversy in the blogosphere for how closely it mirrors both the look of Campfire and its functionality.

Having designed a collaboration tool that encompasses all the functionality provided by Campfire and Huddle Chat but includes a patent pending set of technologies critical to the scalability of the implementation I wonder why 37signals felt entitled to complain. It is clear from looking at the interfaces that they are layed out similarly but I wouldnt call one a clone of the other, Google could have used a different layout (say like parachat, meebo or userplanes for example) but the main fact that they are all using the same simple implementation method to make the chat work is common regardless of the interface. The machine behind is what needs to be unique and protected. If it is novel and efficient, it will allow a company to compete with established players and gain traction without fear of strong competition for a period of time that will allow them to hopefully thrive. This is what I hope to do with my product which will soon be coming out of stealth. I look forward to seeing if Google can "throw together" a scalable competitor to my service when I do...just so long as it takes them about a year or two to get it out there;).

Bring on the competition I say!
Labels:

Comments

Post a Comment

Popular posts from this blog

the attributes of web 3.0...

As the US economy continues to suffer the doldrums of stagnant investment in many industries, belt tightening budgets in many of the largest cities and continuous rounds of lay offs at some of the oldest of corporations, it is little comfort to those suffering through economic problems that what is happening now, has happened before. True, the severity of the downturn might have been different but the common factors of people and businesses being forced to do more with less is the theme of the times. Like environmental shocks to an ecosystem, stresses to the economic system lead to people hunkering down to last the storm, but it is instructive to realize that during the storm, all that idle time in the shelter affords people the ability to solve previous or existing problems. Likewise, economic downturns enable enterprising individuals and corporations the ability to make bold decisions with regard to marketing , sales or product focus that can lead to incredible gains as the economic ...
1 comment
Read more

How many cofactors for inducing expression of every cell type?

Another revolution in iPSC technology announced: "Also known as iPS cells, these cells can become virtually any cell type in the human body -- just like embryonic stem cells. Then last year, Gladstone Senior Investigator Sheng Ding, PhD, announced that he had used a combination of small molecules and genetic factors to transform skin cells directly into neural stem cells. Today, Dr. Huang takes a new tack by using one genetic factor -- Sox2 -- to directly reprogram one cell type into another without reverting to the pluripotent state." -- So the method invented by Yamanaka is now refined to rely only 1 cofactor and b) directly generate the target cell type from the source cell type (skin to neuron) without the stem like intermediate stage.  It also mentions that oncogenic triggering was eliminated in their testing. Now comparative methods can be used to discover other types...the question is..is Sox2 critical for all types? It may be that skin to neuron relies on Sox2 ...
Post a Comment
Read more

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform cert...
2 comments
Read more