1 Article: Code Flows and Social Networks
3 - Exclude simple redistribution. New Code/Patch Flows.
5 * Debian Packages usually include modifications, let it be in its own
6 build system (include debian/ as a patch?)
7 * VCS commits/updates/pushes/pulls/merges.
8 * Patches through mailing lists, BTSs, PTSs, scattered in the web.
9 * releases, pre-releases, candidates, betas.
10 - Flow direction: code goes from author to "user". Creates a Directed
12 - Is it a tree with a identifiable root? It's centralized/hierarchical.
17 o committer o committer o user? sink?
19 - Remove sinks? Code only flows to them, not from them. Don't remove
20 them. It shows (undesirable) cases where people create code but it
21 only goes "downstream" (only one direction). Hypothetical example:
25 | | o Contributor o Debian o Ubuntu
27 | / o Unlucky Person }
30 Code goes in and comes out from Ubuntu, but it does not reach the
33 - Sources only?? Original authors? Is there original works? Do people
34 just leave the project without ever receiving a patch? Do we consider
37 - Push/pull: request direction. Sending an email with the patch is push.
38 A HTTP GET is pull. An email with HTTP URI is still push. CVS commit
39 is push. CVS update is pull. Use original request. Push has same
42 - Truly centralized systems never do the request. When using CVS, a
43 contributor starts the request when commiting (push) and updating
44 (pull). The repository/root/central point does not start them.
45 Requests have only one flow to a sink.
47 - The distributed model: social network with some nodes with high
48 connectivity and low degree of separation. Clusterization.
50 - git: analyse author, committer, tree maintainer, merges.