It occurs to me that in this whole debate over angels and VCs, there is an important third option that is missing from the table and I have been referring to it colloquially as "Social Network Offering", or SNO.

The idea is that instead of raising money directly from an angel investor or a professional venture capitalist, you raise money through a network of friends, acquaintances and contacts in the industry.

The startup to-be creates a prospectus with some basic information like the business they are in, the execution plan, and the capital requirements to go from startup to profitability, acquisition or another exit strategy.

So far, that is not any different than any other financing option available for a startup. The difference is how the share holders are invited into this process. Instead of being a closed door event where the angel or the vc sets the terms, the founders of the company set the terms for the investment as well as the initial round of capital that they are trying to raise and offer this to the social network.

The Social Network Offering round would be setup through an escrow system that would give different investors a chance to participate in the first round of finacing, and if enough startup capital is raised in this phase, the money is given to the company and shares are distributed to the investors. If the startup fails to raise enough capital, the money is returned to the investors.

Social Network Offerings are transparent in nature. They would not work well if you are trying to create something in secret, something that nobody has ever heard of, since you would need a level of secrecy for this to work. But it would work great for business built around open-core, or business where the strategy is to do it better than existing offerings.

Balance

If you have a social network of friends that can help you raise this kind of cash, the advantages are:

• Your social network knows you better than a new VC firm or an angel.
• Individuals that have historically not had a channel to invest in startups, get a chance to participate. This is fairly unique.
• Easier to keep the company vision intact.

There are also some downsides to go with Social Funding: VCs can help you get a seasoned executive team in place, they assist you by filling the gaps during the early stages of the company, they let you tap into their network of companies and resources and they will not hesitate to course-correct any ideological problems that do not necessarily blend well with becoming profitable.

What is your take?

If you had a chance to invest on a high-tech startup, how much of your own money would you be willing to put up-front for something like this?

Fill my survey here.

Update: On twitter, @eoinh pointed out that one company already did something like this. They used Linked-In to raise 350,000 dollars through their contacts, and found matching funds from the government raising the total to 700,000.

The IronPython and IronRuby languages are now under the "IronLanguages" umbrella and are being maintained using GitHub's Organization support.

Tomas has also created an organization for F#, it currently hosts the MonoDevelop F# Add-In, and we are going to maintain there F#'s changes that we make in the open source world to get it tuned for Linux and OSX.

Tomas Petricek has announced the availability of the F# MonoDevelop Add-In.

The add-in provides intellisense for MonoDevelop, inline documentation and access to the F# interactive shell. Most of the heavy lifting is done by the F# compiler itself which is used directly by the Add-In as a service:

His blog also has screencasts on getting F# and the F# add-in installed on Linux and also shows how to create Gtk# applications with F#:

Check his blog for more details.

Ruben has announced that FOSDEM 2011 was kind enough to host a Mono Developer Room at next year's conference.

Ruben is organizing the talks, if you want to present, please submit a proposal for a presentation.

There are plenty of topics to discuss: Gtk# and the Gnome desktop; MonoDevelop and MonoDevelop add-ins; Mono Runtime; Languages: Iron*, UnityScript, C# 4, F#; Server programming with Manos or ASP.NET.

Paolo has checked into Mono's GIT repository our brand-new profiler for Mono applications.

The new profiler is documented in detail here, and is available with Mono 2.9+ (this means: it is available if you build Mono from GIT, and will be part of the upcoming 2.10 release).

We would love to hear your feedback on it, and we hope to have a UI integrated into MonoDevelop soon.

