Wrapping things up with a call for partners

After almost a year of hard work, i eventually realized that the P2P OS project is facing some very serious threats which i just don't feel capable of negotiating all by myself, so i decided to wrap things up with this "Call for partners" post. In a nutshell, here's a super-condensed list of the key things that might be of interest for a potential partner to this project:

• what i managed to do so far is to build a proff-of-concept skype alternative; in fact, the P2P OS networking algorithm has been deigned to allow for a much more robust P2P network than skype's, in the sense that while skype requires a large number of computers with direct internet connection (i.e. public IP or single-router UPnP) in order to support its network (about one such computer for ~100 registered users), P2P OS does not have any such restrictions (i.e. the P2P OS network is self-supporting even if all the computers in the network are running behind routers and/or firewalls).
• i believe this project can become a skype killer because of some key differentiators: it's open-source, it's not collecting any user data, and it consequently can be deployed (and replace skype) in corporate environments
• important: this project is intended to be released under some form of open source license primarily for allowing code inspection and for making it free for home users; however, the program can be released under a dual license, with a commercial license for business users
• i believe money can be made from this project if it is finalized, e.g. by monetizing it as a product (this can be particularly interesting for companies wishing to host their own private network), building services around it (there's a rather large set of options here, including per-user subscriptions for guaranteed uptime), third-party apps advertising on the P2P OS home page (sort of a marketplace, but only for hosting the apps' ads, i.e. without actually hosting the apps themselves), advertized sponsorships, etc, and of course, as a last resort, selling the project copyrights (potential buyers include open source-based and open source-firendly companies).

However, there are at least two major issues with this project and, as far as i can see, with any P2P-based application that someone would want to develop these days, and these two issues are also the sole reason for which i decided to put this project on hold:

• catch 1: the current version of P2P OS has been designed to circumvent the P2P connectivity issues specific to IPv4 in a NAT-based home network environment, but it does not implement provisions for supporting carrier-grade NAT (CGN), and, more importantly, porting the project to IPv6 might not be feasible at all. More specifically, whether any P2P application will be possible on the next-generation IPv6 networks depends on how IPv6 residential gateway devices (RG) will be implemented, and i can't find any way to guestimate, let alone negotiate, this threat because of the very large numbers of factors involved (e.g. whether the high-profile internet companies such as MS, google, or yahoo will lobby for P2P support or not, whether the large ISPs will consider P2P connectivity as being important to the end users or not, whether the present-day high-profile P2P applications such as skype or yahoo will keep their current P2P model or they will transition to a relays-only model - said applications already use relays whenever one user is on a 3G network, etc)
• catch 2: when i started this project i assumed an OS landscape that will allow easy porting and deployment via Qt on all three major desktop OSes Windows, OS X, Linux, plus on at least two major mobile OSes Android and Nokia's MeeGo. However, things have changed dramatically in the sense that (1) porting to the new Windows 8 mobile will be a tough nut to crack (to say the least) because of the limited WinRT API it offers by sandboxing the applications, (2) Nokia abandoned its efforts with MeeGo (so no Nokia port), and (3) Qt has been spun-off (read: all-but-abandoned) by Nokia such that the future of an Android port is uncertain at best; additionally, my paranoid view on the course of MS' and Apple's market strategies suggests that there is a real danger for Windows Phone/Tablet OS and iOS ports to be prohibited by these two OSes. To rise, Qt will probably still be a usable tool for porting P2P OS to the future versions of Windows Desktop, OS X, and Linux for the nest 5 years or so (i.e. porting to these OSes should be fairly easy), but the mobile and tablet ports might prove to be mission impossible.

Keeping the above in mind, should anybody be interested in learning more details about this project and its associated risks should it be continued, please drop me a line.

