The Cloudy Bit

Remember the first time you drew this on the whiteboard (obviously in your own hand drawn style)?

What exactly did you mean by that cloudy bit? Well, what I usually meant was, a place where stuff that I needed to get done, would get done, without me knowing exactly how. I guess I mostly meant the Internet.

Move ahead until today and now hundreds, if not thousands of people (and companies) have tried to define the “cloud”. One company even tried to trademark it. The problem is, what many of these definers fail to remember is the basic premise of the cloudy bit - automatic satisfaction.

Here’s what I mean by that. Today, most of the cloud definitions that I read seem to define something more like this.

Unfortunately, a large majority of today’s definitions of the cloud are basically defining are a new form of hosting environment where the major innovation is “infinite” capacity, that you can enable in a very short time period, and that you pay for by the hour versus by the month. It is an new hosting environment where people and management software must still by employed to make the "cloud" operate.

What these definitions absolutely do not describe is a reality where “hardware need satisfaction” happens automatically. And, they certainly do not reflect my first notion of the cloudy bit. If you want to check out another (fun) perspective on today’s definitions for the "cloud" check out James Governor’s, 15 Ways to Tell Its Not Cloud Computing.

The question for me is why this new form of hosting is being passed off as cloud computing when the promise of the cloudy bit is, things you need to happen, happen automatically?

The short answer is hype.

So, since the hype is already overwhelming and many people and companies have defined the “Cloud”, what I want to do instead is define the “Cloudy Bit”.

James Duncan and I, mostly because of developing the Reasonably Smart business plus James’s past experience with the zimki platform, have spent a great deal of time thinking and talking about the “what exactly is the cloudy bit”. The purest example we have come up with is a SaaS application.

Applications like Salesforce.com’s CRM system or Google Docs are truly delivering functionality and real value based on an architecture diagram I first drew on the whiteboard. The user accesses the functionality and data on their computer and the things that make the application work really happen in the cloudy bit. No investment of effort or time on the user’s side is required. The user can make assumptions about where the data is housed, where the application is being served from and how the hardware is configured but, more and more, they would be wrong (especially when it comes to SaaS applications provided by today’s smaller companies and start-ups).

If you look at the components of a SaaS application (from the simplistic perspective) you will see that the “cloudy bit” looks like this:

The application code is the part that links the user to the functionality and enables the usable transfer of data.

At the platform level exist the operational components, including things like the load balancer, web server, virtual machine, message queue and data store, that make the application run (and scale). The operational platform handles things like security, session management, information distribution and interacts with the servers.

And, then there is the hardware which is basically the OS, machines and infrastructure pipes that provide the power and store the data.

The entire stack is the “Cloudy Bit”. Why? Because the user operates the software without ever considering any of the layers in the stack.

So to be a true "Cloudy Bit" provider you really need to be providing the entire stack. More precisely you need to have the capability to run an application (yours or the customer’s) without the customer having to do anything to make it run – at any point of the application’s life cycle.

So far my point is that SaaS applications are truly representative of the cloudy bit and hardware providers, unless they can automatically scale machines as an application’s consumption requirements change, are not.

Now, let’s look at where Platform as a Service companies like Reasonably Smart, Google App Engine or Force.com fit in. Is a PaaS company a cloud provider?

