Ti | = | How the open source community solved the problem of getting substantial agreement ("Yes") on complex matters |
1.sec | = | It's well-known that open source software develops excellent solutions. Iteration, many eyeballs, etc. The tools for doing this are modularity and versioning. Modularity permits granular agreement. Versioning permits it to get better. |
2.sec | = | The critical condition for success is local necessity - or, to put it another way - running code. Someone needs to solve a problem for their own purposes, in their own environment. |
3.0.sec | = | The method: |
3.1.sec | = | They do their best. |
3.2.sec | = | If it looks like a good start on a problem that is relevant for others, they can publish. |
3.3.sec | = | Then improve. Perhaps someone else will pick up the solution and use it themselves. And improve it and post the improvement. Maybe it forks and wanders off to another solution. |
3.4.sec | = | There is ongoing forking and convergence - eventually a few solutions emerge with strong followings. |
3. | = | [G/Z/ol/s4] |
4.0.sec | = | What may be less well recognized is that this can be applied to other uses of text, notable to legal relationships. The critical concepts are: |
4.1.sec | = | Modularity - disaggregation of a problem - taking it issue by issue. |
4.2.sec | = | Versioning - continuous improvement. One doesn't need a perfect solution, just one's best at any given moment. |
4.3.sec | = | Running code - local decision and consequences. |
4. | = | [G/Z/ol/s3] |
= | [G/Z/ol/s4] |