What Is netfoundry
Imagine If You Will
You’ve got a great new software idea in which you’ll build cool pieces of functionality that will allow end users to do amazing things and developers to build exciting applications against your APIs. Your application will be the next big thing. You build it. Users show up and request all kinds of great new features. They want the pieces of your application to interact in ways you did not consider. Developers show up and request access to the guts of your system so they can fine tune you and control you.
Let’s turn this model upside down. Let the objects of your system interact with each other based on their connections to each other rather than on some predetermined orchestration. Let the outside world be informed when something in your system changes, and vice versa, but do not allow them to directly invoke your functionality.
What you lose is tedious hand stitching of complex behaviors and intrusive command, control and integration of outside parties. What you gain is self-service, self-organization, an organic software ecosystem that spills over into external software applications and produces surprising, emergent behaviors.
Enter netfoundry
netfoundry is an open source node.js based platform for self-organizing collaborative object networks. Objects link to each other, share state and notify each other of state changes. All interactions are event driven and queued for scalability. Object state is persisted in a NoSQL database. netfoundry is based upon ideas from the Object Network and FOREST projects of Duncan Cragg.
With netfoundry you get a solid framework for managing object state and messaging between linked objects in your system. And since links are just represented as URIs, you can link to external objects and notify them of your state changes via RESTful services.
All of this rests upon the agreement between participants of the format or schema of the object state. Participants do not have to agree on what functionality is triggered when a state change message is received. That’s up to the receiving party. And the receiver will probably change state as a result, which will trigger state change messages to its subscribers. And so on. Interesting behavior emerges from the network, not from the individual nodes.
An Example
I schedule an event in my cool new calendaring software. Within the event details I specify that I need a video projector at the event, but I don’t have one handy and could someone please bring one.
I invite a bunch of organizations to the event, and each one that accepts the invite receives a copy of all the event details. One of those organizations sees that I need a video projector and has one available to bring to the event. They create a link between the video projector asset and the event they received. This link request is sent to me. I confirm that link and celebrate that I don’t have to go buy an expensive projector.
Note that in such a system, no one has to orchestrate a functional interaction of borrowing a video projector. That behavior emerges from the expressed need of the event organizer and the expressed generosity of the event invitee. The participants in such a network only have to make their state known to those with whom they are linked, and to request new links as appropriate to enrich network interconnectivity.
Now What
It’s early days for netfoundry. I’ve just posted the framework and a few working examples to the netfoundry github repository. Developers, feel free to take a look and fork it. I’d love to have your feedback and participation.
netfoundry 
This is the cyber-equivalent of the Gift Circle model as practiced and taught by Alpha Lo and will figure largely in Expressions of Peace: Transition to Peace. The needs are put on the table before the gifts. Often people don’t know what gifts they have until they see the needs. And giving gifts when there is no expressed need can lead to wretched excess and devaluing of gifts. I love the absence of units of exchange and the user autonomy.
netfoundry would indeed be a good platform for a gift circle application. That’s exactly the kind of application I had in mind when I developed it. Nothing in the platform would prevent setting up some kind of monetary exchange or reputation rating system, although I do understand why a gift circle application would not necessarily implement such. That would be entirely up to the developer of the application.
The reputation rating system is built in if all transactions are recorded and entered into the transacting individuals’ dossiers and will then be seen whenever she bids on someone else’s request. The usual case is that there are more gifts than needed, so there has to be a way of making the transaction transparent, even when there’s not a unit of exchange, so the need can be taken off the table.