To analyze we can start at the bottom of the stack. What needs to be asked here is do these companies provide the hardware required by their customers automatically? The answer is yes. A person running an application on Reasonably Smart, Force.com or Google App Engine never needs to ask the provider to add or subtract machines to meet their requirements - it happens automatically (from the user's perspective).

Moving up the stack, the second question is, do PaaS companies provide the operating platform in a way that the customer does not worry about it? And again, the answer is yes. A developer creating on any of the aforementioned platforms does need to know how the platform is structured or what component parts are used. In the case of Reasonably Smart, the developer can know because of its open source model but needs to do nothing with this knowledge to make their application run.

Where it gets interesting is when you ask, do these companies provide the code that enables the application to function – the last piece to the cloudy bit definition. In this case, the answer is no. However, what the PaaS providers do give the developer is the foundation on which to create the entire cloudy bit by offering the environment where they can write code and once finished the result is a full blown SaaS application - without any investment in building the platform or hardware infrastructure layer.

And the really exciting part about this is the developer has just leapfrogged traditional SaaS providers like Salesforce for their CRM solution and Google for Docs because today's SaaS companies actually have to manage their infrastructure everyday - regardless if they run on their own hardware or if they run it in the "cloud". If you write on a platform you never will.

So, when you are considering building an app that leverages a cloudy bit architecture you may want to consider a Platform as a Service to minimize your long term costs and potentially out smart your competition.

If you need more information on this topic we would be more than happy to discuss it further.

Wishing Brainpark Good Luck!

I went to Guelph Ontario last Wednesday for a party. No really, I did. It is something I haven't done since my days at Wilfrid Laurier U. And even back then I am not really sure I ever went there on a Wednesday.

The reason I decided to make the trip from Montreal was to support the Brainpark launch and to see how Mark Dowds, a master promoter in his own right, and his team would introduce the new company to the world.

I have to say, I was impressed. The turnout was great. People had come in from all over. The mood was light but had a underlying sense of purpose. It was a very good mixture of networking, demo, interaction and partying. The open bar never hurts.

In the end it was both informative and very fun. Well worth the trek from Montreal.

Good Luck to the Brainpark Team!

Languages in Reasonably Smart

What I love about JavaScript isn't just that it is the programming language of the web, or it's most elegant object system, or even the functional capabilities that are in SpiderMonkey.  With my platform-provider hat on what I love the most is that it's a hardened language.

JavaScript (or, more properly, ECMAScript)  just doesn't have that many capabilities built in, beyond the basic language mechanisms you find in any other programming language.  Sure, you can allocate memory, or put it into a tight loop, but all of those things are detectable from our perspective - again, that of the platform provider.   The big thing you don't get out of the box of course, is IO.

IO is our job.  Reasonably Smart provides carefully wrapped capabilities to read from disk, write to the datastore, and a whole bunch more.  More importantly, we can do it in a secure, considered manner.  This lets us run many different applications on a machine, or a cloud of machines at the same time, without having to carefully vet each codebase to make sure it's not going to do anything bad.

However, some people react strongly to the idea of Server Side JavaScript, and we realize people do like other languages too, which is why we multiple-language support is on our roadmap.  To shine a little more light on our plans -  it's why we're so keen on seeing Mozilla's IronMonkey project get going, and why we are going to support it in any way that we can.

IronMonkey is a planned development to get IronPython and IronRuby compiling to the Tamarin Virtual Machine (the JITting ECMAScript VM that Adobe open-sourced with Mozilla a couple of years ago).   When the IronMonkey project is complete Reasonably Smart will be able to support any language that compiles to the Tamarin virtual machine. 

Having multiple languages is important to us, but not more important than having a safe, secure environment for our customer's applications to run in.  Thanks to open-source, and Mozilla, IronMonkey will help us get there.  In the meantime, we think JavaScript is great - if you've not programmed JavaScript without all that tedious mucking about in the DOM, try it - you'll be pleasantly surprised!

Financing the PaaS - A Friendly Host May Be The Answer

The Reasonably Smart project has just crossed into the 9th week of our funding mission. Let me just say, it has just been a fantastic 8 weeks to be raising capital! Especially with all that stability, strength and optimism all around us!

Actually, despite the fact the "sky was falling" over the past two months the response to our company has been generally positive. Many of the VCs that we have talked to have indeed passed – as they do – but a couple are digging in. Unfortunately, we are still a long way from a deal.

On the bright side, one concept that is picking up momentum is one we were aware of but did not immediately pursue. That is the option of strategically and financially partnering with a hosting provider. Originally we did not move in this direction because of the bias we had towards hosting companies generally being "traditional" suppliers to us. However, based on the conversations we have had over the past 2 - 3 weeks, we realized that they could be so much more.

The whole cloud computing evolution has completely changed how innovative hosting companies are viewing the future. Deals are being made all over the industry that are designed to "on ramp" these companies to the cloud. Hosting companies who want to broaden their offering and/or add more depth to their stack are looking at Platform as a Service (PaaS) with great interest. Those providers who are extremely forward thinking and who want to engage the developer directly and/or create a developer ecosystem, are beginning to see how leveraging a PaaS could be a great way to do this.

Fundamentally, with certain providers the realization seems to be that their hardware is the power generation plant, and a PaaS could be the distribution network that links them to the "home and office". This is all good news for Reasonably Smart as our funding options are increasing "in this time of great need" .

So, if you are a hosting/hardware cloud provider who is looking to extend its offering, its reach and embrace the developer directly, have a look at partnering with a PaaS company.

And, more importantly (to us), if you have money to invest and are going in this direction, take a look at Reasonably Smart as we are still looking for our partner.

Agreeing on Cloud/PaaS Principles

Simon Wardley recently posted on his blog, Bits or Pieces?, about his "rules of happiness" when he considers cloud computing. For those of you who do not know, Simon is a pioneer in this space. For several years, he has been thinking, writing and talking about PaaS and the cloud industries. Three or four years ago he and his team at Fotango (which included Reasonably Smart co-founder James Duncan), built what was arguably the world's first Platform as a Service, zimki. Since then Simon has been front and centre in the PaaS/Cloud discussion.

In his post he first mentions some "absolute minimums" that the service must have/be:

• Readable access to all data, code, frameworks and meta data that may have been created as a result of using the service
• Secure, scalable, resilient and charged for on an "as use" basis
• Clearly communicate T&Cs that cannot be changed without reasonable notice, and reasonable alternatives
• Transparent pricing

Simon then goes on to explain that once a service meets these bare minimum standards in order for him to be happy he applies the following rules (these are direct quotes):

Rule 1: I want to run the service on my own machine.
This enables me to trial out a service before even considering adopting a cloud version and gives me a last resort fall-back option. I certainly don't want to be in an environment where I can't do this for whatever reason, including vendor failure or discontinuation of a product.

Rule 2: I want to easily migrate the service from my machine to a cloud provider and vice versa with a few clicks of a button.
If the test went well then I'll probably consider dipping my toe in the water. Hence I want an easy to use transfer mechanism for my data (including any code or framework elements) from my machine to an external cloud provider and vice versa. I do not want to learn any specialised skills nor require any technical knowledge beyond pressing a button.

Rule 3: I want to easily migrate the service from one cloud provider to another with a few clicks of a button.
If I'm going to use a cloud service then I want a choice in providers and an easy mechanism of switching between alternatives. I do not want to discover that switching only covers half of the service and fails to cover other elements like the storage subsystem or a messaging service.

He ends his post by saying that, "For these reasons, I'm not very happy with most of the current cloud offerings".

After reading Simon's post there was a sense of validation. His bare minimums and rules are all core to our fundamentals at Reasonably Smart. Portability, transparency, ease of use, reliability, security, scalability are what we are building and delivering with the RSP. The only exception could be meeting the "pricing transparency" requirement but that's only because we aren't charging yet. Once we start billing (launch of v1.0), we are going to be billing for consumption in a utility model (pay for use) and our pricing plan will be clearly explained on our new website. See the post on our pricing model.

We realize we have a ways to go to prove out that the fundamentals are consistently delivered. However, we will continue to build the business based on our core philosophy. The great thing is now we can print out Simon's post and put it on the whiteboard as both a reminder and encouragement.

Thanks Simon.

PaaS Channel Strategies

Over the past several weeks we have had many conversations about how to build our business with various people. One of the strategies that we have consistently discussed and are very bullish about is the strategy of building strong relationships with those companies building websites and web apps. In other words, engaging with companies like: design shops, agencies and software consultancies.

We are excited about this targeting strategy because these types of companies have the access to a regular stream of new projects and the budgets associated with them. We are also excited because of the benefit that we can deliver in return. Benefits ranging from speed to market, to added end customer benefit (lower operational costs) to code reusability, and last but definitely not least, a potential recurring revenue stream through revenue sharing, are resulting in interest from most we have talked to date.

One company that we are currently exploring a strategic relationship opportunity with is BCM. BCM is a large, 11 year old, Mexico based technology consultancy with a broad range of services and a consistently impressive annual growth rate. Last week, after working with Miguel Caron (CEO of BCM International), BCM began helping us develop an application on the RSP. At the same time, the plan is to have their developers evaluate the RSP while they work with it.

The goal of this project is to have BCM identify the types of projects that they deem to be well suited for the platform so that they can leverage its power to deliver those projects more quickly, efficiently and with the potential of generating recurring revenue in future. We are very excited about the early results and thank Miguel and his team for the referrals they have past on to us over the last couple of weeks.

Other companies that we have talked to include: Eric and Sylvain of iWeb, Stephen Walsh of Sinodev, and Niko Leger and Karim Barbir of PhiVision. Each has provided their own unique and valuable perspective on what we are doing at Reasonably Smart. PhiVision is considering building a relatively simple website on the RSP and the others are looking at how the RSP would benefit (or not) their business.

Fundamentally, the early positive response solidifies our belief that there is an additional method for building a business like Reasonably Smart over and above just driving adoption in the developer community.

Consultancies, agencies and design shops are in our sights and we are going to do our best to capitalize on the opportunity with them.

All up and running again...

Basically, our hosting provider got DoSd. Once we have funding in place, and our hardware is built out, we won't suffer this again, but for now, you have our apologies.

Working through it...

Just checking a disk and then we should be able to be back on line. Sorry for the delay.

Issues

We're currently experiencing a problem at our data center. I'll keep updating this with news until we're back up.

Web2.0 NY Participation -- Better Late...

About 15 days ago, James and I attended Web2.0 Expo and Interop in NY city. We have been very busy since the conferences building our business so, there really has been little time for reflection. However, it is worth a post to quickly recap how these shows acted as validation for our new venture. Over and above just meeting many great people and having several in depth discussions, there were several moments that further solidified our belief that we are definitely onto something big and more importantly, valuable here.

First, we attended a panel discussion called Building in the Clouds: Scaling Web 2.0. Although it was a pretty general talk about PaaS and Cloud computing what was positive was the panel make-up.

The panel members represented the large and the small, the established and the emerging and they all had a singular message...

Cloud/Platform Computing is going to continue to provide more and more value to those who develop and deploy web applications.

The conversation focused on the value proposition of the cloud and many strong points in favour were made. However, despite the bias of the panel, there were also many valid concerns brought to the forefront with guidance for navigating these concerns.

At Interop, I was fortunate enough to catch Peter Laird's talk on The Taxonomy of On-Demand Computing, where he did a fantastic of organizing the mess that is, the term cloud computing. Anyone who is interested in figuring out who sits where in the cloud needs to check out his blog post where he graphically illustrates the industry (unfortunately I do not think he included Reasonably Smart yet - we are eagerly awaiting the October update).

We were also fortunate enough to carve out 30 minutes of Tim O'Reilly's time to bring him up to speed on what we have completed since his keynote mention of us at this year's OSCON in July. He told us to keep him informed of our progress and we certainly will.

There was what could be considered a 'meeting of the minds' when we sat down with Dwight Merriman, CEO of 10gen. 10gen is easily our closest competition in the PaaS space but, this did not stop us from leaving our discussion agreeing to work together moving forward. How, you ask? Well the starting point is to get together to begin defining JavaScript on the server standards. It's a good idea for both of us and funny enough while speaking with Paul Colton, CEO of Aptana yesterday, he also expressed interest. We are targeting late October to kick this project off.

Finally, we were invited to moderate the cloud computing component of Interop's Unconference by Alistair Croll. At its most intense, there were 20 - 25 people hotly debating issues like security within the cloud, the differences between clouds and whether or not it would really be possible to broker the world's excess server capacity.

One thing that nobody was debating... if there is value in the cloud. This, for us, is a good thing.

First Reasonablysmart.com Customer Site

We at Reasonably Smart are proud to announce that we now have our first customer site up and running on the Reasonably Smart Platform (RSP) - http://trientje.reasonablysmart.com/. The site is owned by Katrien Janin - Designer and Usability expert extraordinaire.

As many of you close to the company know, Katrien is the wife of Reasonably Smart's founder and CTO, James Duncan. Given this fact, it's a special kind of validation for me that despite the husband and wife thing, she trusts and believes in the platform enough to host her newly launched business website. Tremendous!

In other customer news, on Monday of this week we launched a project where we are working with an accomplished group of Montreal-based software executives to deliver a comprehensive social network application. We are very excited about this project and hope to deliver the beta by the middle to 3rd week of October. Once operational, this customer's application is sure to showcase much of what the RSP has to offer.

Reasonably Smart Pricing Model

To date we have not talked much about how Reasonably Smart will generate revenue. This post is an overview of what our revenue model will look like once the billing engine is turned on.

Reasonably Smart plans to employ a utility model for the use of its platform. We will be charging users of the platform for the consumption of server cycles, storage and bandwidth. Our pricing for Storage and Bandwidth will be competitive with what is being provided through Amazon's EC2 and S3 offering.

Where Reasonably Smart differentiates significantly from most of the Platform as a Service and Hhardware Cloud providers is in how we are charging for processing or what we call server cycles. Here we will be charging at the micro-unit level so the user of the platform literally only pays for what they use.

We have completed some testing that demonstrated that a typical directory web site that receives 20K hits per month would cost the operator between $5 and $6 per month. Keep in mind that this testing was done on a $20/month box located at Slicehost that has not been optimized in anyway.

One area where this model provides benefit is during development of an application or a website. Because the developer does their coding in their own environment he or she will not incur any costs until they push the code back to the platform to execute their tests or run their application. We anticipate that this will save those who do a significant amount of prototyping a great deal of money.

This model will also save the small website owner (the hardware store, etc.) money. If they only get a few 100 hits per month then instead of paying for the base package (like the $20 per month we are paying at Slicehost) they could end up paying pennies.

For the large applications or those that go viral the model provides linear cost predictability at the hit (URL) level. We anticipate that this will be a significant strategic advantage for our enterprise users.

Will Reasonably Smart be cheaper than EC2?

In response to James's post Ning shuts down WidgetLaboratory, Chris Holland asked if the Reasonably Smart Platform (RSP) would be cheaper than Amazon's EC2. It's a valid question that deserved its own blog post as a response.

So, will RSP be cheaper than EC2? The short answer is maybe.

The long answer needs to be looked at from a couple different angles.

1. Should the pricing of the two companies even be compared given the businesses they are in?
2. If they are in the same business will Reasonably Smart be cheaper than EC2?

In their own words, Amazon, through EC2, delivers a true virtual computing environment, allowing you to use web service interfaces to requisition machines for use, load them with your custom application environment, manage your network's access permissions, and run your image using as many or few systems as you desire.

In other words, they let you rent servers and bandwidth in shorter time frames then what was available from traditional hosting companies. Plus they make it "easy" to increase and/or decrease the number of machines you are renting quickly.

In our words, Reasonably Smart's mission is to develop and manage the open source Platform-as-a-Service that enables web application development in a Peer-to-Peer cloud/utility computing environment and empowers collaborative, efficient, industry transforming web application creation.

In other words, we provide an environment for you to develop and execute web applications.

The major differences between the two being that on our platform you can develop your web application without concerning yourself with:

• Creating, managing and scaling a database
• Creating back-up routines and load balancing between servers
• Developing an execution environment
• Managing security patches
• Hiring and managing system administrators
• Engaging (and paying) cloud computing management system providers
• Figuring out how to be "at the edges of the network"

A couple of other pieces of added value within the RSP platform over and above EC2 are the integrated distributed version control and the core philosophy of open source.

So the first answer to the question "will RSP be cheaper than EC2?" is that they are difficult to compare because there is much more value being provided by RSP than EC2.

Now, if you completely discount the Platform as a Service (PaaS) value proposition then the question of who will be cheaper comes down to the vision of the two companies for the (hardware) cloud.

Amazon has huge buying power, and can reach economies of scale that are difficult for others to attain. However, the RSP has been designed to be completely hardware-provider agnostic. Therefore, our hardware layer options could include EC2, IBM, Dell, EMC, any hosting company, our own datacentre, the server under your desk or all of the above. This makes the answer to the question most easily broken down like this:

1. If RSP utilizes EC2 as its hardware layer then RSP will not be cheaper than EC2
2. If RSP utilizes several data centres (EC2, EMC, IBM, Opsource) then RSP might be cheaper than EC2
3. If RSP reaches its "blue sky vision" of leveraging the world's excess server capacity then it is likely that RSP will be cheaper than EC2

Fundementally we believe that someone needs to start identifying the difference between a hosting provider and a cloud computing environment in light of all of the misrepresentation in the market and media. What Amazon are doing with EC2 is fantastic, and makes renting computing power more straightforward than ever before. They are, undoubtedly taking away the need to plug in server, and wire it up to the network. But don't forget, there is a difference between being in the cloud and being the cloud.

Hopefully this addresses both the question about who will be cheaper and starts to illustrate more clearly some of the differences between ourselves, and other "cloud" computing companies.

TraceMonkey

A decision that I made early in the development of Reasonably Smart was to completely ditch the idea of building my own, hardened version of various languages for the runtime engine.  Instead we embedded Mozilla's SpiderMonkey engine. 

We've fielded questions on this a number of times, so I thought I'd write a little about the decision here.

Firstly, we don't have an infinite number of engineering hours.  We're not language builders, and we need to focus very clearly on building the datastore, machine infrastructure and management tools that benefits our customers.  Secondly, the Mozilla team are going to be building around SpiderMonkey for the forceeable future. Improvements like Tamarin only benefit us (and projects like IronMonkey may allow us to run Ruby, Python & PHP code in a hardened environment too).  While we'd love to be able to contribute back to Mozilla eventually, right now we can't afford to.

Announcements like today's about TraceMonkey validate this decision further.  We'll be able to benefit from this change very quickly -- we've already got a version built in development, and as soon as it hits a stable point, we'll be able to roll the change up very quickly.

Ning shuts down WidgetLaboratory

This morning Ning removed WidgetLaboratory's account and service.  While I'm sure they had what they think is a good reason for doing so this sort of thing is exactly the reason that Platform-as-a-Service providers must be open source.

WidgetLaboratory, for those of you who don't know, makes widgets that other Ning network creators could plug into their own sites.  These widgets of course were things that Ning didn't provide themselves, and a lot of people are very upset about this.

As I see it there are four outcomes here: WidgetLaboratory's service is restored, the people who are upset build their own replacements, the people who are upset stay upset, or Ning provide alternatives.  Of the four, I think the best possible outcome for Ning will be if they follow the first path -- if there was a ToS violation, fix it, restore the service, and move on.

 

We feel that the worst outcome would be if Ning went down the route of providing replacements.  The idea has already been floated by others that perhaps WidgetLaboratory's widgets were somehow encroaching on Ning's revenue.  If Ning recreate the widgets then fuel will merely be added to that fire.  Of course, it's only a possibility at this time, but it highlights something else we strongly believe.

We think a Platform-as-a-Service must be charged on a utility basis.  We don't think freemium models can work, because the provider will always be looking to expand their premium offering and sooner or later these will collide with those of their customers.  When that happens, sparks will fly, and fires will start.

Fundamental to everything we're doing is the belief that a utility model works for everybody - the customer wins because utility models are more fair, and the PaaS provider wins because more usage from your customer's customers means more revenue for you -- never less.  As a business-to-business software service, we believe there needs to be clear blue sky between what we offer, and what our customers offer.  That's very hard, and will continuously get harder, with a freemium model.

Reasonably Smart is open source, and is going to operate under a utility model.  We'll charge for bandwidth, storage, and operations in the VM.  You can build what you want, and if you don't like how we operate, or feel our charges are unfair, you'll have the ability to take not only your code, but our code as well, and it run elsewhere.

Thoughts?

Good to be on the Receiving end of Patches

It's especially good when a lot of your time is being used by working on the business itself.

On that front, I have to thank two people especially.  Firstly, Claes Jakobsson, creator of JavaScript.pm, and without whom RSP would not exist.  Claes has been incredibly helpful, working on ironing out a few bugs in JavaScript.pm, and introducing a couple of new capabilities that are needed to push what the RSP is doing to another level.

Secondly, Hans Dieter Pearcey sent me a few patches for the RSP itself.  One of them was on my todo list, so I'm incredibly happy to apply it into my working tree.  HDP also fixed up my Makefile.PL so that it has all the correct prereqs in there.  Another win!

I'm also trying to track down what is stopping ClaimID OpenID's from working, reported in our Google group.

So a huge thank you to everybody who has taken the time to look at, fix, and report problems and, even better, come up with solutions!

VC Financing - the Certainty and the Uncertainty

We at Reasonably Smart (James and I) are now fully engaged with the VC community. Since last Wednesday, we have had 5 meetings with various potential partners. The discussions included potential partners Storm Ventures, Montreal Start-up, Neotech Ventures and Desjardins. This week we are talking to OATV and JLA Ventures. I know, we are all over the place.

Obviously, these discussions are not the result of a well thought through plan but more a result of the significant positive PR received so far and leveraging our network. This is both good and bad...

In my previous life, I has the opportunity go through the funding exercise on 3 occasions. This experience exposed my to all types of organizations all over North America, including VCs, Investment Banks, Sub-debt lenders and the advisors. Although I talked to several North American VCs, the VCs I became close to were mostly Montreal based. To be truthful, I have little experience with the "valley" based organizations. With Reasonably Smart, this is changing quickly...

The current business is much more "technical" than the last business. It does not have as big a service component so it fits very well into the VC sweet spot. Which is great because everyone we contact is somewhat interested. The downside of this is, everyone is interested. Combine this with the fact that we are being contacted because to of the PR and it's obvious that targeting and keeping focus are going to be key challenges we need to navigate.

With my somewhat limited experience I am pretty sure of some things and unsure about many other things when it comes to raising money. Here's the summary:

Certainty:

• Conceptually, raising equity is straightforward
• In reality, raising capital is often affected by factors beyond your control
• The Canadian VC market is stagnant
• A couple of Canadian VCs still invest in good businesses so they can't be ignored
• Referrals really help
• Advisors are usually overrated, viewed negatively by the VCs and unnecessary for early round funding projects
• Fund raising without a targeting strategy causes inefficiency
• A VC's deal flow and timing can and does affect whether a good idea gets funded with them

Uncertainty

• Do you ever submit an Executive Summary via a VCs website?
• How do you really target the "best VCs" for your business?
• When is a VC just saying nice things and when does what they say really mean they want to invest?
• Is a California (valley) based VC really the be-all and end-all for a software company?
• How much does an strong advisory board help?

With these ideas and questions in mind we are now both reacting to the interest and approaching "target" VCs. We are absorbing all the advice that comes our way and we are hopeful that we make the best decisions for this business. Ultimately, we are not looking for the "perfect deal", just a good deal with strong partners to help us get this venture growing.

If we accomplish this reasonablysmart.com is on its way!

Quite A Week

Since getting the "alpha" version up and available, reasonablysmart.com has had quite a week. It all started with Tim O'Reilly's keynote. From there the interest has grown quickly. The site has seen significant traffic everyday and it's coming from all over the world. There has been a number of writes ups and the CIO article has been reprinted in many online publications. James is receiving much appreciated feedback on the platform. There have also been interview requests. V good for the first week with no money.


Now it is time to get serious and raise the required capital to make a business out of what we have started. We have already written a overview of the business plan and today we will finalize the financial forecasts. We should be ready to talk to potential financial partners by Friday.


If anybody is interested in finding out more about our exciting new venture please contact me at bbogens1@gmail.com.

Article from the Keynote

CIO magazine also made mention of reasonablysmart.com as a result of Tim's Wednesday Keynote. It's great to be a cool startup!

Reasonably Smart Keynote Mention

It was very good of Tim O'Reilly to mention the Reasonably Smart Platform during his OSCON keynote.

Introduction

Hello Software World! My name is Bryan and I would like to introduce myself. I am the co-founder of Reasonably Smart**. In fact I am the reasonably smart one. James Duncan, my friends, is the really, really smart one.

Despite founding and operating a SaaS company for the past 8 years I have never really immersed myself into the software development environment outside of my own company. This has now changed.

James and I are working hard to create a powerful, exciting and value delivering Platform as a Service that we can all sink our teeth into and derive value from. We are building this platform so that it will support everyone from the individual to the corporation. The two of us are both are very much aligned in overall philosophy about how this platform must be designed. Fundamentally it must be:

• Open
• Scalable, redundant, secure, etc.
• Full-featured at the application level
• Well-supported beyond the help desk - more specifically, solid professional services
• Did I say open?
• Integrated with version control
• Free of lock-in tactics
• Open

I, obviously, will be concentrating on the business building elements of growing this company so, when you are reading my posts, you will be reading about things like:

• The company's product road-map
• The revenue model
• The professional services and support we will be offering
• The company's funding activities
• The developer community that we will try to bring together
• The applications that we will build to give our customers a head start
• The company's human resource needs

We now have the "alpha" version up and running at reasonablysmart.com. We are hoping that you can spend a little time playing around with it and providing us with some feedback.

While you are doing that and James continues to work on the infrastructure I will be putting the finishing touches on the business plan. We will then contact targeted potential funding organizations to see if we can secure the needed capital for the next steps of the plan.

Please stay tuned. This is going to be a very fun and interesting ride...

** a working name - comments welcome

Next!

...on the code front, having done the Apache integration is the object store.  I'm still writing documentation for what we have already, but I'm talking specifically about code here.

As you'd know from the open source code, a part of the Candomble (the internal name for the object store) is based upon SQLite.  Specifically, the bit that writes to disk, when it needs to.

However, we're designing this system to run on multiple machines, transparently, so what becomes absolutely needed is a message passing architecture.

Here are some of the basic requirements of a cloud object store:

1. Distributed - the system needs to distribute data across many machines
2. "Self Aware" - as more machines come into play, the load is shared without any manual configuration on the part of the datastore clients or the datastores themselves.
3. Redundant - each piece of data always needs to be in at minimum, two places
4. Predictable - should go without saying really, but the datastore needs to have predictable speed.  It's easy to make it go blindingly fast, but better is that it operates at a reasonable pace, all the time.
5. Segmented - again, it should be obvious.  Because we're storing data for multiple sites, it needs to segment itself nicely into data partitions for each of those sites, without fear of that data colliding. 

There are others, but those are the ones I'm having to deal with right now.

Managed to break OpenID

I really like OpenID, but at times its a really finicky thing. I'm getting to the point that if I change something, the first thing I check is OpenID to see if it's still working.

It's all working again now, but it always seems to be touch and go...

*sigh*

Apache Integration Done

Well, that's the Apache integration done. It was a bit hairy this morning, trying to get it all running.

Still, I got there in the end, and it's all tied together nicely. Appropriate layers of abstraction are cool!

Code is up!

With Reasonably Smart, we're committed to being as open as we possibly can. In the case of our software, it's mostly open source already. You can fetch it now, using git, by cloning http://platform.reasonablysmart.com:81/.

The next parts I need to work on (and its getting urgent) are moving away from the hand-rolled web server (which has served us well, and is great for development purposes) and on to Apache. This won't be hard, I just need to get it done.

Getting Started... wow!

We're just getting started at reasonablysmart.com, and it's quite an endeavor we're embarking upon.

The system is, of course, in its infancy, but we're trying to do the right thing from the start.