Update: This is what one of the reports of the new profiler can produce, this is taken from running an ASP.NET application (a question that came up a few days ago on IRC):

       Heap shot 5 at 14.518 secs: size: 43684432, object count: 562907, class count: 543
            Bytes      Count  Average Class name
         10506984      87373      120 System.Collections.Hashtable.Slot[] (bytes: +1939272, count: +16161)
               87346 references from: System.Collections.Hashtable
          8130304      87486       92 System.Int32[] (bytes: +1706912, count: +16164)
               87346 references from: System.Collections.Hashtable
               40 references from: System.Collections.Generic.Dictionary
               30 references from: System.Globalization.NumberFormatInfo
          6846000      57050      120 System.Web.Caching.CacheItem (bytes: +1232880, count: +10274)
          4891432      87347       56 System.Collections.Hashtable (bytes: +904176, count: +16146)
               28526 references from: System.Web.HttpStaticObjectsCollection
               28525 references from: System.Threading.ReaderWriterLock
               28524 references from: System.Web.SessionState.SessionStateItemCollection
          1597344      28524       56 System.Web.SessionState.InProcSessionItem (bytes: +287672, count: +5137)
               28524 references from: System.Web.Caching.CacheItem
          1597344      28524       56 System.Web.SessionState.SessionStateItemCollection (bytes: +287616, count: +5136)
               28524 references from: System.Web.SessionState.InProcSessionItem

	This heapshot was taken 14.518 seconds after application startup, at the
	time there were 562907 objects in the heap, of 543 different types,
	using about 43 MB of memory.
	

Last week, Don Syme announced that Microsoft has open sourced the F# compiler and the F# core libraries under the Apache 2 license.

In addition, on Tuesday, Don also announced a new release that fixes a handful of bugs specifically for users targeting Mono.

F# is a fascinating language, but I had not really spent much time with it as we could not really distribute it as an open source compiler limiting its usefulness in the Linux and Mac worlds. Now F# can become just another language that developers can use.

F# supports asynchronous programming today, and it was the inspiration for C# 5.0's async support. There is no need to wait for C# 5 to come out, you can start using async workflows today with F# everywhere.

MonoDevelop plugin

At the F# in Education workshop Tomas Petricek announced his MonoDevelop add-in for F#. Although he has not released a binary add-in, the source code to his plugin is available here. It provides intellisense, parameter documentation, on-the-flight error underlying and support for the F# interactive shell from the IDE.

Distributing F#

Our plan is to distribute F# as part of Mono for both OSX and Linux. This will take some time, in the meantime, check fsxplat.codeplex.com for instructions on how to get started with F# on MacOS and Linux.

It will likely run out of the box on Mono/Android and Mono/Wii. Since F# uses generics extensively, we do not know if it can be used to target the iPhone or the PS3 as both require Mono's full static compiler. We will be evaluating this in the coming weeks.

Don, minutes after open sourcing F# enjoying a tasty meal.

F# Resources

These resources are straight from Don's blog:

• F# 2.0 Language Specification
• F# Development Center
• Interview with Don Syme on F#, C#, Haskell and Scala.
• Sources for the compiler and libraries are in the "compiler" module at the F# PowerPack site.

If you are attending PDC or at Microsoft and love Mono, .NET, Open Source, Linux, MacOS, iPhone, Silverlight, Android or WP7 and want to hang out, discuss, or debate the finer points of trollcats in contemporary society, drop me an email at [email protected].

Alternatively, we can also indulge in some Java-driven schadenfreude or debate whether chubby pixels are worth staring at.

I will be in Redmond from Tuesday afternoon until Friday night.

Yesterday, Jason Zander announced that the maintenance and future development of IronRuby and IronPython languages was being turned over to the Iron* communities.

Microsoft reached out to some of the users of the Iron languages to take over the coordination for these projects. Together with JB Evain, Michael Foord, Jeff Hardy and Jimmy Schementi I agreed to help coordinate the future development of these languages. The Iron* community reaction to the opening of the process has been very supportive judging by the emails on the mailing list and the twitter responses.

There are four pieces of code involved, all licensed under the Apache 2.0 license:

• The IronPython Python implementation
• The IronRuby Ruby implementation
• The Iron Python Tools for Visual Studio
• The IronRuby Tools for Visual Studio. This one is a new source code drop.

Both IronPython and IronRuby will be developed like other open source projects without any of the limitations that previously existed. In particular, from my very Unix-centric view, we will be able to get the proper fixes into the Iron* languages to make them work out of the box on Linux and MacOS.

Our Contributions

Although we will help with the coordination efforts in the Iron languages as the community grows and evolves, we have some concrete tasks that we will be working towards right away:

• Ensure that the Iron* languages build and work out of the box on Linux, MacOS and Unix.
• Use Mono's Continuous build system to keep an eye on any regressions on IronRuby and IronPython.
• Package the latest IronRuby and IronPython for Linux and MacOS.

