Involvd.com

To help describe the route I’m intending over the coming months I’ll try to cater for different learning styles, especially both right and left brain thinkers, so I’m going to lean on an excellent concept being developed by Peter Hilton (@PeterHilton) of Lunatech Ventures currently. The Plancruncher website is here.

Having been inspired by the simplicity of the Creative Commons icons they’ve created a series of images that could be used to cover-note business plan Executive Summaries. They’ve identified seven standard sections of a plan within which the writer can summarise their offering (the team, the idea, the product/service, the revenue model, funding requirements, partnership requirements and the return on investment detail). Here’s Peter’s full presentation.

Now I’m not looking to summarise my business plan for a pitch just yet but I should be able to use the model to show the position I’m in today, the position I’m looking to get to when funding will be a requirement and a mid-way step in between. So here goes:

Phase 1

• The product is vapourware (no working demo or prototype)
• There is no team (it’s just me)
• The idea is new and is going to take the world by storm
• The founder is an ambitious and wildly enthusiastic entrepreneur
• There is an elevator pitch that receives great feedback wherever it’s rolled out

Phase 2

• The product is a combination of several well proven concepts
• We are building the product ourselves
• We’re open-source through and through (both technologically and culturally – see earlier post)
• We have a prototype that is invite-only to allow us to manage load and receive valuable early feedback
• We are bootstrapping (self-funded) and are extremely careful with our expenses and costs (as we always will be as long as I’m involvd)

Phase 3

• There is a main revenue stream with more in the pipeline (none are advertising-based)
• We have developed the product and own all the IP
• We have a working product live on the internet
• The community is our #1 asset and we treat them accordingly. Network effects are present and we’re heading for critical mass
• We are looking for funding in return for a share of equity

So there we go, I hope that gives you more of an idea of where I’m going with this. Priority #1 at the moment is to turn this from an “I” to a “We” so early next week I’ll be launching my recruitment campaign.

When I have built a team I intend for us to work out together the details of how we’re going to get from Phase 1 to Phase 2. I’ll be sure to let you know how I get on.

Coming soon — launch of the recruitment campaign, early progress

Q: What the **** is copen source?
Me: Fair question! Copen source is my chosen development style or methodology. Mostly open source with a little closed thrown in.

Q: Not heard of it I’m afraid. What’s that?
Me: Not surprised really. I’ve just made it up.

Q: Will it succeed?
Me: No idea. I’m not sure it’s been tried before.

Q: Why are you doing it then?
Me: Because I want lots of people to come and help me bake the cake.

Q: What are you talking about?
Me: Well it’s like this. I’ve created what I think is a nice sounding recipe of a cake and I want to get lots of others to come and help me make, bake and taste it. I’m figuring that the more people that come and stick their fingers in the mixing bowl the better the likelihood that the final recipe will be knock-out tasty. The tastier it is the better it will sell, right?

Q: Yeh I guess. What happens when this cake of yours is done?
Me: Well that’s another reason to go down the copen source route. Once the cake is ready then it needs to be decorated. Now not everyone wants their cakes to look the same, do they? So we’ll need lots of others to come and help pretty it up. If there are plenty of people already involvd in the project then we’ll be off to a flying start.

Q: Right … think I get it … can you break it down for me and maybe keep these cakes out of it?
Me: Sure. As the name implies (visually) it’s 80% open source and 20% closed. C-O-P-E-N. These 5 convenient ‘C’ words provide a little more detail of the characteristics from both systems that I’ll look to leverage:

Cost [open]

• Developers will self-organise into teams or work individually (depending on their inclination) which will mean very low management overheads
• They are also involvd for the opportunity of achieving the project’s vision and not solely for monetary compensation. They are here to be part of something great (with the added bonus of employment and share options if the launch goes well)

Capacity [open]

• “Given enough eyeballs, all bugs are shallow” said a very wise man once. Larger groups of developers coding and fixing bugs can put orders of magnitude more skilled time into solving problems and developing new functionality than they can in smaller closed systems

Capability [open]

• Every open-source project has some kind of under-the-table reputation management system bubbling away. This dictates who in the project exerts the most influence and the best naturally rise to the top

Condition (also read Quality, Reliability and Security) [open]

• Implementations that have been comprehensively peer-reviewed by many can be better trusted to have code that is efficient, scalable and secure. Developers tend to be less territorial over their code in open systems
• Developers who work on their own terms (when, how, on what) are more content and motivated to produce better work, “enjoyment predicts efficiency”
• Open and transparent feedback loops ensure project goals are defined not by management committees but by users alone
• Succession planning naturally occurs in open-source systems which mitigates an otherwise key project risk

Control [closed]

• The development team are located in close geographic proximity as face-to-face requirements events are necessary to shape and define the project. This will result in a more closely bonding team than you would see in open-source and offers a more friendly community dimension
• The code falls under copyright and remains proprietary until such time as network effects have led to market dominance

It is my plan at this time that the platform code will eventually go fully open-source whether this succeeds or fails as a project. Eric Raymond’s discriminators that push towards open source are all there for this project. The reason not to do so at this stage is that for open source to work one of the key rules is:

It’s fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. Your nascent developer community needs to have something runnable and testable to play with.
Cathedral & Bazaar

From the time the prototype is up-and-running the decision on when and how to go fully open source will be on the table.

The term copen source also has a nice tie in with our location of course —- Copenhagen

Coming soon —– high-level plan, launch of the recruitment campaign