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