Update
As i gather more info on the current trends in CGN deployments (reading some articles e.g. from CISCO and Juniper on this topic and talking to industry insiders), adding full CGN support to P2P OS (or any other P2P application for that matter) increasingly seems technically impossible because of the algorithms that ISPs are enabling on their CGNs (namely, most ISPs seem to opt for what it's called EDM - endpoint dependent mapping, which maximizes the reuse of the CGN ports but breaks P2P), such that an IPv4-only P2P OS implementation will probably be impossible for the coming years when CGNs will be the IPv4 connectivity norm for the end user.

A glimmer of hope (but not much more)

Don't want to let this blog end (or just hibernate, time will tell) on that all's doom and gloom note of the previous post, so i'll add this: there still is a slim chance for the internet to go back to its roots, i.e. with everybody having a direct IP connection, and this slim chance comes from IPv6. However, the reason i call IPv6 just a slim chance is that although IPv6 can bring back "the internet of peers" to the world, the ISPs (and, to a lesser extent, the various router vendors) can still f* this up e.g. by deciding to install default firewalls inside their residential gateway devices, in which case your average Joe will still not be able to set up his router to accept incoming connections. And no incoming connections means no P2P. And no P2P means no internet.

As i said in the previous post, at this point in time i'm incapable of assessing whether the internet is dying, or it's headed towards a rebirth (via IPv6), or whatever else, so for the time being i'll just wait. The only thing that i can think of possibly doing at this point is to somehow start an awareness campaign for including "you need to have an unrestricted public IP" in the very definition of "internet connection"; any other type of connection should simply not be called "internet connection". Maybe i'll make a clip on youtube about this if/when i'll find the time and energy to do it...

Update
Apparently i'm not alone in my paranoia: www.isoc.org/tools/blogs/scenarios

Signing off, very likely permanently

There is some good news, some bad news, and a killer (or maybe just artificially-induced coma - this remains to be seen) conclusion.

The good news:
There seems to be a way of shouldering one billion users on a P2P network with just some $1,000/mo central server traffic: it's called Kademlia (seminal article, wikipedia, search). Kademlia essentially creates an overlay network of micro-servers which, in turn, sustain the rest of the network users, while a central server is only used to log on to the network. But there's a catch: in order to distribute micro-server services over a P2P network there have to be at least ~1% of the participating peers that can act as micro-servers, i.e. they must:

1. be directly connected to the internet (i.e. they are not behind a NAT or firewall)
2. have relatively stable connections, i.e. they should stay connected tens of minutes after they completed a network operation (e.g. a chat session, a file transfer, etc)

Both of the above conditions are easily met in today's internet topology: (1) is achieved by any peer that has maximum one router and the router is UPnP-enabled, and (2) is achievable by having the P2P application remain running in the background for a certain amount of time after a specific p2p session ends, or by making the sessions themselves last a relatively long time. BTW, the most successful p2p applications currently available - Skype and BitTorrent - both do their best to enforce the above two conditions upon all the nodes on which it they are installed (by remaining online even after you click their 'close' button, and by turning on UPnP by default).

The bad news:
In brief, the bad news is that the good news don't do me much good. Because:

• a) i no longer trust that (1) will be maintained in the future. People increasingly install cascaded routers in their homes, and UPnP does not give any signs whatsoever that it is willing to address this issue (i.e. make a computer directly accessible on the internet when connected through cascaded routers). Furthermore, ISPs can deploy new methods of preventing p2p applications from running at any time (and i don't mean filters, but rather generic methods such as CGNs and firewalls, and i really don't think this is very far fetched)
• b) the new mobile communications paradigm will become an increasingly significant burden that a depleting pool of directly-connected peers will have to deal with (because mobile data plans are always offered through operator NATs - but, even if they weren't, a mobile peer can't be used a a server because of mobile traffic costs). And BTW, i have this feeling that one of the main reasons for which skype was sold was the realization that the pool of "supernodes" (skype's terminology for shamelessly using people's bandwidth and making $8 billions out of this scheme) is depleting and some big-pockets company will eventually need to step in and shoulder the network with dedicated servers of their own (sure, that's just a hunch, but it will be interesting to see if/when that "use UPnP" checkbox will go away from skype's connection settings, cause that'd pretty much say that skype fully transitioned to in-house supernodes)
  
  Update
  It happened: arstechnica.com/business/news/2012/05/skype-replaces-p2p-supernodes-with-linux-boxes-hosted-by-microsoft.ars (and never mind the M$ lady's reply, it's damage control nonsense)

My killer conclusion:
At this point in time i'm incapable of evaluating just how serious the above challenges (1) & (2) are, let alone other unforeseen issues that might creep in; and since implementing Kademlia would require anywhere from 6 moths to one year of hard work, i'm just not ready to plunge into such an effort alone and empty-handed.

So i stop. Very likely for good.

Roadblock

Mea culpa for not updating this blog in quite a while, but it's not because i slowed down work on it, but rather, much worse, i've hit a roadblock which is pretty darn serious. In brief, when trying to write the algorithm that would enable a p2pOS client to act as a relay for its plugins (i.e. to "connect the crossed red lines" that i talked about in a previous post), i also had to try to define the low-level API that the plugins will be using to connect to one another (by means of their associated p2pOS clients that will be acting as the relays, one relay at each end of a P2P connection). And as one thing led to another, i eventually reached the conclusion that what i need to do first is to establish exactly how a peer joins the network and connects to another peer. And this is where things got really, really ugly.

Without entering into too many technical details, the important point here is that in order to have two peers connect to each other, they have to go through an initial "handshaking phase" during which the two peers learn some essential things about one another (e.g. their IP addresses, what kind of router(s)/firewall(s) they are behind, etc), and this handshaking phase has to be negotiated through a dedicated handshaking server. Well,  i can try to hide behind all sorts of technical arguments, but that fact of the matter is that ever since i started this project i never tried to calculate exactly how much traffic such a central handshaking server would require for a large P2P network (i'm talking about 100,000,000...1,000,000,000 users being online), only to find out now that the numbers are astronomical: namely, we're talking about thousands, or even tens of thousands, of terrabytes/month, which translates into a handshaking server operating cost somewhere in the hundreds of thousand, maybe millions, of dollars a month. This in turn means that hosting such a server is not something that just about any punk can do in his basement, which in turn means a large company would be required to finance the network operation. Or, in layman's terms: the network can never be truly open, no matter what license will be covering this project, no matter what verbal commitments a company would make, etc. And since the (maybe only) non-negotiable objective of this project is to create a truly open P2P platform, well... you guessed it: i'm stuck.

But, as i said at the beginning of this post, all this mess doesn't mean i gave up on the project; in fact, because it seems increasingly likely that some sort of distributed handshaking algorithm will be necessary, i made quite a few tweaks in the program in order to reduce the traffic between connected peers (e.g. i managed to reduce the P2P keep-alive traffic by about an order of magnitude by detecting the peers' routers' port timeouts and only send keep-alive messages at the required rate), i refined the router classes such that over 90% of the routers models can now act as relays, and i introduced an algorithm that detects if a peer is directly connected to the internet (i.e. public IP or UPnP) such that it can serve as handshaking server in the network. This is how the new "Settings" panel looks like now:

So what i'm doing right now is study what other smart-@$$ P2P projects have done (e.g. Gnutella, Freenet, etc), i'm trying to learn about various DHT approaches (there's a very nice tutorial talking about the basics here), etc, and i'll see if i'll be able to come up with a solution. Keep ya fingers crossed for me, it's in the world's best interest and sh*t :)

PS
Here's how a p2pOS-based P2P session is established through NAT routers with the help of a handshaking server: the blue messages are P2P messages, while the green messages are relayed via the handshaking server (once the handshaking phase is completed, all messages from one peer go directly to the other, i.e. they are P2P messages):

Pirates invade Berlin

The German wing of The Pirate Party just got a few comfy seats in the Berlin state parliament. While the news will sound exciting in and of itself for grass-root movements supporters and ideologists, maybe even more significant would be to mention here that such a development could only happen in (some sort of) a proportional representation democracy, i.e. forget about first taking Manhattan and then taking Berlin, that will never work, but the other way around...

Interesting times ahead or just another protest vote? Time will tell.

Integrating plugins: stage 1

Took a lil' bit longer than i expected (those "little things", you know), but the main p2pOS application now reads the plugin list from a 'plugins' sub-directory and can start plugins.

Essentially, a p2pOS plugin is an application that runs on a client computer (i.e. alongside the main p2pOS application) and which implements a localhost sockets-based communication protocol which allows it to connect to the p2pOS main application (said communication protocol specification is part of the p2pOS API). Thus, because the only requirement for a p2pOS plugin is to implement a sockets-based communication protocol, a plugin can be written in any programming language which provides sockets access, including interpreted languages e.g. python, or tcl/tk, etc.

As the title of this post says, it's only the first stage of the plugin framework that's been implemented so far (specifically having p2pOS detect and run plugins), or, in other words, this is how things look like now:

The next step is to implement the crossed thicK red line(s) in the image below:

So basically, once the crossed-red-lines above will be implemented, a plugin will be able to communicate with another [remote] plugin by tunneling its messages through a p2pOS-managed p2p connection, which in terms of nuts and bolts means something like this:

Finally, because i love screenshots, here's the p2pOS main application starting a plugin...

...and then stopping it:

Multiple connections are now supported

The P2P network manager now fully supports multiple connections. The image below shows three P2PCommunicator instances running, with user 'a' logging on in the bottom-right window, and users 'b' and 'c' logging on in the other two P2PCommunicator windows; in this setup, the following actions occur (in the listed order):

1. user 'a' connects to user 'b'
2. user 'a' connects to user 'c': user 'a' is now connected to both 'b' and 'c'
3. user 'a' sends the message "message from a to b" to user 'b' (i.e. this message is typed in user 'a's window and it appears in user 'b's window)
4. user 'a' sends the message "message from a to c" to user 'c' (i.e. this message is typed in user 'a's window and it appears in user 'c's window)
5. user 'b' sends the reply "message from b to a" to user 'a' (i.e. this reply message is typed in user 'b's window and it appears in user 'a's window) 
6. user 'c' sends the reply "message from c to a" to user 'a' (i.e. this reply message is typed in user 'c's window and it appears in user 'a's window)

So the image above shows one user ('a') connected with two other users ('b' and 'c'); now here's how things look like with three peers ('a', 'b', and 'c') all connected to each other:

Together with implementing multiple-connection support, the old disconnect algorithm (which was designed for a single-connection environment) had to be re-written, and it now fully supports multiple connections (btw, properly managing disconnects is no simple feat, took me about a week just to figure out how to do it).

The next two major milestones for the client-side algorithm are:

1. implement the plugins architecture (i.e. allow third-party applications running on separate computers to connect to each other using the P2P network as managed by P2P OS); this is no simple thing as it requires defining a P2P direct-link frame structure which should be tunneled by P2P OS, and then implementing a 'DirectP2P' API that will support said frame structure (so this will most likely be a multi-stage task that will keep me busy for several weeks)
2. allow relay-based connections between two Non-BEHAVE peers (currently a Non-BEHAVE client can only connect to a BEHAVE-compliant client); i expect relay-based connections to be the last major client-side algorithm update, but you never know...

PS

Just for the fun of it, here's a sample of what i was struggling with late last night:

Phew!...

Freedom with a twist: micro-states

This is an idea sitting dormant at the back of my mind ever since i started this P2P OS project (well, should i ever be able to make any real money out of it :p): http://www.washingtonpost.com/blogs/blogpost/post/peter-thiel-founder-of-paypal-invests-124-million-to-create-floating-micro-countries/2011/08/17/gIQA88AhLJ_blog.html

PS
Just to make things clear from my personal opinions' point of view: when i say "this is an idea sitting dormant at the back of my mind" i mean the independent [micro-]states idea, but i don't have any specific form of government/society in mind just yet. My reasoning behind the micro-states idea is to allow people to build and trade things inside a small-business-friendly legislation, but i can hardly see any appeal for someone in her right minds to actually be living on a boat somewhere in the middle of the ocean.

A few words on privacy

Just stumbled upon an article discussing skype's alleged security and how it was built into skype from day one (as opposed to being an afterthought), and felt like throwing my 2 cents on this.

For some bizarre reason, it is commonly thought that a skype p2p link offers anything and everything that can translate to "ultimate privacy" and some more, but this is... anything but. Here's the drill:

1. privacy has two major components, the first of which is protecting your communication from potential eavesdroppers. On this front, skype praises itself with unbeatable encryption, which is technically true, but what skype omits to say is that a good encryption only servers to protect a link that already exists; in other words, if you talk to someone and wish to know that your communication is shielded from eavesdropping, then skype might be the real thing. However, what skype does not, and cannot, guarantee, is that you are indeed talking to the person you think you are: specifically, when you set up your communication link with your peer, the link setup stage is vulnerable to what is called a "man in the middle attack" which essentially means that someone has just placed a listening device between you and your peer, and everything that you'll be talking with your peer will in effect go through said man-in-the-middle eavesdropper. In the security world, this is called "the authentication problem" (i.e. making sure that what you're so carefully whispering to your peer indeed goes to your peer and not to someone else), and this is the hardest part (and philosophically unsolvable in the absence of a trusted third-party authority which knows you both) of the secure communications problem.
• note: without entering into too many technical details, it may be technically true that skype itself cannot eavesdrop on your communication by having one of its engineers flip some switches at their headquarters, but what skype does not explicitly say is that what it can do if it so wishes (or is legally forced) is to provide third parties with a technical equipment (i.e. a piece of skype-certified software) that can eavesdrop on any communication whatsoever if some conditions are met (e.g. if this eavesdropping software is placed on your ISP's routers then there is absolutely no problem whatsoever to wiretap your communications)
2. the second big issue related to communication privacy is whether or not a third-party can know who you're talking to, even if it won't be able to actually listen into your conversation. On this front, skype not only does not offer any protection, but its algorithms actually don't even make any effort whatsoever in this direction (e.g. along the line of Tor and the likes); in other words, there are absolutely no provisions in skype to even attempt to address the issue of protecting the identities of the two ends of a skype link.

To rise, none of the two fundamental attributes that could together label a communication link as "private" are present in skype, and while the "skype is encrypted" mantra is technically true, this mantra is blown out of proportions in terms of communication privacy.

P2P OS is different. I will not say much about the cornerstones (or implementation details) of P2P OS' security framework at this stage, but i will just say that it addresses both of the privacy issues described above, and it will [attempt to] provide the highest level of communication privacy that is philosophically achievable within the technical limitations of a given digital communications equipment.


Later edit
As i said in the post above, i don't want to get [too] technical here, but in light of some new developments i'll just mention that the cornerstone of skype's security model (and just about any security model out there for that matter) are the security certificates, and if a bunch of geeks can do things like this just imagine what a more potent attacker can do. And don't take my word on this, just look at what they say.
Needless to say (since i'm hereby flaming this model), P2P OS will not use this model.

Project status in a nutshell

The current client algorithm can log on to a server when it runs behind just about any type of home modem/router, with the notable exception of some 3G connections which purposefully use port-hopping algorithms in an attempt to make persistent P2P connections impossible (a partial solution to this problem exists, but implementing it is very low on my priority list).

In terms of connectivity, a client can currently connect to another client directly (i.e. P2P, without any relays) if at least one of the client's connections is BEHAVE-compliant; specifically, if both connections are BEHAVE-compliant, then the connection is quasi-instantaneous, while if one of the clients uses a Non-BEHAVE connection then the BEHAVE client will perform a port-scan on the Non-BEHAVE client and will find the P2P connection port.

The image below shows a simulation of a BEHAVE-to-Non-BEHAVE P2P connection.

• note: in order to simulate the BEHAVE-to-Non-BEHAVE connection, the automatically-detected connection settings on the clients had to be manually overridden, and this is the reason for the warnings in the clients' main windows.

Currently a client can only have one active P2P connection, i.e. a client cannot connect to two (or more) other clients simultaneously. Eliminating this limitation is the next planned milestone.

On the server side, the current server algorithm is very basic and only aims at supplying the clients with the information required for them to establish a P2P connection. The identity-related functionality (e.g. user registration, login authentication, etc) as well as any other advanced features (e.g. server-side contact lists, offline message buffers, third-party services integration API, etc) are not implemented, but the server software framework has been designed with these functionalities (as well as expandability) in mind from day one, such that incorporating new features (when the time comes) should be rather straight-forward.

Logging in

The mess inside...

And yeah, it actually works...

Okay, this was the easy part. Now back to work!

Skype is worth a cool $8 billion. In cash.

Well, at least in Microsoft's eyes:
http://www.engadget.com/2011/05/10/microsofts-acquisition-of-skype-for-8-5-billion-becomes-offici/
The only problem now is how long until skype on linux will be history.

Multimedia for world+dog

Google might have its issues and there are definitely quite a few haters out there, but it's still one of the very few large-scale corporations with a fair share of good deeds, the latest of which being the open-sourcing of the VP8 video codec as part of the WebM project. What this means for the garage-based developer (like me) is that anyone can now build top-notch multi-media applications "that just work", without needing to dive into that funky world of cosine transforms and the like. As far as the P2P OS project is concerned, this is heavenly-sent.

A glimpse of my desktop

Making progress (you can get an idea of the size of the project by looking at the scroll bar thumb's size and position), but it's painstakingly slow...

A web browser for world+dog

Just found out that WebKit is an integral part of Qt, which essentially means that your average Joe Programmer can embed an HTML5-based GUI in his applications as easy as pie; to me this was huge news. But who in their right minds will bet on Qt after Nokia shook hands with MS and all but abandoned Qt, and there's only one big name left out there - SuSe with the KDE Desktop - actually relying on Qt (but with an option to abandon ship at any time and jump on GTK, wxWidgets, or any of a few others to chose from). Unless a big name (Google?) comes to the rescue...

Another one bytes the dust

I really didn't see this coming: www.itworld.com/open-source/136873/qts-future-bigger-nokia
Qt was the only professional free-software cross-platform C++ development kit out there, supported by a big name with a big promise. So now what?

Some business ideas

As i stated in the first post of this blog, one of the main objectives of P2P OS is to have it released as an open source product, and, furthermore, the underpinning P2P protocol should also be released as an open specification. While keeping within the constraints of these self-imposed bounds, this post gathers some business ideas that i thought of, and which could add a business case perspective to the P2P OS project.

• note: by its very nature this page is a perpetual work in progress as it has to reflect the up-to-date technological and business environment, and i'll keep adding/editing/removing ideas as they come and go; feel free to jump right in with any suggestions/criticism/etc that you may have

For starters, several important things that need to be mentioned at this point:

• first, "open source" does not mean free, neither as in "free beer" nor as in "free speech". Although a common perception is that open source software must necessarily be free software all the way (i.e. both as in "free beer" and as in "free speech"), the truth of the matter is that "open source" literally only means that the source code of the application is open for inspection to anyone who'd like to peek into the code. In other words, releasing a piece of software as open source simply means that anyone is allowed to inspect the inner working of said software, with the main benefit being to allow the potential users to check for themselves the claims that the software makes for itself.
• second, keeping in mind that P2P OS is, at its core, an application server (specifically, it provides P2P connectivity services to third-party applications), an important technical detail for the business perspective is that the P2P OS API is based on sockets communications, with P2P OS always running as a background service in parallel with any P2P OS-based application (i.e. as a separate process or thread).
• third, it is important to keep in mind that P2P OS is intended as the foundation for an application ecosystem which creates its own self-supporting network(s), such that P2P OS-based applications (e.g. collaboration platforms, social networks, etc) will barely require any centralized infrastructure, may that me technical, financial, or of some other form, for their operation.
• last but not least, there's a new kid on the block starting to flex its muscles, namely the WebRTC project. WebRTC was little more than a mere statement of intent two years ago when the P2P OS project has been started, but it has made some significant progress during the past two years and it currently looks like a serious potential competitor to P2P OS should it evolve into a truly free and open generic P2P technology (which is not the case in its current incarnation).

Now a few words about what i have in mind w/r to how P2P OS can be introduced on the market in a three-stage licensing approach:

1. in the first stage, start by releasing P2P OS as a multi-platform executable only (i.e. closed source), while also making a promise that it will be released as open source after a certain period of time (about 1 year); this first stage will essentially allow P2P OS to penetrate the market, mainly with the help of early adopters
2. in a second stage, release P2P OS as open source such that the code can be freely inspected, but do not release it as free software yet; instead, specify in the license itself that the code will [automatically] transition to free software status at a well-defined date (specified in the license); this stage should span several years, and it will be used to accomplish two main objectives:
• provide the opportunity to increase market awareness and, based on the availability of the code as open source, establish P2P OS as a trusted brand
• evaluate new business ideas/opportunities, and possibly initiate projects around them
3. finally, release P2P OS as free software under GPL or a similar license. The choice of an "infecting" viral license (like GPL, but not LGLP) is critical for allowing the development and marketing of commercial variants of the product, in parallel with the free software variant

Finally, some business ideas that crossed my mind until now:

Dual-license
This business model is based on releasing the software under dual license, GPL and a commercial license: specifically, a commercial license option can be added (in parallel with the free-software license described in the three-stage licensing model), such that application developers can purchase and embed P2P OS in their own closed source application for a fee (a one time fee, or royalty, etc).
The main idea here is that while closed-source P2P OS-based applications can be released (i.e. under a proprietary license) even in conjunction with a GPLed version of P2P OS, said close-source applications will require the presence of P2P OS as a separate service that must be run alongside the application (think of P2P OS as an independent "system tray" application that must be started for the application to run), i.e. the applications that will use the GPLed version cannot be self-contained (this restriction results from the viral nature of GPL which disallows embedding GPLed software into a close-source app). In contrast, the applications that will use the commercial license version of P2P OS will be allowed to embed [a binary library version of] P2P OS inside the applications themselves, thus enabling the creation of commercial stand-alone products.

App directory
Okay, this idea might be a bit far-fetched, but i'll write it down none-the-less: based on the fact that P2P OS is an Operating System, i.e. it is a software module that serves third-party applications, maybe a business can be made around an application directory, similar to the application store model of iOS or Android, except that the app directory will only list applications for a fee, without attempting to own/control a complete e-commerce solution (i.e. the app directory would act as a one-stop-shopping advertisement platform, directly and prominently linked from P2P OS' main website). Additionally, a number of derived businesses can also be imagined around the app directory, e.g. subcontracting application reviewers (which will themselves be subject to user rankings), etc.

Application development
The two business model ideas described above (application store and dual-licensing) are both based on using P2P OS itself for generating a revenue stream, but a business model can also be built by expanding into in-house development, and marketing, of closed-source P2P OS-based end-user applications that can be released under different licensing terms for different platforms. For example, a full-fledged P2P Communicator solution can be developed in-house and released for free (like in "free beer", but closed source) for Win/Mac/Linux, while mobile platforms variants can be sold for a fee (Android and BlackBerry 10 are prime candidates here). Should such in-house applications manage to attain high quality standards and address real market needs, they will be able to rip the benefits resulting from P2P OS' reputation as an established and trusted brand.

• "Pro" connectivity services
  as explained in the P2P networking post, the P2P application server's functionality heavily depends on the reliability of an underlying network of relaying-capable nodes, and said network of nodes is inherently not [close enough to] 100% reliable in a pure P2P network (primarily because there is no guarantee that a sufficient number of relay nodes are online at a given time, as required by a given traffic pattern). In this context, a constant revenue stream for an application vendor could come from selling a "pro" connectivity service in conjunction with its applications, which would guarantee the end users a reliable network of fallback servers whenever the p2p-based main network is unable to cope with the network traffic.
  Furthermore, the availability of "pro" connectivity services in conjunction with P2P OS-based applications is valuable not only to the end users of an app (by providing them with reliable connectivity for a decent price), but also to P2P OS's reputation by establishing it not only as an enabler for free best-effort services, but also as a foundation for reliable "pro"-class services

Sponsorships & partnerships
Well, this is more of a wishful thinking than a business idea, but i still think it has some merit: namely, when P2P OS will be released as free software, and should it indeed turn into a unique and valuable piece of software, i don't think it's totally off the wall to imagine receiving some sponsorship offers from the likes of Fedora, Ubuntu, or even Mozilla (and in exchange display their logo as sponsors on the project's home page, on the application store, etc) . Or maybe some partnership programs could be put in place with free-sofware-based companies, like e.g. imagine providing a free-software P2P communications backbone for Firefox OS, Jolla, or even BB10 (and maybe they'd be willing to provide a network of fallback servers - see the paragraph above); now wouldn't that be cool or what?

Selling the software
I'd rather keep this option as a last resort, but it is a fallback option none-the-less if WebRTC (or a similar free-software project) will evolve towards providing a self-sustained P2P network (i.e. doing away with the reliance on dedicated relay servers): in this case, whether P2P OS got to be released as free software or not, maybe a large software company/organization will be interested in acquiring the software's copyrights and owning a WebRTC alternative in-house - and again i'm primarily thinking of free-software outfits like Fedora, Ubuntu, or KDE, but maybe even a "more traditional" company like e.g. Microsoft, Apple, Viber, or Yahoo might be an interested buyer.

P2P OS in a nutshell

The P2P OS project aims at creating an open-source Peer-to-Peer Network Operating System that will enable users to communicate and share with each other without relying on any centralized infrastructure and/or service provider.

A top-level technical overview
From a technical perspective, the core of P2P OS will consist of a P2P Application Server that will implement an open-spec peer-to-peer communication API, thus enabling P2P OS-based applications to seamlessly connect with each other inside a transparently-managed P2P network.

• for example, a P2P Messenger text-only application will be able to simply request to the underlying P2P operating system to connect to [a copy of itself running on] a remote user's computer, and then send and receive messages without dealing with any of the P2P network connection details:
  
  
  
  
  
• additionally, a P2P application running on a user's computer will be able to start other "helper applications" on said computer, and thus it may both extend its own functionality via plug-ins, or it may even become a service provider (i.e. a server) for other, totally distinct, third-party applications
• for example, the above-mentioned text-based chat application can start, and fully control the operation of, a voice/video chat plug-in (which is itself a separate application), thus effectively integrating peer-to-peer voice/video chat functionality in the original (text-only) chat application:

The peer-to-peer application server module will be the first OS component to be developed, while additional kernel and userland components will be added at a later stage, with the end goal of supplying P2P OS with a comprehensive set of system management functions in areas such as the management of distributed resources, task control, creation and management of peer-to-peer overlay networks, system monitoring and diagnosis tools, etc.

P2P OS will be initially developed on the Windows platform with Windows-specific development tools, but should the project reach a stage where it becomes usable it will be ported to Nokia's Qt framework on Windows, Linux, MacOS, and MeeGo. Additionally, P2P OS will also be ported to all the mobile operating systems for which Qt support will be available, with a primary candidate being the Android OS when/if Qt support for Android will become adequate.

A few words on the business potential
Currently there are several peer-to-peer products on the market that share some common design elements with P2P OS (e.g. Yahoo messenger, Skype, Google talk, and various file sharing applications, all use some form of peer-to-peer communication), but all these products are a far cry from P2P OS in terms of both their technological foundation and their objectives: more specifically, all said products except for Skype are not pure peer-to-peer applications in that they rely on some form of centralized resources - i.e. they have the fundamental problem of requiring continuous and substantial financial backing, none of them is intended as a foundation platform for third-party applications, and none of them is open-source software. Given the above, a number of distinctive business models can be thought of which can add a business component to P2P OS, all without compromising its quintessential free public service role (i'll write a mode detailed post on this topic sometime in the coming weeks).

Support this project

If you consider this project interesting/meaningful/valuable in any way, please help spread the word to as many people you can, may they be software developers, potential sponsors and/or angel investors interested in supporting free software, or just about any other people you think might be willing to further spread the word to their own circle(s) of friends and colleagues.