Opportunities

Ruby and Python make programmers happy. They bring joy and smiles to programmers everywhere in the Unix world. Both have strong user bases on Linux and MacOS and there is a strong ecosystem of independent implementations for both Ruby and Python, each with their unique features.

In Iron's case the major feature is being able to use your scripting language of choice while having access to all Mono APIs for building standalone applications or for extending existing applications like MonoDevelop, F-Spot, Banshee, SparkleShare and Tomboy.

From my Unix-biased standpoint, this means that all of the libraries that we have been working on over the years from Gtk# for building desktop Gnome apps, to MonoMac for creating native Mac applications with the entire universe of .NET libraries at your disposal.

The Iron* languages, combined with our MonoMac will make an appealing platform for building apps for the Mac AppStore.

Another fascinating project is the Pyjama Educational Project. Pyjama is written in IronPython, Gtk#, and GtkSourceView and currently supports 5 DLR languages.

Teaser

As the announcement came out last night, Geoff Norton cooked this simple teaser of IronRuby on the iPhone.

Check it out here.

Microsoft has three big tasks ahead of itself: (a) make Azure successful; (b) make Windows Phone 7 successful; (c) keep the existing Windows and Office businesses printing money.

There is probably not a lot of political support at this point to embark on more large-scale innovations at Microsoft while there are probably hundreds of smaller innovations that are waiting under all of their product groups.

Ray Ozzie incubated a number of projects like Azure and Mesh at Microsoft that once they reached a level of usefulness were transferred to the product groups.

He is probably leaving his position as Chief Architect at Microsoft as he transfers the Azure assets to the product group and he is once again left as a general without an Army. Starting new project and recruiting teams from scratch for new products has probably taken a toll on him and he is ready to move on.

Missed Opportunities

Back in June I blogged about what I would do if I was in charge of Windows 8: among other things, I would have created a Windows AppStore.

This AppStore would have helped independent ISVs tremendously by opening the entire Windows user base as potential customer for Microsoft's products. It would have helped Microsoft make Windows even more relevant, and it would have done more to push native applications on Windows than anything else they have tried in the past.

The Windows PC market is a market that is many times larger than today's iPhone market. It would have been a gold mine, and there would have been a renewed gold rush to ship "Windows AppStore-ready" applications for Windows.

Hundreds of people at Microsoft must have had this idea, the question is why it never bubbled up to the top?

Short of a Microsoft-powered AppStore, Intel has announced that their Windows Appstore will now include .NET software.

On the one hand, Intel has now given up any attempts to make their AppStore be a cross-platform app-store, which I felt was a gracious thing for them to do, as it would have helped Linux.

Financially, having a strong Windows-based appstore was probably the right thing to do for Intel. There was really no point in Intel undermining his own efforts by forcing people to use cross platform tools in the first place.

If Microsoft was the one providing the AppStore, they would be reaching a much bigger market than what Intel hopes to reach.

This could have been a great Ray-Ozzie level hack to pull at Microsoft. In the meantime, Apple today announced an AppStore, and they are going to get a bucket of apps and a bucket of developers to push software on their platform.

Live Mesh

Live Mesh had a lot of promise, but sadly, the groups working on it refused to open up the specs on time, and the product became fairly uninteresting over time.

If you are going to open something for the world to see, you should be ready to let the world interoperate with it from the start. Otherwise you merely give your competitors the good ideas, and they throw away your bad ideas and avoid paying any of your strategy taxes.

Happy days at Mono Central. Just a few months ago we decided that we should apply the lessons learned from MonoTouch to Mono on the Mac and we built a new set of .NET APIs for developing native Mac applications. We called this MonoMac.

We recently brought tears of joy to developers by shipping it.

MonoMac will be a great tool to build native Mac application using your favorite .NET programming language.

We clearly have to take this to the next step as MonoMac is merely a binding to .NET. We are going to have to extend MonoDevelop to create fully self-contained applications that embed both your application, any library dependencies that it needs as well as the Mono runtime.

The above really had not been my priority, as far as I was concerned "Download Mono and Install it" was a perfectly suitable solution. So you have Apple to thank for my change of heart.

Hopefully we will have an experience as smooth as the MonoTouch experience has been.