End-to-end principle: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 28: Line 28:
*'''It’s competitive''': For the same reason, it incentives efficient and effective design: one can drop down to a more basic layer and instead implement an alternative, competing layer.
*'''It’s competitive''': For the same reason, it incentives efficient and effective design: one can drop down to a more basic layer and instead implement an alternative, competing layer.
*'''It’s agile''': Thus as use cases develop, the network develops organically to accommodate the new uses through the entrepreneurial  development of the network. So the internet has adapted from messaging to webpages, to VOIP and videostreaming etc etc etc.
*'''It’s agile''': Thus as use cases develop, the network develops organically to accommodate the new uses through the entrepreneurial  development of the network. So the internet has adapted from messaging to webpages, to VOIP and videostreaming etc etc etc.
 
===Don’t do this:===
This applies in the design of all other kinds of multi-use systems, such as — for rather good example — a digital execution hub. There are a number of things you should not do when designing a network if you want to maximise its chances of success:
This applies in the design of all other kinds of multi-use systems, such as — for rather good example — a digital execution hub. There are a number of things you should not do when designing a network if you want to maximise its chances of success:
*'''Teach to fish, do not give a fish''': Do not try to anticipate future uses. Acknowledge that the potential applications and use-cases  
*'''Teach to fish, do not give a fish''': Do not try to anticipate future uses. Acknowledge that the potential applications and use-cases  
*'''Set it free''': Release all code. Make access free. If you try to meter it, extract rent or otherwise monetise basic access to the network, or stifle user’s attempts to build structures on the network, you will dissuade people from using the network at all.
*'''Set it free''': Release all code. No [[copyright]]. Make access free. If you try to meter it, extract rent or otherwise monetise basic access to the network, or stifle user attempts to build structures on the network, you will dissuade people from using the network at all.
*'''Live with free-riders''': it is better to permit free riders than to charge entry to all. Free riders aren’t such a bad thing: mostly, they are ''not'' exclusively free-riders and their usage patters will give other users valuable data about what parts of the network are useful and which are not.  
*'''Live with free-riders''': it is better to permit free riders than to charge entry to all. Free riders aren’t such a bad thing: mostly, they are ''not'' exclusively free-riders and their usage patters will give other users valuable data about what parts of the network are useful and which are not. free-riders who contribute nothing are using your code, and that means you get to influence community standards. In any case, the costs of policing free-riders, and adverse impact that would have on the network’s success (metering, pay-walling, charging) outweighs the benefit to everyone (yes, including the free-rider) of a free, open, adaptive network.
*'''Bottom up, not top down''': Don’t design by committee. As far as possible allow — and require — clients to develop structures on the network that are useful ''to them''. The premise is that the basic layer of the network is a simple as possible: once established as a design it should not need maintenance, and users should contribute much of the hardware.
*'''Bottom up, not top down''': Don’t design by committee. As far as possible allow — and require — clients to develop structures on the network that are useful ''to them''. The premise is that the basic layer of the network is a simple as possible: once established as a design it should not need maintenance, and users should contribute much of the hardware.