Doctorado

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   width="781.56781mm"
   height="246.74869mm"
   viewBox="0 0 781.56781 246.74869"
   version="1.1"
   id="svg8"
   inkscape:version="0.92.2 2405546, 2018-03-11"
   sodipodi:docname="nomad-cath.svg">
  <defs
     id="defs2" />
  <sodipodi:namedview
     id="base"
     pagecolor="#ffffff"
     bordercolor="#666666"
     borderopacity="1.0"
     inkscape:pageopacity="0.0"
     inkscape:pageshadow="2"
     inkscape:zoom="0.35"
     inkscape:cx="1707.1854"
     inkscape:cy="182.44035"
     inkscape:document-units="mm"
     inkscape:current-layer="layer1"
     showgrid="false"
     inkscape:window-width="2560"
     inkscape:window-height="1051"
     inkscape:window-x="0"
     inkscape:window-y="0"
     inkscape:window-maximized="1"
     fit-margin-top="0"
     fit-margin-left="0"
     fit-margin-right="0"
     fit-margin-bottom="0" />
  <metadata
     id="metadata5">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <dc:title />
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <g
     inkscape:label="Capa 1"
     inkscape:groupmode="layer"
     id="layer1"
     transform="translate(508.01125,49.644683)">
    <g
       id="g77">
      <flowRoot
         xml:space="preserve"
         id="flowRoot84"
         style="font-style:normal;font-weight:normal;font-size:16px;line-height:25px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"><flowRegion
           id="flowRegion86"><rect
             id="rect88"
             width="193.40176"
             height="358.97366"
             x="-1613.4017"
             y="429.26031" /></flowRegion><flowPara
           id="flowPara90" /></flowRoot>      <text
         transform="matrix(-4.5915791e-4,-0.82622363,1.2103259,-3.2920516e-4,0,0)"
         id="text25-3-1-9"
         y="-253.24312"
         x="-437.07639"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;opacity:0;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         xml:space="preserve"><tspan
           style="stroke-width:0.91002208px"
           y="-253.24312"
           x="-437.07639"
           id="tspan23-5-2-3"
           sodipodi:role="line">Project 3</tspan></text>
      <rect
         style="opacity:0;fill:#0088aa;fill-opacity:1;stroke:#c70000;stroke-width:0.58208334;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
         id="rect214"
         width="40.82143"
         height="123.22024"
         x="-659.19043"
         y="251.64285" />
      <rect
         style="opacity:0;fill:#0088aa;fill-opacity:1;stroke:#c70000;stroke-width:0.58208334;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
         id="rect216"
         width="53.672619"
         height="142.875"
         x="-651.63098"
         y="266.00592" />
      <rect
         style="opacity:0;fill:#808000;fill-opacity:1;stroke:#c70000;stroke-width:0.58208334;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
         id="rect237"
         width="45.357143"
         height="130.77975"
         x="-733.27374"
         y="231.23213" />
      <rect
         style="opacity:0;fill:#808000;fill-opacity:1;stroke:#c70000;stroke-width:0.58208334;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
         id="rect239"
         width="43.845234"
         height="175.38094"
         x="312.20834"
         y="-57.541668" />
      <rect
         style="opacity:0;fill:#808000;fill-opacity:1;stroke:#c70000;stroke-width:0.58208334;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
         id="rect45"
         width="52.160713"
         height="160.2619"
         x="-721.17859"
         y="169.24405" />
      <ellipse
         style="opacity:0;fill:#808000;fill-opacity:1;stroke:#c70000;stroke-width:0.58208334;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
         id="path47"
         cx="-694.34222"
         cy="115.57143"
         rx="63.877975"
         ry="86.178574" />
      <ellipse
         style="opacity:0;fill:#808000;fill-opacity:1;stroke:#c70000;stroke-width:0.58208334;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
         id="path49"
         cx="-633.11011"
         cy="293.22025"
         rx="35.151787"
         ry="53.672619" />
    </g>
    <g
       id="g131"
       inkscape:export-xdpi="61"
       inkscape:export-ydpi="61">
      <g
         transform="matrix(-2.9060253e-4,-0.52292057,0.74745455,-2.0330606e-4,-587.89548,179.58023)"
         id="g32">
        <g
           id="g28">
          <rect
             y="107.25147"
             x="-33.266388"
             height="55.94944"
             width="158.00301"
             id="rect21"
             style="fill:#89a02c;fill-opacity:1;stroke:#c70000;stroke-width:0.57312012;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
        </g>
      </g>
      <g
         transform="matrix(-2.9006271e-4,-0.77614687,0.74606708,-3.0175729e-4,-506.82096,170.38618)"
         id="g32-6">
        <g
           id="g28-7">
          <rect
             style="fill:#89a02c;fill-opacity:1;stroke:#c70000;stroke-width:0.57312012;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
             id="rect21-5"
             width="158.00301"
             height="55.94944"
             x="-33.266388"
             y="107.25147" />
        </g>
      </g>
      <g
         transform="matrix(-2.8986163e-4,-1.0817345,0.74554739,-4.2056579e-4,-418.75731,159.02728)"
         id="g32-6-6">
        <g
           id="g28-7-2">
          <rect
             style="fill:#89a02c;fill-opacity:1;stroke:#c70000;stroke-width:0.57312012;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
             id="rect21-5-9"
             width="158.00301"
             height="55.94944"
             x="-33.266388"
             y="107.25147" />
        </g>
      </g>
      <rect
         y="156.90393"
         x="-507.7049"
         height="39.278889"
         width="340.9039"
         id="rect143"
         style="fill:#0088aa;fill-opacity:1;stroke:#c70000;stroke-width:0.61271977;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
      <text
         xml:space="preserve"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         x="-202.82234"
         y="-331.32965"
         id="text25-3"
         transform="matrix(-4.5915792e-4,-0.82622364,1.2103259,-3.2920517e-4,0,0)"><tspan
           sodipodi:role="line"
           id="tspan23-5"
           x="-202.82234"
           y="-331.32965"
           style="stroke-width:0.91002208px">Project 2</tspan></text>
      <text
         xml:space="preserve"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         x="-427.28372"
         y="157.66428"
         id="text25-3-1-6"
         transform="matrix(0.82622364,-4.5915792e-4,3.2920517e-4,1.2103259,0,0)"><tspan
           sodipodi:role="line"
           id="tspan23-5-2-0"
           x="-427.28372"
           y="157.66428"
           style="stroke-width:0.91002208px">The Platform</tspan></text>
      <text
         xml:space="preserve"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         x="-199.22437"
         y="-257.52499"
         id="text25-3-1"
         transform="matrix(-4.5915792e-4,-0.82622364,1.2103259,-3.2920517e-4,0,0)"><tspan
           sodipodi:role="line"
           id="tspan23-5-2"
           x="-199.22437"
           y="-257.52499"
           style="stroke-width:0.91002208px">Project 3</tspan></text>
      <g
         style="fill:#ffffff"
         transform="matrix(-2.8986163e-4,-1.0960598,0.74554739,-4.2613527e-4,-327.96795,119.26425)"
         id="g32-6-6-3">
        <g
           style="fill:#ffffff"
           id="g28-7-2-6">
          <rect
             style="fill:#ffffff;fill-opacity:1;stroke:#c70000;stroke-width:0.57312012;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
             id="rect21-5-9-7"
             width="158.00301"
             height="55.94944"
             x="-33.266388"
             y="107.25147" />
        </g>
      </g>
      <text
         xml:space="preserve"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         x="-312.72449"
         y="-29.033178"
         id="text25-3-1-6-5"
         transform="matrix(0.82622364,-4.5915792e-4,3.2920517e-4,1.2103259,0,0)"><tspan
           sodipodi:role="line"
           id="tspan23-5-2-0-3"
           x="-312.72449"
           y="-29.033178"
           style="stroke-width:0.91002208px">Jump to large</tspan></text>
      <text
         transform="matrix(-4.5915708e-4,-0.82622364,1.2103259,-3.2920608e-4,0,0)"
         id="text25"
         y="-398.16159"
         x="-205.63182"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         xml:space="preserve"><tspan
           style="stroke-width:0.91002208px"
           y="-398.16159"
           x="-205.63182"
           id="tspan23"
           sodipodi:role="line">Project 1</tspan></text>
    </g>
    <g
       transform="translate(440.05122,-1.2158124)"
       id="g131-5"
       inkscape:export-xdpi="61"
       inkscape:export-ydpi="61">
      <g
         transform="matrix(-2.8986163e-4,-1.0817345,0.74554739,-4.2056579e-4,-328.51913,115.55815)"
         id="g32-6-6-9-8">
        <g
           id="g28-7-2-3-1">
          <rect
             style="fill:#89a02c;fill-opacity:1;stroke:#c70000;stroke-width:0.57312012;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
             id="rect21-5-9-6-3"
             width="158.00301"
             height="55.94944"
             x="-33.266388"
             y="107.25147" />
        </g>
      </g>
      <g
         transform="matrix(-2.9060253e-4,-0.52292057,0.74745455,-2.0330606e-4,-587.89548,179.58023)"
         id="g32-62">
        <g
           id="g28-9">
          <rect
             y="107.25147"
             x="-33.266388"
             height="55.94944"
             width="158.00301"
             id="rect21-1"
             style="fill:#89a02c;fill-opacity:1;stroke:#c70000;stroke-width:0.57312012;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
        </g>
      </g>
      <g
         transform="matrix(-2.9006271e-4,-0.77614687,0.74606708,-3.0175729e-4,-506.82096,170.38618)"
         id="g32-6-2">
        <g
           id="g28-7-7">
          <rect
             style="fill:#89a02c;fill-opacity:1;stroke:#c70000;stroke-width:0.57312012;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
             id="rect21-5-0"
             width="158.00301"
             height="55.94944"
             x="-33.266388"
             y="107.25147" />
        </g>
      </g>
      <g
         transform="matrix(-2.8986163e-4,-1.0817345,0.74554739,-4.2056579e-4,-418.75731,159.02728)"
         id="g32-6-6-9">
        <g
           id="g28-7-2-3">
          <rect
             style="fill:#89a02c;fill-opacity:1;stroke:#c70000;stroke-width:0.57312012;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
             id="rect21-5-9-6"
             width="158.00301"
             height="55.94944"
             x="-33.266388"
             y="107.25147" />
        </g>
      </g>
      <rect
         y="156.90393"
         x="-507.7049"
         height="39.278889"
         width="340.9039"
         id="rect143-0"
         style="fill:#0088aa;fill-opacity:1;stroke:#c70000;stroke-width:0.61271977;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
      <text
         xml:space="preserve"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         x="-156.70943"
         y="-331.31207"
         id="text25-3-6"
         transform="matrix(-4.5915791e-4,-0.82622363,1.2103259,-3.2920517e-4,0,0)"><tspan
           sodipodi:role="line"
           id="tspan23-5-26"
           x="-156.70943"
           y="-331.31207"
           style="stroke-width:0.91002208px">Project 2</tspan></text>
      <text
         xml:space="preserve"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         x="-104.43639"
         y="-257.48886"
         id="text25-3-1-7"
         transform="matrix(-4.5915791e-4,-0.82622363,1.2103259,-3.2920517e-4,0,0)"><tspan
           sodipodi:role="line"
           id="tspan23-5-2-9"
           x="-104.43639"
           y="-257.48886"
           style="stroke-width:0.91002208px">Project 3</tspan></text>
      <text
         xml:space="preserve"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         x="-312.72449"
         y="-29.033178"
         id="text25-3-1-6-5-3"
         transform="matrix(0.82622364,-4.5915792e-4,3.2920517e-4,1.2103259,0,0)"><tspan
           sodipodi:role="line"
           id="tspan23-5-2-0-3-7"
           x="-312.72449"
           y="-29.033178"
           style="stroke-width:0.91002208px">Jump Possible</tspan></text>
      <text
         transform="matrix(-4.5915708e-4,-0.82622364,1.2103259,-3.2920608e-4,0,0)"
         id="text25-5"
         y="-398.16159"
         x="-205.63182"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         xml:space="preserve"><tspan
           style="stroke-width:0.91002208px"
           y="-398.16159"
           x="-205.63182"
           id="tspan23-9"
           sodipodi:role="line">Project 1</tspan></text>
      <rect
         y="138.569"
         x="-427.61984"
         height="37.102825"
         width="260.86475"
         id="rect143-0-2"
         style="fill:#0088aa;fill-opacity:1;stroke:none;stroke-width:0.52092773;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
      <rect
         y="101.14937"
         x="-339.17343"
         height="37.858776"
         width="172.41833"
         id="rect143-0-2-9"
         style="fill:#0088aa;fill-opacity:1;stroke:none;stroke-width:0.42780051;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
      <text
         xml:space="preserve"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         x="-427.27951"
         y="147.60844"
         id="text25-3-1-6-1"
         transform="matrix(0.82622363,-4.5915791e-4,3.2920517e-4,1.2103259,0,0)"><tspan
           sodipodi:role="line"
           id="tspan23-5-2-0-8"
           x="-427.27951"
           y="147.60844"
           style="stroke-width:0.91002208px">The Platform</tspan></text>
      <rect
         y="58.438057"
         x="-248.83711"
         height="43.150444"
         width="81.704048"
         id="rect143-0-2-9-0"
         style="fill:#0088aa;fill-opacity:1;stroke:none;stroke-width:0.31439871;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
      <text
         xml:space="preserve"
         style="font-style:normal;font-weight:normal;font-size:14.56035328px;line-height:22.75055122px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.91002208px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         x="-55.718758"
         y="-184.2253"
         id="text25-3-1-7-1"
         transform="matrix(-4.5915791e-4,-0.82622363,1.2103259,-3.2920516e-4,0,0)"><tspan
           sodipodi:role="line"
           id="tspan23-5-2-9-1"
           x="-55.718758"
           y="-184.2253"
           style="stroke-width:0.91002208px">Project 4</tspan></text>
      <flowRoot
         xml:space="preserve"
         id="flowRoot1126"
         style="font-style:normal;font-weight:normal;font-size:16px;line-height:25px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         transform="matrix(0.26458333,0,0,0.26458333,-948.06247,-47.200928)"><flowRegion
           id="flowRegion1128"><rect
             id="rect1130"
             width="1720"
             height="1577.1428"
             x="-477.14285"
             y="-297.76184" /></flowRegion><flowPara
           id="flowPara1132" /></flowRoot>      <flowRoot
         xml:space="preserve"
         id="flowRoot1134"
         style="font-style:normal;font-weight:normal;font-size:16px;line-height:25px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         transform="matrix(0.26458333,0,0,0.26458333,-948.06247,-47.200928)"><flowRegion
           id="flowRegion1136"><rect
             id="rect1138"
             width="3697.1428"
             height="1668.5714"
             x="-320"
             y="-312.04755" /></flowRegion><flowPara
           id="flowPara1140" /></flowRoot>      <flowRoot
         xml:space="preserve"
         id="flowRoot1142"
         style="font-style:normal;font-weight:normal;font-size:16px;line-height:25px;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
         transform="matrix(0.26458333,0,0,0.26458333,-948.06247,-47.200928)"><flowRegion
           id="flowRegion1144"><rect
             id="rect1146"
             width="3762.8572"
             height="1691.4286"
             x="-302.85715"
             y="-272.04755" /></flowRegion><flowPara
           id="flowPara1148" /></flowRoot>    </g>
  </g>
</svg>

	urldate = {2018-06-03},
	journal = {Palimpsesto, hipertexto, destripa/atrapa musas},
	author = {Luna, Offray},
	month = jan,
	year = {2014}
}




@misc{ramirez-ordonez_estudio_2018,
	title = {Estudio {Crews} en detalle},
	url = {http://micros.nomono.co/copyright-lac/},
	author = {Ramirez-Ordoñez, David and Simón, Virginia Inés},
	year = {2018}
}

	url = {http://joss.theoj.org},
	doi = {pending},
	abstract = {The Journal of Open Source Software, a developer friendly journal for research software packages.},
	language = {en},
	urldate = {2018-01-17},
	author = {Luna Cárdenas, Offray Vladimir}
}

@misc{noauthor_what_2017,
	title = {What is {Mob} {Programming}?},
	url = {https://www.agilealliance.org/glossary/mob-programming/},
	abstract = {Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.},
	language = {en-US},
	urldate = {2018-07-17},
	journal = {Agile Alliance},
	month = jan,
	year = {2017}
}

@misc{noauthor_mob_nodate,
	title = {Mob {Programming} – {All} the brilliant people working on the same thing, at the same time, in the same space, and on the same computer},
	url = {http://mobprogramming.org/},
	language = {en-US},
	urldate = {2018-07-17}
}

@book{meadows_mob_2013,
	title = {Mob {Programming}},
	url = {https://leanpub.com/mobprogramming},
	abstract = {\"All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer\" - We call it \"Mob Programming\". With dual projectors, one computer, two keyboards, and a very collaborative approach we use this practice to super-charge our development efforts and deliver high value software quickly.},
	language = {undefined},
	urldate = {2018-07-17},
	publisher = {Leanpub},
	author = {Meadows, Kevin and Zuill, Woody},
	month = mar,
	year = {2013}
}

@misc{noauthor_mob_2018,
	title = {Mob programming},
	copyright = {Creative Commons Attribution-ShareAlike License},
	url = {https://en.wikipedia.org/w/index.php?title=Mob_programming&oldid=846035312},
	abstract = {Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This is similar to pair programming where two people sit at the same computer and collaborate on the same code at the same time. With Mob Programming the collaboration is extended to everyone on the team, while still using a single computer for writing the code and inputting it into the code base.
It builds on principles of lean manufacturing, extreme programming, and lean software development. Early use of the phrase "mob programming" was made in Extreme Programming Perspectives.
In addition to software coding, a mob programming team can work together to do almost all the work a typical software development team tackles, such as defining user stories or requirements, designing, testing, deploying software, and working with the customer and business experts. Almost all work is handled in working meetings or workshops, and all the people involved in creating the software are considered to be team members, including the customer and business experts.},
	language = {en},
	urldate = {2018-07-17},
	journal = {Wikipedia},
	month = jun,
	year = {2018},
	note = {Page Version ID: 846035312}
}

@misc{noauthor_quoting_nodate,
	title = {quoting - "{Inspirational}" quote at start of chapter},
	url = {https://tex.stackexchange.com/questions/53377/inspirational-quote-at-start-of-chapter},
	urldate = {2018-07-17},
	journal = {TeX - LaTeX Stack Exchange}
}

@misc{noauthor_grafoscopio_nodate,
	title = {grafoscopio - {Re}: [grafoscopio] {Algunas} estadísticas de los repositorios de código},
	url = {https://lists.riseup.net/www/arc/grafoscopio/2017-12/msg00025.html},
	urldate = {2018-08-13}
}

@misc{noauthor_libre_nodate,
	title = {The {Libre} {Culture} {Manifesto}},
	url = {http://freesoftwaremagazine.com/articles/libre_manifesto/},
	urldate = {2018-08-18}
}

@misc{noauthor_libre_2018,
	title = {Libre manifesto},
	copyright = {Creative Commons Attribution-ShareAlike License},
	url = {https://en.wikipedia.org/w/index.php?title=Libre_manifesto&oldid=836132796},
	abstract = {A libre manifesto is a concise statement of values and intent shared by members of a community concerned with the development and sharing of libre resources. The values reflect those of the free/libre software movement and the community behind the manifesto typically engages in activism towards a libre society.},
	language = {en},
	urldate = {2018-08-18},
	journal = {Wikipedia},
	month = apr,
	year = {2018},
	note = {Page Version ID: 836132796}
}

@misc{noauthor_desis_nodate,
	title = {Desis {Network}: {Design} for {Social} {Innovation} and  {Sustainability} {\textbar} {Articles}},
	url = {https://www.desisnetwork.org/articles/},
	language = {en-GB},
	urldate = {2018-08-18},
	journal = {Desis Network}
}

@misc{noauthor_desis_nodate-1,
	title = {Desis {\textbar} {About}},
	url = {https://www.desisnetwork.org/about/},
	abstract = {ABOUT About the coordination project 2017-2017: here DESIS Network originates from three main international activities in the 2006-2008 period: the European research EMUDE, 2005; the UNEP Program CCSL, 2008 and the international conference “Changing the Change, within the framework of Torino World Design Capital, 2008. In different ways, these activities introduced the notions of creative …},
	language = {en-GB},
	urldate = {2018-08-18},
	journal = {Desis Network}
}

@article{griffith_sociologists_2018,
	title = {Sociologists {Examine} {Hackathons} and {See} {Exploitation}},
	issn = {1059-1028},
	url = {https://www.wired.com/story/sociologists-examine-hackathons-and-see-exploitation/},
	abstract = {A study finds that hackathon sponsors take advantage of free labor to create "fictional expectations of innovation that benefits all."},
	urldate = {2018-08-18},
	journal = {Wired},
	author = {Griffith, Erin},
	month = mar,
	year = {2018},
	keywords = {hackathons}
}

@article{conway_how_1968,
	title = {How {Do} {Committees} {Invent}?},
	url = {http://www.melconway.com/Home/Committees_Paper.html},
	journal = {Datamation magazine},
	author = {Conway, Melvin E.},
	month = apr,
	year = {1968}
}

@misc{maccormack_exploring_2011,
	title = {Exploring the {Duality} between {Product} and {Organizational} {Architectures}: {A} {Test} of the “{Mirroring}” {Hypothesis}},
	author = {MacCormack, Alan and Rusnak, John and Baldwin, Carliss},
	year = {2011}
}

@book{latour_vida_1995,
	address = {Madrid},
	title = {La vida en el laboratorio: la construcción de los hechos científicos},
	isbn = {978-84-206-2813-4},
	shorttitle = {La vida en el laboratorio},
	language = {Spanish},
	publisher = {Alianza Editorial},
	author = {Latour, Bruno and Pérez Sedeño, Eulalia and Woolgar, Steve},
	year = {1995},
	note = {OCLC: 1023996376}
}

@book{latour_laboratory_1986,
	address = {Princeton, N.J},
	title = {Laboratory life: the construction of scientific facts},
	isbn = {978-0-691-02832-3 978-0-691-09418-2},
	shorttitle = {Laboratory life},
	publisher = {Princeton University Press},
	author = {Latour, Bruno and Woolgar, Steve},
	year = {1986},
	keywords = {Biology, Methodology, Research}
}

@misc{vance_crossing_2017,
	title = {Crossing {Boundaries}: {Insights} for {Ethics} of {Extractive} {Knowledge} from {Post}-{Colonial} {Contexts}},
	shorttitle = {Crossing {Boundaries}},
	url = {https://medium.com/@cartervance/crossing-boundaries-insights-for-ethics-of-extractive-knowledge-from-post-colonial-contexts-32b6f734cb47},
	abstract = {One of the key insights that post-colonial theory has brought to the world of research, and academia more broadly, is the historically…},
	urldate = {2018-09-12},
	journal = {Medium},
	author = {Vance, Carter},
	month = mar,
	year = {2017}
}

@misc{hill_when_2013,
	title = {When {Free} {Software} {Isn}'t {Better} - {Benjamin} {Mako} {Hill} - {LibrePlanet} 2013},
	url = {https://www.youtube.com/watch?v=Er1pM9suxvE},
	urldate = {2018-09-12},
	author = {Hill, Benjamin Mako},
	year = {2013},
	keywords = {Benjamin Mako Hill, Free Software (Industry), Free Software Foundation (Organization), LibrePlanet}
}

@misc{luna_cardenas_nomadas_2010,
	title = {Nómadas {Digitales}},
	url = {https://prezi.com/8nqtobpcshjm/nomadas-digitales-javeriana/},
	abstract = {Nómadas Digitales - Javeriana},
	language = {en},
	urldate = {2018-09-13},
	journal = {prezi.com},
	author = {Luna Cárdenas, Offray Vladimir},
	month = may,
	year = {2010}
}

@misc{maxigas_hacklabs_nodate,
	title = {Hacklabs and hackerspaces – tracing two genealogies » {The} {Journal} of {Peer} {Production}},
	url = {/issues/issue-2/peer-reviewed-papers/hacklabs-and-hackerspaces/},
	language = {en-US},
	urldate = {2018-09-13},
	author = {{Maxigas}}
}

@book{wark_hacker_2004,
	address = {Cambridge, MA},
	title = {A hacker manifesto},
	isbn = {978-0-674-01543-2},
	publisher = {Harvard University Press},
	author = {Wark, McKenzie},
	year = {2004},
	keywords = {Intellectual property, Computers and civilization, Digital divide, Hackers, Information technology, Social aspects, Social conflict}
}

@incollection{schrock_hackers_nodate,
	title = {Hackers are {Ordinary}: {Entanglement} in {Hacker} and {Maker} {Spaces}},
	booktitle = {Making {Our} {World}: {The} {Hacker} and {Maker} {Movements} in {Context}.},
	author = {Schrock, Andrew R.},
	editor = {Schrock, Andrew R. and Hunsinger, J.}
}

@article{schrock_education_2014,
	title = {“{Education} in {Disguise}”: {Culture} of a {Hacker} and {Maker} {Space}},
	volume = {10},
	issn = {1548-3320},
	shorttitle = {“{Education} in {Disguise}”},
	url = {https://escholarship.org/uc/item/0js1n1qg#author},
	abstract = {Hacker and maker spaces (HMSs) are open-access workshops devoted to creative and technical work. Their growing numbers (over 500 worldwide) make them a significant grassroots movement supporting informal learning. Scholars have found pedagogical benefits of tinkering and hacking, but the cultural contexts from which these practices arise remain under-studied. How do members of hacker and maker spaces bring about personalized and collaborative learning? In-depth interviews were conducted between October 2011 and March 2012 with members of GeekSpace, a North American HMS. Findings suggest that the pragmatic attitude present in other hacker cultures served a similar uniting function in this space. Specifically, members encouraged learning and collaboration predominantly through a belief in materialities, particularly as GeekSpace's collective identity shifted from hacker to maker. Members altered the space to serve individual and collective goals rather than employing deliberation or strong organizational methods. Initially the group approached learning through lectures and solo problem-solving, which gave way to learning through hands-on work and peripheral participation on projects. Future avenues of research on HMSs include patterning across different sites, organizational practices and factors that inhibit participation. This article draws on interviews with HMS members to discuss how the spread of hacking and making has led to members forming loose organizations focused on informal learning and peer production.},
	language = {en},
	number = {1},
	urldate = {2018-09-13},
	journal = {InterActions: UCLA Journal of Education and Information Studies},
	author = {Schrock, Andrew Richard},
	month = jan,
	year = {2014}
}

@inproceedings{ostrom_artifacts_2001,
	address = {Duke Law School, Durham, North Carolina},
	title = {Artifacts, {Facilities}, {And} {Content}: {Information} as a {Common}-pool {Resource}},
	url = {https://law.duke.edu/pd/papers/ostromhes.pdf},
	author = {Ostrom, Elinor and Hess, Charlotte},
	month = nov,
	year = {2001},
	pages = {44 -- 79}
}

@misc{kelty_geeks_2008,
	title = {Geeks and {Recursive} {Publics}: {How} the {Internet} and {Free} {Software} {Make} {Things} {Public}},
	author = {Kelty, Christopher},
	year = {2008}
}

@incollection{schrock_hackathons_2016,
	title = {“{Hackathons} with no hacking”: civic hackathons and the performance of  innovation.},
	booktitle = {Rethinking the {Innovation} {Economy}: {Exploring} the {Future} of {Technology}, {Social} {Inequality},  and {Creative} {Labor}.},
	author = {Schrock, Andrew R.},
	year = {2016}
}

@article{couldry_data_2018,
	title = {Data {Colonialism}: {Rethinking} {Big} {Data}’s {Relation} to the {Contemporary} {Subject}},
	issn = {1527-4764, 1552-8316},
	shorttitle = {Data {Colonialism}},
	url = {http://journals.sagepub.com/doi/10.1177/1527476418796632},
	doi = {10.1177/1527476418796632},
	language = {en},
	urldate = {2018-09-23},
	journal = {Television \& New Media},
	author = {Couldry, Nick and Mejias, Ulises A.},
	month = sep,
	year = {2018},
	pages = {152747641879663}
}

@book{wenger_digital_2009,
	address = {Portland, OR},
	title = {Digital habitats: stewarding technology for communities},
	isbn = {978-0-9825036-0-7},
	shorttitle = {Digital habitats},
	language = {eng},
	publisher = {Cpsquare},
	author = {Wenger, Etienne and White, Nancy and Smith, John D.},
	year = {2009},
	note = {OCLC: 602796157}
}

@book{rodriguez_narratopedia:_2011,
	address = {Bogotá},
	edition = {Primera edición},
	title = {Narratopedia: {Reflexiones} sobre narrativa digital, creación colectiva y cibercultura},
	isbn = {978-958-716-425-1},
	shorttitle = {Narratopedia},
	publisher = {Pontificia Universidad Javeriana},
	editor = {Rodríguez, Jaime Alejandro},
	year = {2011},
	note = {OCLC: ocn747559184},
	keywords = {Authorship, Collaboration Data processing, Creation (Literary, artistic, etc.), History and criticism, Hypertext literature, Literature and the Internet, User-generated content, Social media}
}

@incollection{luna_cardenas_habitats_2011,
	address = {Bogotá},
	edition = {Primera edición},
	title = {Hábitats digitales para la memoria, la presencia y la imaginación},
	isbn = {978-958-716-425-1},
	booktitle = {Narratopedia: {Reflexiones} sobre narrativa digital, creación colectiva y cibercultura},
	publisher = {Pontificia Universidad Javeriana},
	author = {Luna Cárdenas, Offray Vladimir},
	year = {2011},
	note = {OCLC: ocn747559184},
	keywords = {Authorship, Collaboration Data processing, Creation (Literary, artistic, etc.), History and criticism, Hypertext literature, Literature and the Internet, User-generated content, Social media}
}

@misc{luna_gobernaton:_2013,
	title = {La {Gobernatón}: ¿{Qué} sigue?},
	shorttitle = {La {Gobernatón}},
	url = {http://mutabit.com/offray/static/blog/output/posts/la-gobernaton-que-sigue.html},
	abstract = {Por Offray Vladimir Luna Cárdenas
La Gobernaton es una iniciativa ciudadana de innovación social y abierta. 
Inició como una crítica constructiva a una iniciativa de 
MinTIC en 2013 que gastó 2700 mil},
	language = {es},
	urldate = {2018-09-26},
	journal = {Palimpsesto, hipertexto, destripa/atrapa musas},
	author = {Luna, Offray},
	month = jun,
	year = {2013}
}

@misc{vila_permanent_2013,
	title = {The {Permanent} {Hackathon}},
	url = {https://www.theengineroom.org/the-permanent-hackathon/},
	abstract = {The discussion about hackathons is moving beyond their relative merit to the question of how they can be improved. New projects are starting to reimagine the hackathon model so that it’s less focused on discrete time-frames, ticking clocks and prize money, and more focused on building lasting commun},
	language = {en-GB},
	urldate = {2018-10-01},
	journal = {The Engine Room},
	author = {Vila, Susannah},
	month = aug,
	year = {2013}
}

@misc{noauthor_live_2018,
	title = {Live coding},
	copyright = {Creative Commons Attribution-ShareAlike License},
	url = {https://en.wikipedia.org/w/index.php?title=Live_coding&oldid=858069693},
	abstract = {Live coding (sometimes referred to as 'on-the-fly programming', 'just in time programming' and 'conversational programming') makes programming an integral part of the running program.It is most prominent as a performing arts form and a creativity technique centred upon the writing of source code and the use of interactive programming in an improvised way. Live coding is often used to create sound and image based digital media, as well as light systems, improvised dance and poetry, though is particularly prevalent in computer music usually as improvisation, although it could be combined with algorithmic composition. Typically, the process of writing source code is made visible by projecting the computer screen in the audience space, with ways of visualising the code an area of active research. Live coding techniques are also employed outside of performance, such as in producing sound for film or audiovisual work for interactive art installations. Also, the interconnection between computers makes possible to realize this practice networked in group. 
The figure of live coder is who performs the act of live coding, usually "artists who want to learn to code, and coders who want to express themselves" or in terms of Wang \& Cook the "programmer/performer/composer".Live coding is also an increasingly popular technique in programming-related lectures and conference presentations, and has been described as a "best practice" for computer science lectures by Mark Guzdial.},
	language = {en},
	urldate = {2018-10-11},
	journal = {Wikipedia},
	month = sep,
	year = {2018},
	note = {Page Version ID: 858069693}
}

@misc{denker_nomads_2014,
	type = {Software},
	title = {Nomads do not build {Cathedrals}},
	url = {https://www.slideshare.net/esug/nomads-do-not-build-cathedrals},
	abstract = {Title: Nomads do not build Cathedrals
Speaker: Marcus Denker
Thu,},
	urldate = {2018-10-11},
	author = {Denker, Marcus},
	month = aug,
	year = {2014}
}

progresiva.
Se considerarán desde la perspectiva histórica, dando cuenta de como surgieron
y cambiaron, y también de la variedad y diversidad de las mismas.
Como la participación y la cosificación son inseparables, las maneras de participación
estarán mediadas no sólo por Grafoscopio, sino por otros artefactos de los que también
se dara cuenta.
Por ello, el término encuentro, se referirá tanto a las experiencias cara a cara, como
a aquellas que son mediadas por alguna forma de artefacto (cosificación) creado por y 
para dichas formas de participación.

De los diversos encuentros dos en particular, las Data Week y Data Rodas permitieron
ejecutar tres de las cuatro fases propuestas en la metodología: el \emph{software como hipótesis}
era reapropiado por una comunidad durante los encuentros, pues una vez se contaba con
protipos básicos de Grafoscopio y otras infraestructuras y herramientas estas se colocanban
en contextos comunitarios para ser aprendidos; también servían para la \emph{indagación contextual} 
en la misma, recibiendo realimentación de los participantes, permitiendo definir prioridades
y énfasis en los próximos diseños y, finalmente, se usaban para la fase de
\emph{diseño participativo}, pues el código, los problemas y las metodologías 
originalmente propuestas, cambiaban de acuerdo a la participación.
La fase de \emph{diseño de producto} se hacía en solitario, incorporando en el software 
Grafoscopio y otros artefactos los resultados de las otras fases y alistándolo para nuevas
iteraciones del ciclo de investigación.
Además, Data Weeks y Data Rodas incorporan tres innovaciones metodológicas a resaltar:
el \emph{live coding}, la documentación ágil y el \emph{mob programming}.
(La primera es facilitada gracias a Pharo/Grafoscopio), de las que se hablará más 
adelante y que son  particularmente útiles en encuentros de prototipado intensivo, cómo las 
hackatones, pero que también ayudan a escapar de la volatilidad asociada a las mismas.

Dichos espacios de encuentro son, no sólo una manera explícita de desplegar la metodología
de investigación de esta tesis en tres de sus cuatro fases, sino una manera de dar cuenta de
los componentes de carácter etnográficamente informado de la misma y su apuesta por la
investigación acción desde el trabajo comprometido y extenso (casi 4 años) con comunidades de base, 
pues amplificaba la capacidad en las mismas de co-construir, reconstruir y participar del discurso 
público (mencionadas en el capítulo \ref{cultura-hacker} y ejemplificadas en los prototipos
del capítulo \ref{prototipos}).
Además Data Weeks y Data Rodas configuraban un currículo y prácticas educativas, en una comunidad 
particular, sobre las maneras de apropiar saberes para cambiar las tecnologías que nos cambian 
(en particular Grafoscopio) al mismo tiempo que se adquirían y compartían alfabetismos críticos 
desde y sobre lo digital, en la naturaleza casi siempre político de los datos, las maneras de 
reapropiarlos y compartirlos y el código y las herramientas que nos permiten ejercicios ciudadanos 
desde y sobre la tecnología antes referidos.
Las fases de diseño no sólo diseñaban artefactos de software, sino prácticas educativas
y ciudadanas de las que da cuenta este capítulo.

El Data Week y las Data Rodas incorporan, algunas innovaciones metodológicas que vale la pena 
mencionar y fueron avanzando desde sus diseños preliminares hasta características propiamente
consolidadas:

\begin{itemize}
	
	\item \emph{Live Coding}: Según la Wikipedia (\cite{noauthor_live_2018}) es también
	referido como programación al vuelo (\emph{on the fly}) o conversacional y tiene
	que ver con hacer la programación una parte integral del programa en ejecución.
	Esta característica ha sido particularmente subrayada en los performances musicales
	donde se hace código que interpreta la música que suena en el momento y existe un
	fuerte movimiento de live coding como arte performativa musical (véase \url{http://toplap.org}), 
	sin embargo su posibilidades también se encuentran en otros dominios como la visualización 
	de datos o el activismo.
	En en el caso de los Data Weeks y Data Rodas, la implementación de esta característica
	tuvo que ver con realizar modificaciones en caliente de un sistema funcional y ejecutándose, 
	y disminuyendo la brecha entre la creación y los creados, lo cual es particularmente
	útil cuando se opera con un material simbólico y abstracto como lo es el código.
	Aprovechamos que Pharo soporta el \emph{live coding}, continuando la tradición de 
	Smalltalk, e incorporando un continuo entre texto, código, documentos y programas, que
	Grafoscopio ayuda a establecer (como se mostró en el capítulo \ref{grafoscopio}.).	  
	\item \emph{Documentación ágil}: A lo largo de las distintas iteraciones la documentación
	jugó un papel importante y progresivamente se incorporaron prácticas e infraestructuras
	que permitieron realizarla de maneras más ágiles, desde sencillos textos colaborativos
	provistos vía Etherpad, que sumados a lenguajes de etiquetamiento ligeros (Markdown) y 
	sistemas distribuidos de control de versiones minimalistas (Fossil) permitián escribir 
	colaborativamente las memorias del evento y estructurarlas progresivamente para la 
	participación posterior de nosotros mismos en la comunidad, facilitando el ingreso de nuevos 
	participantes y el trabajo asíncrono y remoto.
	Al final implementamos una versión de CodiMD\footnote{\url{https://demo.codimd.org/}} en 
	nuestros propios servidores, que permitió integrar la experiencia y crear librillos y 
	documentación ágil estructurada entre varios participantes en tiempo real, conectando la 
	experiencia del \emph{live coding} no sólo a la escritura de software, sino de documentación.
	
	\marginpar{
		\captionsetup{type=figure}
		\centering
		\includegraphics[width=\marginparwidth]{./Parte2/mobbing.jpg}
		\caption[\emph{Mob Programming}]
		{Una sesión de \emph{Mob Programming} habitual: varias participantes
			compartimos un proyector o pantalla y sugerimos código que es escrito desde un único
			teclado. En nuestra variación, otros participantes pueden tener sus propios computadores,
			si bien el foco está en lo que se escribe desde uno solo de ellos.}
		\label{fig:mobbing}
	}	  
	
	\item \emph{Mob Programming}: Es una técnica en la que varias personas comparte un 
	teclado y una pantalla o proyector mientras dan ideas y sobre el código que se escribe, 
	por una de ellas, llamado el conductor, que es un puesto que se puede rotar.
	De esta manera se permite expresar ideas en código, sin colocar a la escritura 
	del mismo como una barrera para la participación y alentando a otros a ver prácticas 
	de los más experimentados y eventualmente a escribir el código por ellos mismos.
	Si bien se implementó desde las primeras sesiones el descubrimiento de esta técnica
	fue contingente y no sabíamos que ya existía, incluso con libros que la reportan
	y describen en detalle.
	En nuestro caso se trataba de la disponibilidad del proyector y el hecho de que
	en nuestro intento por hacer del código un lenguaje común entre quienes no éramos
	programadores, dicha técnica fue emergiendo de manera natural y comparábamos
	el acto de ver a otros escribir código al de ir a alguien interpretar música,
	que era algo de lo que todos podíamos participar, incluso si no todos en la audiencia
	eran intérpretes musicales ellos mismos.
	El caracter frenético del modelo hackatón hacía también de esta una técnica adecuada
	cuando el cierre del evento se acercaba, si bien se rotó algunas veces la función
	de conductor y otros pudieron escribir código directamente.
	La ganancia principal estuvo sin embargo en la posibilidad de conversar sobre el código
	aportando ideas que se verían reflejadas en este y ejemplificando lo que otros autores
	(\cite{bhargava_beyond_2015}, \cite{luna_hacer_2014}) mencionaban sobre los alfabetismos 
	críticos \emph{sobre} la tecnología y \emph{desde} la tecnología.
	
\end{itemize}

\begin{figure*}[!hbt]
	\centering
	\includegraphics[width=0.75\linewidth]{./Parte2/agile-doc.png}
	\label{fig:agile-doc}
	\caption[Documentación ágil.]
	{Infraestructura para documentación ágil incorporándo varias
		búsquedas a lo largo de los eventos. En el panel de la izquierda está la vista de 
		código (Markdown) del documento y en el panel de la derecha la visualización en
		tiempo real de dicho código, extendiendo así la idea de \emph{live coding} asociada al
		software también a la documentación.}
	\label{fig:metodologia-innovaciones}
\end{figure*}


Las primeras secciones darán cuenta de cómo se llegó a las Data Weeks y Data  Rodas
y los desafíos y limtaciones que dichos formatos enfrentan.
En dicho recuento se harán explícitas las fases de la metodología antes explicadas,
pues se verá como ellas se interconectan y cómo crean artefactos que ayudan a
la comunidad a apropiar y sugerir saberes para ejercer ciudadanías digitales desde
la modificación recíproca entre ésta y los artefactos digitales que se usan.

Los otros eventos tanto nacionales e internacionales de los que se participó, muestran el
caracter polisémico de los artefactos y aproximaciones que esta tesis tiene, más allá del
enfoque púramente positivista centrado en el código y lo medible, para preocuparse por
las dinámicas sociales alrededor de la tecnología y las subjetividades que estás convocan.
Por ello fue posible participar de eventos técnicos, pero también de eventos académicos
preocupados por la investigación y las comunidades hacker, y aquellos que leen en clave
crítica prácticas ciudadanas mediadas por tecnologías digitales, con perspectiva del Sur 
Global, o que convocan a activistas, periodistas, académicos, artistas y otros públicos
y sujetos diversos.

Este capítulo muestra los diferentes eventos relacionados con Grafoscopio y las metodologías
de aprendizaje que se desplegaron alrededor del mismo, así como la participación en
eventos nacionales e internacionales que dan cuenta de las múltiples facetas con las que
esta tesis y sus artefactos intentan interlocutar, más allá de discursos puramente 
tecnocéntricos\footnote{La tecnología es importante, por supuesto, en esta tesis y el 
	capítulo \ref{grafoscopio} da cuenta detallada de las materialidades tecnológicas
	que soportan esta tesis y las maneras en que estas se apropiaron para la construcción
	de prototipos mínimos que permitiesen desplegar dicha tecnología en contextos sociales.
	Sin embargo, al ser esta una tesis en diseño y no en ciencias de la computación, la
	preocupación principal no está en los algortimos o infraestructuras computacionales, sino
	en las formas en que ellas (con propiedades particulares), empoderan a individuos y comunidades 
	de base, y desde la modificación recíproca tecnología - seres humanos y propician 
	articulaciones intercomunitarias y entre ciudadanos y gobierno.}.

\section{Data Week}\label{dataweek-intro}

El \emph{Data Week}, según su página web (\cite{luna_cardenas_data_2015}), es un 
taller+(anti)hackatón sobre visualización y activismo de datos donde se aprende a trabajar
con diversas representaciones referidas a los datos, bien sean simbólicas (código), icónicas
(visualizaciones) o cuantitativas.
Su carácter de taller tiene que ver con el aprendizaje mediante el ejemplo y la práctica
y su carácter de (anti)hackatón tiene que ver con la naturaleza intensiva y orientada a
prototipado de las hackatones, a la vez que la resistencia a la gentrificación del término
y la práctica (por eso el ``anti'' en paréntesis) por actividades que sólo quieren la fachada
de la innovación al mismo tiempo que no contribuyen a la interconexión permanente entre
comunidades de base y asuntos de construcción de lo público y el procomún, particularmente





en diálogo con instituciones gubernamentales intersectadas con dichas construcciones.





\begin{figure*}[tbh]
	\centering
	\subfloat[¿Qué es el data week?]{
		\includegraphics[width=0.45\linewidth]{./Parte2/dataweek-web1.png}
		\label{subfig:dataweek-web1.png}}
	\quad
	\subfloat[Cómo participar (aparte)]{
		\includegraphics[width=0.45\linewidth]{./Parte2/dataweek-web2.png}
		\label{subfig:label2}}
	\caption[Página web del Data Week]
	{Apartes de la página web del Data Week, que explican qué es y cómo participar.
		Se pude ver en toda su extensión en \url{http://mutabit.com/dataweek}.}
	\label{fig:label}
\end{figure*}


En el Data Week se enseña como usar y extender Grafoscopio, usualmente desde ejemplos, 
temáticas y problemáticas de caracter abierto, que tienen la intensión de amplificar voces
ciudadanas.
El despliegue de la metodología no sólo considera aspectos de índole técnica, sino también
historico crítica, alejándonos del inicio por el clásico pero neutralizado ejemplo del
``hola mundo'' y más bien considerando partir de preguntas y propuestas abiertas sobre temas 
ciudadanos.
A pesar de que se suele tomar un tema recurrente (casi siempre el de los Data Selfies, explicado
en detalle en la sección \ref{twitter-data-selfies}) se permiten variaciones entre temas y
la intensión es más constituir un ritual de bienvenida (\cite{wenger_communities_1999} habla de
estructuras de acogida) a la comunidad de práctica de Grafoscopio, interesada por las herramientas
amoldables, en el contexto de la investigación y publicación reproducible, las narrativas y
visualización de datos y las llamadas tecnologías cívicas.
Este caracter introductorio a una comunidad se menciona en cada una de las ediciones.
Se intentan aproximaciones alternativas al ``Big Data'', virando el foco hacia la capacidad
de agencia que nuestros propios datos o aquellos que extraemos de entidades gubernamentales
(bien sea porque ellos los publican o porque nosotros los adquirimos vía scrapping) brindan
en la constitución de prácticas ciudadanas.


\subsection*{Las motivaciones: crear capacidad en la base, interlocutar con el poder y resistir}

El Data Week tuvo dos motivaciones conexas: la primera, resistir los actos de gentrificación
asociados a la popularización de la ``hackatón'' como formato de ``innovación social'' denunciados
en la sección La Gobernaton (ver sección \ref{gobernaton}), la segunda, crear capacidad en las comunidades
de base para interlocutar con el poder desde nuevas técnicas mediadas por saberes 
y materialidades hacker, específicamente en diálogo de las preguntas que esta tesis buscaba explorar
respecto a cómo cambiar los artefactos que nos cambian, usando Grafoscopio para ello.



El vértigo en el hacer, el inmediatismo y la excesiva orientación al lucro y la manoseada ``innovación'' 
de las \emph{hackatones} enajenadas, denunciadas
por Irani con su crítica a la ``ciudadanía emprendedora'', por Schrock (\emph{hackathons without hacking}) 
y Luna en la Gobernatón, 
son una desconexión evidente a este discurso de la idea de hacer es pensar expresada por Sennet. 
El quehacer artesanal tiene un ritmo y continuidad que dichas hackatones no logran capturar ni interconectar. 
La idea de pulso, que yo mismo digo, con momentos sosegados y frenéticos tampoco se ve. 
Tan sólo hay cabida para los momentos frenéticos.
Frente a esta dinámica, se propuso el Data Week como una manera de combinar los distintos
ritmos, en la medida en que era un ritual intensivo de bienvenida a una comunidad que
también tendría ritmos más sosegados (dando así los primeros pasos de ese viaje largo al
que se refiere el epígrafe de este capítulo).
De este modo se mostraba que la hackatón podría ser algo más que sólo un evento mediático
e interconectarse mejor con los procesos orgánicos en comunidades de base, a la vez que
las visibilizaba y las articulaba con las preocupaciones por la construcción de lo público
y lo ciudadano, lo cual era un lugar ausente en las hackatones de orientación más técnica.
Así se aprovechaba las propuestas de las hackatones \emph{fashionistas} respecto a proponer
formatos innovadores de interlocución entre ciudadanía y estado, mediante prototipos
tecnológicos, al mismo tiempo que se resistía la gentrificación al articularse con comunidades
de base con posturas críticas y trabajos permanentes y duraderos más allá de la hackatón.

\marginpar{
	\captionsetup{type=figure}
	\centering
	\subfloat[]{
		\includegraphics[width=\marginparwidth]{./Parte2/salto-imposible.png}
		\label{subfig:salto-imposible}}
	\quad
	\subfloat[]{
		\includegraphics[width=\marginparwidth]{./Parte2/salto-posible.png}
		\label{subfig:salto-posible}}
	\caption[Instalar capacidad creciente en la infraestructura]
	{Instalar capacidad creciente en la infraestructura fue una de las motivaciones
		del formato Data Week y Data Roda, de manera que se pudieran asumir proyectos
		progresivamente más complejos desde infraestructuras y comunidades progresivamente
		más capaces.
		Este tema se retoma en la figura \ref{fig:capacity-building}, cuando se presentaba
		el currículo y las intensiones de las Data Weeks y Data Rodas a sus participantes
		(adaptado de \cite{denker_nomads_2014}).}
	\label{fig:capacidad-en-infraestructura}
}

Por otro lado, la pregunta sobre cómo cambiar los artefactos digitales que nos cambian, tenía 
que ver con la puesta en escena del entramado entre tecnologías y comunidades de base para
indagar sobre esta relación de modificación recíproca en la práctica.
Se quería dejar instalada capacidad en la comunidad de base y la tecnología (véase figura) 
de modo que se pudieran asumir proyectos progresivamente más complejos gracias a los saberes que 
la comunidad iba adquiriendo y que la infraestructura iba reflejando, como efectivamente ocurrió,
con lo cual se escapaba a la volatilidad propia de los eventos de prototipado más vertiginosos
y se iniciaban actos de enculturación (de pertenencia) a comunidades de práctica más duraderas,
que las fortalecían.
Esta intensión se hacía explícita durante la presentación del Data Week, como se muestra
después en el mapa que introduce su currículo (véase figura \ref{fig:capacity-building} de la
sección \ref{curriculo}).

Así, el Data Week se construyó sobre dos premisas:

\begin{itemize}
	\item Construir un puente entre el pasado y el futuro de una comunidad, a través de los
	  espacios de encuentro en esta donde creamos juntos, desde un caracter celebratorio y de
	  bienvenida (como algunos de los encuentros previos en las comunidades de software libre,
	  mencionados en el capítulo \ref{prehistoria}.)
	\item Permitir que ciudadanía y estado conversen desde el lenguaje que facilitan los
	  prototipos.  
\end{itemize}

Las siguientes secciones dan cuenta de cómo dichas premisas se consolidaron, tanto desde
las dinámicas comunitarias, como de algunos los artefactos construidos y usados durante ellas,
mientras que el capítulo \ref{prototipos} habla de los prototipos en mayor detalle.

\section{Las ediciones: los ritmos, intensidades, temáticas y productos}\label{dataweek-ediciones}

Debido a su caracter simultáneo de taller y hackatón, el \emph{Data Week} buscaba lograr
un balance entre el aprendizaje guiado, que permitiría asumir los conceptos necesarios
para la exploración autónoma luego, y los problemas abiertos, sin una respuesta preconstruida
para ser enseñada.

El énfasis acá estuvo en mejorar la infraestructura, usando lo desarrollado en la edición
anterior.
Fue particularmente interesante ver como estas prácticas también se podían llevar a un
plano individual, si la experticia estaba ampliamente instalada y fue una muestra más de esa 
relación entre tecnologías informáticas y empoderamiento personal, así como de las dinámicas
ágiles desarrolladas durante las ediciones previas del Data Week.

\begin{figure*}[tbh]
	\centering
	\includegraphics[angle=90,origin=c,width=\linewidth]{./Parte2/dataweek6-blog.jpg}
	\vspace*{-6.5cm}
	\caption[Data Week 6: Entrada al blog]
	{Entrada al blog sobre el Data Week 6, que fue una edición unipersonal, referida a la
		hora del código desde las bibliotecas públicas.
		La gráfica ha sido rotada para mostrar la entrada al blog en toda su extensión,

y expresar en código tales automatismos, además dando paso a la interpretación crítica de los mismos
por parte de los asistentes.
Además, trabajamos el problema de abrir el documento de los 
``Pasos para Una Biblioteca Publica de Bogota'', empleando y extendiendo técnicas similares a las
empleadas para abrir el código fuente del Manual de Periodismo de Datos, y diviendo el grupo en subgrupos
con distintos grados de experticia, pero intercambiando saberes desde ellos.

\begin{figure*}[tb]
	\centering
	\subfloat[Técnicas para activismo de datos]{
		\includegraphics[width=0.45\linewidth]{./Parte2/notebook-techniques.png}
		\label{subfig:notebook-techniques}}
	\quad
	\subfloat[Libreta del aprendiz]{
		\includegraphics[width=0.45\linewidth]{./Parte2/notebook-apprentice.png}

como con temas conyunturales (las elecciones presidenciales), que pueden proyectarse largamente
y construir saberes duraderos desde otras formas de participación ciudadana complementarias a las
más conocidas y que permiten dialogar entre comunidades.
Por ejemplo, los proyectos de esta edición del Data Week fueron mostrados en la edición que se
hizo del evento Datos y Guaros, que articula a comunidades relacionadas con datos, o ``dateras'',
como ellas se autodenominan (se mencionará más de estos eventos de articulación en la sección XYXZ).

La edición 12 del Data Week, se hizo en el Exploratorio de Medellín del 9 al 14 de Abril, 
en el marco de los preparativos para la edición del FLISoL (Festival Latinoamericano de 
Instalación de Software Libre) y retomó los aspectos referidos a documentación ágil y 
resiliente desarrollados en la edición anterior, pero esta vez en otra ciudad e incorporó 
los de lectura anotada, de manera que la memoria más estructurada que se había creado en 
dicha edición pudiera ser anotada por los participantes y que ellos mismos también compartieran 
otros espacios que querían anotar.
La parte de los Data Selfies de Twitter se hizo hacia los últimos días debido a dificultades 
con la instalación de Grafoscopio en Windows, originados en un cambio que hizo la comunidad 
de Pharo al instalador de dicha plataforma por esos días y a algunos inconvenientes con las 
máquinas que tenía el Exploratorio con versiones del sistema operativo Gnu/Linux muy desactualizadas.
Aún así los asistentes mostraron gran compromiso con las actividades y manifestaron comprensión, 
de manera  general sobre los imprevistos de las plataformas donde ejecutaríamos el software 
y participaron de los procesos de publicación de memorias y liberación de datos.

\subsection{Las Data Rodas}

Entre edición y edición de los Data Weeks, que podían estar separadas de uno a tres meses en
promedio, se empezaron a realizar un conjuto de eventos ágiles, para los asistentes de ediciones

	datos. 
	
	[...]
	
	La idea de un dojo como lugar de aprendizaje de la programación llegó a mi después de algo que se llamaba un 
	``code sprint'' con la comunidad de un software llamado Sage, en un evento llamado Sage Days 16, por allá en el 
	2009[1], pues me parecía que era difícil para los novatos adquirir experticia en esos encuentros con otros 
	expertos. El dojo me parecía una mejor metáfora para el aprendizaje que el salón de clase o el ``sprint'' y es uno 
	de los espacios más interesantes y potentes de aprendizaje en los que he estado. Desafortunadamente no escribí 
	nada al respecto (por variar!) y el término fue cooptado por otras prácticas con métaforas como las katas [3] y 
	los kumites[4][5], que enfatizan el aspecto solitario, abstracto y de competencia, en lugar de lo social, lo 
	compartido, el díalogo entre lo básico/puro y lo complejo/aplicado, además de lo lúdico, que es propio de esos 
	espacios de aprendizaje entre pares. Así que para recuperar parte de ese espíritu original, haremos esta primera 
	"Data Roda", con un sabor más festivo y colectivo, como ocurre con la metáfora que tomamos prestada del 
	capoeira[6]. Me parece también que el nombre y la metáfora tienen su encanto ;-).

	sábado de julio para celebrar los cumpleaños de Grafoscopio, reunirnos y
	hacer una Data Roda de carácter más festivo y relajado que las usuales
	(aunque no se nos puede culpar de no ser ni lo uno, ni lo otro, con
	nuestra táctica nado 'e perro, sin prisa, pero sin pausa  ).
	Coincidencialmente ya estuvimos reunidos el último sábado de Julio
	trabajando en estas cosas, por lo que, teóricamente, ya tuvimos la
	celebración, pero no lo supimos ese día, por lo cual sugiero que nos
	reunamos este sábado 5 de agosto para hacer ``oficial'' que el sábado
	pasado estábamos celebrando  (porque lo otro es como estar
	emparejado, pero sin que la pareja sepa!)
\end{quote}

Se hicieron más de una veintena de Data Rodas desde su lanzamiento a mediados de 2016 y 
projectos como el manual ya referido fueron realizados de manera casi exclusiva en las 
mismas durante varios días.
Ellas se constituyeron en tejido que ayudó a articular los esfuerzos entre Data Week y Data Week y,
debido a que no asumían temas iniciales, sino que se hacían con asistentes familiarizados con los
contenidos y dinámicas de tales eventos, se avanzó mucho en la consolidación de proyectos y se
solidificaron las dinámicas desde las Data Rodas, a pesar de no ser tan visibles como las Data Weeks, 
ni tener una página propia (pues no era necesario, ya que se hacía la invitación a ellas se hacía al 
cierre de los Data Weeks).

Incluso cuando otras actividades copan el tiempo de los asistentes habituales (como la escritura
de esta misma tesis), organizamos una Data Roda de vez en cuando, para vernos y mantener las
conexiones.


















\begin{figure}[tbh]
	\centering
	\subfloat[]{
		\includegraphics[width=0.4\linewidth]{./Parte2/indie-web-science.jpg}
		\label{subfig:indie-web-science}}
	\quad
	\subfloat[]{

		\label{subfig:dataweek-12}}
	\caption[Talleres comunitarios]
	{4 Eventos relacionados con el Data Week: 
		[a] Talleres de \emph{Indie Web Science} en HackBo, Bogotá (marzo 2015).
		[b] Data Week 1 en HackBo, Bogotá (junio 2015)
		[c] Data Week 4 en el Colaboratorio, Medellín (julio 2016).
		[d] Data Week 12, en Parque Explora, Medellín (abril de 2018).
		Este formato maduraría y se mantendría evolucionando durante 2 años y medio y
		seguiría vigente al término de esta tesis.}
	\label{fig:talleres}
\end{figure}




Estos formatos ágiles de tienen sus limitaciones y otras propuestas se han realizado desde el otro 
extremo, al proponer eventos mucho más duraderos que el Data Week y en lugar de pasar sus dinámicas 
de un fin de semana a un día, como con las Data Rodas, extenderlo a 6 u 8 fines de semana seguidos,
en la figura de un diplomado, gracias a las configuraciones de la legislación  colombiana \footnote{Particularmente
	el Decreto 1075 del 2015 sobre educación informal, establece las condiciones para este tipo
	de educación no conducente a título.} 
que permiten tal figura y a pesar de que circularon por la lista de 
correo\footnote{ver \url{https://is.gd/diplomado_grafoscopio}}, no se concretaron durante esta 
investigación, debido a los límites de tiempo en la misma.
La intensión específica era la de cambiar largos periodos formativos de años en pregrados, maestrías
y (post)doctorados, conducentes a títulos por periodos más cortos donde en su lugar se creen
portafolios, en este caso, mostrando los conocimientos de los participantes sobre temas de
activimos y visualización de datos.
Una exploración en ese sentido se propone tanto para labores activistas, como educativas, tanto
en contextos no formales, como de investigaciones doctorales y post-doctorales
(ver conclusiones y recomendaciones XYZ).


\section{El currículo}\label{curriculo}

Los hackerspaces son vistos como lugares donde se consolidan comunidades de práctica
desde esta tesis, pues son un ejemplo de esos lugares, que se mencionaban en la primera parte,
donde habitan los diseñadores, junto con las comunidades allí establecidas,
explorando el ``no todavía''.
Desde dicha perspectiva son lugares educativos donde se aprende desde las dinámicas de
enculturación propias de vincularse a dichas comunidades y al igual que como se mencionó

los aprendizajes y la memoria que se estructuraban progresivamente.
La siguiente parte menciona las formas de cosificación creadas durante los Data Weeks y Data Rodas,
por los participantes, así como los canales de comunicación permanentes.
A los prototipos desarrollados, les damos su lugar particular en el capítulo \ref{prototipos}.

\section{Espacios virtuales: Etherpads, Fossil, Lista de correo, Telegram}\label{encuentro-digital}

El software social, en la definición de Tom A. Coates (\citeyear{coates_my_2003,coates_addendum_2005})
es aquel de propicia, extiende y deriva valor de las interacciones sociales.
Este ha sido divido en dos grupos\footnote{La taxonomía entre software social conversacional o dialógico
	la encontré en un wiki, cuyos contenidos no puedo recuperar nuevamente.
	Si mal no estoy se traba de \url{http://wiki.c2.com/}.
	Dicha taxonomía me ha sido útil para encontrar los énfasis en la interacción de un software
	social y por ello la retomo acá.}, 
dependiendo de los énfasis que se tengan: los documentales,

posible para los asistentes de las últimas ediciones, llevarse una copia con la memoria
de todos los eventos desde el comienzo, con una infraestructura sencilla pero potente.

Se emplearon Etherpads\footnote{\url{http://etherpad.org/}}, que son sistemas de escritura 
colaborativa de texto en tiempo real, a los que se unen los participantes con sólo compartir 
un enlace web.
Dichos enlaces, que iniciaban el etherpad, se compartían empleando un acortador de direcciones
ético, que no rastrea a quienes lo emplean, disponible en \hyperlink{https://is.gd}{is.gd}.
Las memorias se fueron organizando de modo que el primer etherpad (o simplemente \emph{pad}) 
se usaba como una índice para los etherpads que guardaban la memoria de cada una de las sesiones 
diarias que constituían el Data Week (o Data Roda).

Debido a la reubicación de algunos miembros de la comunidad a países europeos con otros
usos horarios, la documentación empezó a volverse más estructurada, para facilitar así
la participación remota.

ideosincracias particulares y alejadas de las formas de programación populares más indirectas,
pero también superé dichas expectativas y abracé otras formas de programar que eran más fluidas
gracias al \emph{Live Coding} y la idea del artefácto como currículo que se puede explorar dentro
del artefacto mismo.
Esto ayudó a tender puentes con programadores más experimentados, si bien dichos conflictos fueron
invisibles para los no expertos en programación, que al no tener prejuicios frente a cómo debería
ser la programación no entraban en tales expectativas y hacían comentarios más generales respecto
a los saberes tácitos que todo curso de programación más tradicional presupone y cómo reconfigurarlos
cuando siguen presentes en nuestras prácticas de enseñanza en el Data Week y las Data Rodas, para
lo cual sugirieron la elaboración de glosarios y diccionarios (que se incoporaron en el wiki).
Por ejemplo, el hecho de que Pharo tenga algunas ideosincracias respecto al desarrollo de interfaces
gráficas de usuario en el \emph{Toolkit} Spec, era constrastato con como otros sistemas permiten
empezar con archivos de texto plano en cualquier lugar y crear desde ceros.
Frente a esto se habló de cómo ello creaba dificultades frente a entender las maneras particulares
en que algunas personas organizaban su código y se habían incorporado progresivamente una transión

	\item Re:publica y Global Innovation Gathering (Berlín, Alemania, 2017 y 2018).
	\item Big Data from the South (Cartagena, Colombia, 2017).
	\item ISEA: International Symposium of Electronic Arts (Manizales, Colombia, 2017). 
	\item DataCamp (Kotor, Montenegro, 2017).
	\item Exploratorio (Medellín, Colombia abril de 2018).
	\item Varias ediciones de Datos y Guaros (Bogotá, Colombia desde 2016 a 2018).
	\item Digital Citizen Toolkit Workshop (Kotor, Montenegro, 2018).
	\item Visualizar18 Datos Personales en Medialab El Prado (Madrid, España, 2018).
\end{itemize}

Esto permitió localizar Grafoscopio y sus dinámicas en un entramado que interpelaban
varios colectivos y temáticas: desarrollo de software; visualización de datos; ciencias de
la computación; ciudadanías digitales críticas; estudios críticos de software y datos; 
estudios doctorales y post-doctorales sobre culturas hacker, particularmente las reconfiguraciones 
de dinámicas de investigación y construcción de conocimiento en la perifería y en el diálogo entre 

	tesis retoman y se reelaboran sobre los textos presentado para dicho examen.
	\\
	Mis estudiantes de la cohorte 11B de la Maestría en Didáctica de las
	Ciencias de la Fundación Universitaria Autónoma de Colombia leyeron,
	como una de las actividades de nuestro seminario de software libre y
	educación, borradores de este artículo e hicieron valiosos comentarios.
	}.
	
Grafoscopio realiza varios aportes, dentro del contexto indagar por la modificación recíproca 
entre comunidades y artefactos digitales, desde perspectivas críticas: es altamente cambiable, 
debido a estar realizado en el metasistema Pharo (un sistema hecho en sí mismo),
posee una metáfora uniforme para trabajar a lo largo del entorno (un enfoque objetual
puro), lo cual facilita su aprendizaje y contrasta con otros entornos que mezclan
distintos paradigmas y tecnologías incrementando la complejidad incidental del problema
(aquella que no es esencial del problema, sino de otras cosas como las tecnologías con
las cuales se aborda).
Tiene una perspectiva centrada en el Sur Global desde la apuesta por lo que se llamó
``infraestructuras de bolsillo'' (sencillas, auto-contenidas y que funcionan bien en y fuera de
línea).
Al permitir narrativas computacionales e investigación y publicación reproducibles, realiza un 
puente entre el mundo impreso y el mundo computacional, pues combina prosa, código, texto, datos
y visualizaciones, permitiendo un ingreso de más saberes, además de los desarrolladores de software
o los científicos de la computación.

Se mostrarán las ideas claves sobre los temas relacionados de esta tesis respecto
a la construcción de artefactos autorreferenciales, que complementan las dinámicas
autopoiéticas propias de las comunidades de práctica, y del desarrollo de
software como labor artesanal y desde actos de empoderamiento ciudadano.
Si bien Grafoscopio habita un ecosistema donde otras alternativas parecidas 
existen\footnote{El Manual de Usuario Grafoscopio (\emph{Grafoscopio User Manual},
	\cite{luna_cardenas_grafoscopio_2017}), lista varias de esas alternativas,
	como Jupyter, The Gamma, Zeppeling, TeXmacs, OrgMode y Pollen, entre otros,
	y muestra los parecidos y diferencias con los mismos en mayor detalle.},
ninguna de ellas es pensada desde esta combinación entre alfabetismos y ciudadanías
digitales críticas, artefactos amoldables auto-referenciales y comunidades de práctica
hacktivistas, desde una perspectiva del Sur Global.
Es en esta combinación donde se ubican las principales contribuciones de este artefacto y 
esta tesis y en la forma como ésta configura comunidades y les da posibilidades de expresión, 
sobre y desde la tecnología, desde perspectivas críticas y ciudadanas, como se verá en este 
capítulo y los dos siguientes.

Se considerarán las motivaciones e historia detrás de Grafoscopio, así como
los movimientos conexos al mismo: investigación reproducible, ciencia de garage
y ciudadana, visualización y activismo de datos, objetos activistas, entre otros
y cómo Grafoscopio es un prototipo de software para escritura no lineal y en 
profundidad tanto para la academia, como consecuente con esos movimientos conexos.
Dicho prototipo, por tanto usa estándares abiertos, software libre y repositorios de 
código, para disponer para otros el conjunto de herramientas y datos que permitan mayor 
trazabilidad y transparencia en la construcción de diversos objetos de conocimiento, en 
particular el texto escrito, pero sin limitarse a él.






Puede parecer paradójico que se de cuenta de esas otras formas y objetos de conocimiento, 
precisamente a través de la escritura académica, en artículos indexados y esta misma tesis, 
pero esto habilita un puente entre aquellas prácticas y objetos visibles e invisibles. 
Esta parte del texto, por tanto, es un escrito que reflexiona sobre la escritura
académica, como forma de comunicación y producción por excelencia dentro
de la academia misma y de ella hacia afuera, introduciendo nuevas metáforas escriturales 
y artefactos digitales para re y co construirla y habla precisamente sobre tales metáforas y
artefactos, desde \emph{el interior} de los mismos, pero permitiendo la creación de otros 
artefactos ``externos'', como los textos para someter a publicación, sin limitarse a ellos,
ni validarse exclusivamente mediante la escritura académica.

%Ello permitirá la conexión con los dos capítulos siguientes, referidos a las
%dinámicas que se desarrollaron alrededor de Grafoscopio (Data Weeks, Data Rodas y
%otros encuentros), así como los otros artefactos digitales que se construyeron
%gracias a la interacción entre Grafoscopio y tales dinámicas.


\section{Investigaciones y ciencias otras, objetos de investigación reproducibles y
	activistas}\label{iccag-intro}

Como se apreció en los antecedentes, Grafoscopio tenía la intención de explorar
formas de escribir diferentes, que permitieran amplificar las voces de las comunidades
de base, usando maneras de argumentar desde los datos y las visualizaciones, en particular
en relación con las interacciones entre dichas comunidades y entidades estatales.
Ejemplos de ello se empezaron a avisorar en la Gobernatón y los prototipos de
\emph{Indie Web Science}, antes abordados.
Grafoscopio también tenía la intención de visibilizar los múltiples objetos 
de investigación, de los cuales la academia suele no dar cuenta, debido a las 
prácticas de validación de saberes que privilegian excesivamente lo escrito y la
publicación indexada.

Como se vera en detalle más adelante, estas dos búsquedas tenían una intención común:
construir nuevas metáforas que a su vez permitiesen adquirir nuevos alfabetismos
sobre escritura, mediada por código, datos y visualización, lo que, a su vez, 
permitiera re y co-construir la metáfora original: \emph{cambiando así el artefacto que nos cambia}.
En ese sentido las elecciones hechas, por ejemplo, que el texto se presente como un árbol,
son temporales y puntos de partida para reconfigurar y desplegar dichas elecciones nuevamente.

Distintas iniciativas, colectivas e individuales están deconstruyendo y reconfigurando las
prácticas con las cuales se apropia, produce y comunican saberes. 
Se agrupan bajo distintas denominaciones, como investigación y ciencia abiertas, 
ciencia de garage, \emph{research object}, \emph{activist object} 
(se hará referencia a ellas de modo colectivo con la sigla ICACG), complementado y en muchas 
ocaciones contrastando críticamente las maneras y lugares hegemónicos desde los que se realizan 
las labores de apropiación, producción y comunicación de saberes al interior de la academia y se 
repiensan los pactos entre esta y la ciudadanía. 
Pues, como diría \cite{lafuente_critica_2013},
``la divulgación no es el único pacto posible entre ciencia y sociedad''.
Podemos, entonces, imaginar tránsitos de doble vía de saberes y comunicación, que también 
van desde la ciudadanía hacia las instituciones científicas para revertir esa lógica
donde las comunidades son vistas como simples ``objetos de estudio'' y se convierten
en ``sujetos estudiosos'' y donde en tampoco son ``usuarios finales'' de lo que la 
ciencia produce y es mediado por el mercado y entregado a ciudadanos y comunidades vía la
tecnología.
Los colectivos y e individuos, en su caracter de académicos vinculados a las instituciones, 
como ciudadanos fuera de ellas, o en algún lugar intermedio, están pensando en maneras distintas 
de comunicar las respuestas que saberes académicos tradicionalmente se han hecho, de colocar 
nuevas preguntas en la intersección entre saberes o de abordar de manera más horizontal y 

emergentes, los lugares donde las deficiones y prácticas se consolidan sean principalmente 
sitios en línea, sin publicaciones canónicas fruto del acuerdo, aunque eso sí, muchas 
iniciativas cuentan con el respaldo de prestigiosas instituciones académicas y con intereses 
en las prácticas que ocurren tanto en el Norte Global, como en el Sur Global.
Consideraré en este apartado algunas definiciones, a fin de dar una mirada panorámica 
e introductoria al fenómeno, sin ahondar en los diálogos críticos alrededor del mismo.

La \cite{wikipedia_open_2014} menciona como la investigación abierta es cercana a los espíritus
del software libre y de código abierto y así como el código fuente se hace disponible en









de manera abierta en los primeros, en la última la metodología de investigación se abre,

facilitando tanto en el software como en la investigación la colaboración.
La Wikipedia también menciona que si bien la investigación puede referirse a hechos factuales



de los que se ocupa la ciencia exactas y naturales (llamándose ciencia abierta), la investigación

abierta también puede cubrir temas periodísticos, humanistas y médicos entre otros.










La ciencia abierta es, entonces, un subconjunto de la investigación abierta, que involucra 
varios campos científicos.
Sin embargo la investigación abierta va mucho más allá de los campos científicos.

En nuestra experiencia en los Data Weeks y Data Rodas y otros encuentros,
fue recurrente la presencia de periodistas interesados por el campo
del periodismo de datos, activistas de derechos humanos en entornos digitales,
libertad de expresión, memoria y privacidad, entre otros.
Incluso hay un tema de investigación reproducible, %PENDIENTE: 
que se deriva de la investigación abierta y que pretende que las
afirmaciones hechas en la investigación puedan ser contrastados y
extendidos por cualquier lector o coinvestigador.
En el caso de Grafoscopio, como veremos en los prototipos del capítulo %PENDIENTE
este permite acceder a infraestructura para investigación reproducible que
es de bajo costo y altamente portable y poderosa, útil a todos los perfiles
antes mencionados..

Por otra parte, el proyecto del \cite{research_object_research_nodate} menciona
com los resultados de investigación ``no son sólo publicaciones


tradicionales [sino] todo lo demás que entra en y soporta una investigación''

y mencioa cómo el hacer esa diversidad de objetos legibles por máquinas permite

que la investigación sea reutilizable, interesante y novedosa y menciona un 




conjunto de principios comunes de las distintas iniciativas de objetos de investigación

que los haría más ampliamente interoperables y reutilizables.













Dichos principios son, según el sitio de \cite{research_object_research_nodate}:

\begin{quote}
	\textbf{Identidad}: Usar identificadores globalmente únicos como nombres
	para las cosas. Por ejemplo DOI's para publicaciones o ORCID para
	investigadores. Esto es por dos razones:

	\begin{enumerate}

La sección de prototipos, particularmente el Manual de Periodismo de Datos, muestra cómo
esas otras formas de publicar pueden hacerse posibles en la práctica.
También piensa las infraestructuras activistas, pues surge de necesidades sentidas respecto
a la creación de capacidad en comunidades de base desde HackBo, tanto en sus saberes, como
en las materialidades que los soportan, como se verá en los capítulos del Data Week y los
prototipos del Portal de Software Libre y los Data Selfies de Twitter.

Sobre la ciencia de garage \cite{critical_art_emsamble_ciencia_2009} dice, que se trata


de un término ``rebosante de posibilidades utópicas; sin
embargo, a diferencia de otras florituras retóricas utópicas, la forma
de producción que describe puede tener un impacto revolucionario en el
paisaje de la vida cotidiana''. 

Dentro de él caben los mitos fundacionales de científicos solitarios y geniales inventando 
en su garagje la bombilla o el computador (un mito que se ha demostrado falso en la mayoría
de casos\footnote{Para el caso del computador personal, la invención estuvo lejos de
	ocurrir en solitario y en los garajes del Valle del Silio.
	Por el contrario, fue una historia de influencias diversas, si sólo contamos la tradición
	norteamericana, como da cuenta \cite{maxwell_tracing_2006}} en \emph{Tracing the dynabook}.),
pero sobre todo caben las personas cotidianas que están en condiciones de interlocutar
con el poder desde los lugares cotidianos (como los garajes), en lugar de la ciencia como aquello
exclusivo de los espacios cerrados de la academía y los dominos cerrados de los académicos.






Por supuesto, los planes de popularización de la ciencia encontraron resistencia neoliberal
y ahora nos encontramos frente a una tensión dialéctica por reabrir la ciencia desde iniciativas
ciudadanas, ya sea que estas cuente o no con el apoyo del gobierno.



Esta tensión se expresa en palabras de \cite{critical_art_emsamble_ciencia_2009}:

\begin{quote}
	No hace falta decir que cuando los neoliberales llegaron al poder se
	dieron cuenta rápidamente de que había que parar esta forma de política,
	y la mejor manera de hacerlo era detener toda manifestación de ciencia
	amateur. Creían que la gestión y el desarrollo del conocimiento debían
	llevarlo a cabo pequeños grupos de ``expertos'' que compartían los
	valores ideológicos del neoliberalismo, de forma que el conocimiento y
	su aplicación pudiera ser controlada únicamente de arriba abajo.

	{[}\ldots{}{]}

	Para Critical Art Ensemble parte de nuestra lucha ha sido establecer la
	ciencia como un lugar popular para la intervención cultural, y de ese
	modo contribuir a una pedagogía que otorga poder a la gente para retar a
	los expertos, para convertirse en activos participantes en las políticas
	del conocimiento de las esferas científica y tecnológica, y expandir las
	posibilidades para la producción cultural en las disciplinas
	científicas.
\end{quote}

Una posibilidad similar hemos visto desde HackBo, cuando participamos desde
infraestructuras como Grafoscopio en debates sobre asuntos públicos o cuando
deconstruimos investigaciones de Big Data haciéndolas accesibles para muchos
(el capítulo \ref{prototipos} lo muestra en detalle).
Estamos haciendo posible que el ciudadano participe del debate, rete al experto
o muestre que esta no es una esfera cerrada y que, por el contrario, puede
incluir voces diversas.

Por su parte, \cite{lafuente_amateurs_2014} conecta a la ciencia ciudadana con
el movimiento hacker cuando dice que este movimiento resistia la corporatización






del saber, pues era tan absurdo como privatizar las leyes de Newton o los teoremas
matemáticos y conecta este movimiento con otros movimientos e iniciativsa, como




la Wikipedia, los Creative Commons, el movimiento punk y de hecho muestra una
perspectiva similar a la de Wark, Coleman o Schrock, antes vistas, cuando plurariza
el fenómeno hacker y lo conecta con diferentes sujetos y maneras de hacer conocimiento:




\begin{quote}
	La cultura hacker pronto resonó con la cultura punk. Ambas daban forma a
	los anhelos anticonsumistas, antimonopolistas y antielitistas. Ambas
	representaban una apuesta por la cultura del DIY, las formas
	cooperativas, las prácticas de garaje y la innovación maker. Hace ya
	cinco décadas que su presencia no deja de contagiar el mundo de los

%prototipo), para finalmente dar cuenta de las conclusiones y
%posibilidades futuras de este ejercicio de prototipado y primera
%aproximación investigativa al problema.

\section{\emph{Bootstrapping}: condiciones mínimas para jalonar la complejidad}\label{bootstrapping-condiciones-muxednimas-para-jalonar-la-complejidad}

Estas fueron las condiciones mínimas que se prefijaron, antes de que el
ejercicio de escritura académica del borrador de este capítulo se hiciera
dentro de Grafoscopio:

\begin{enumerate}
	\def\labelenumi{\arabic{enumi}.}
	\item
	Interface gráfica arborea:
	\item
	Modelo de persistencia de información.

comentarios, estructuración o para la exportación a diferentes formatos
y/o la publicación de la historia en repositorios de código. 
Es decir que las condiciones 1 a 3 fueron prerrequisitos para iniciar con la
exploración de la condición 4 y una vez esta se tuvo se itero sobre las
condiciones anteriores: las condiciones mínimas del prototipo permitían
ejercicios de escritura que a su vez servían como base para mirar qué
había que cambiar en el prototipo, de modo que el proceso de escritura
entre el prototipo y el borrador del texto se fuese realimentando, afinando
y mejorando.

El entorno Pharo/Smalltalk propicia el \emph{bootstrapping}, pues integra dentro de sí un
lenguaje de programación mininalista, un poderoso ambiente integrado de desarrollo y una 
interface gráfica.
La experiencia de usuario inicial es sólo descargar, decomprimir y usar, sin ningún tipo de 
privilegio particular\footnote{A diferencia de Leo, que es difícil de instalar en 
	plataformas no Gnu/Linux, y puede requierir de permisos de administrador en la máquina.}.
En Pharo se pudo recrear mucha de la experiencia de escritura arbórea básica con Leo, 
mencionada en  la sección \ref{indie-web-science} y se delegó el resto de la misma, en 
particular la creación de PDF, a plataformas completas instaladas localmente, específicamente
Pandoc y \LaTeX, el cual tiene una amplia tradición  en la creación de PDF de alta calidad 
(el Manual de Periodismo de Datos y el Manual de Grafoscopio, en el capítulo \ref{prototipos}, 
son muestras de cómo esta combinación entre Grafoscopio, Pandoc y \LaTeX es usada en la creación 
de documentos).

y bifurcaciones y de los componentes que permiten la recombinación y el metabolismo cognitivo
a partir de los mismos.
Las subsecciones abordarán en detalle cuáles son los alcances de Grafoscopio y dónde este
se ubica en un ecosistema de aplicaciones similares, relacionadas con temas de investigación
y publicación reproducibles, así como narrativas y visualización de datos.

La idea de los metasistemas y la autorreferencialidad, se esbozaba desde el 2010 y comienzos
del 2011, en una conversación cara a cara con Wolfgang Jonas y se retomó y mostró en el examen de candidatura de 2014 (véase figura \ref{fig:candidatura-detalle}) %NOTA: Jonas scroll?.
Se hablaba de dos ``mantras'' de la computación en paradigmas distintos, que marcaron puntos
de bifurcación a comienzos de la misma.
Por un lado estaba la tradición y el mantra de ``todo es un archivo'' y  la Smalltalk y el mantra de 
``todo es un objeto''.
A su vez se tienen implementaciones de metasistemas en dichas tradiciones:
Con Leo teníamos un (meta)archivo (arbóreo) que integraba y hablaba de otros archivos 
(usualmente externos a Leo) y con Pharo/Smalltalk teníamos un entorno de (meta)objetos 
que integraba y hablaba de otros objetos (usualmente internos a Pharo/Smalltalk).
Dichas tradiciones a su vez fortalecieron caminos paraleos: en de los archivos y las
aplicaciones, propio de la tradición Unix y sus derivados (incluidos Windows, Mac y Gnu/Linux)
y el de las simulaciones y las meta-herramientas, propio de Smalltalk.
Mientras el primero estaba orientado a ``usuarios finales'', que usan aplicaciones para crear
documentos, el segundo estaba orientado a programadores que usan meta-herramientas para crear
otras herramientas o aplicaciones y ``software educativo'', para jóvenes y niños que usan la
simulación para expresar y desarrollar el pensamiento.

		Leo y de Smalltalk.
		A pesar de su caracter de intuición temprana, dicha idea cristalizaría 3 años después
		(y tras una primera pausa de año y medio en el doctorado) en Grafoscopio.
		Para la gráfica completa ver \ref{fig:candidatura}}
	\label{fig:candidatura-detalle}
\end{figure}

La primera intensión de Grafoscopio era juntar estas dos tradiciones ofreciendo un modelo
en el cual los objetos representan archivos, que son documentos arbóreos interactivos para hacer
narrativas computacionales.
Grafoscopio une estas dos tradiciones al ofrecer herramienta para documentar, simular y visualizar,
que son ``internas'' del entorno Smalltalk, pero que pueden producir documentos ``externos'' al mismo
y con un público objetivo que no se centra en niños, jóvenes o programadores profesionales, 
sino que incluye activistas, periodistas, comunicadores, filósofos, investigadores académicos,
químicos farmacéuticos, microbiólogos, bibliotecarios, entre otros (considerados a partir de la 
población que ha asistido a los talleres del \emph{Data Week}, como se detalla en el capítulo \ref{dataweek}).

el lugar de este software en medio de las otros similares, las ideas de las cuales se inspira y 
las apuestas de valor agregado del mismo.

Otra tradición importante que Grafoscopio recoge es la mirada tecnopolítica del Software Libre,
pues se acoge a una de las licencias que lo cobijan (la MIT) y explicita en muchos de los
talleres que se hicieron la idea de la tecnología digital como una manera de hacer viable (o no)
la idea del conocimiento como bien común.
También expresa las tensiones que estas otras formas de pensar el derecho de autor enfrenta,
pues si bien el código es MIT, su manual (\cite{luna_cardenas_grafoscopio_2017}) emplea la 
licencia de producción entre pares, que alienta relaciones cooperativas y no coloca el usufructo 
de la creación comunitaria y de los comunes en igualdad de condiciones para todos, sino que realiza 
una discriminación positiva para cooperativas y cooperantes.

Es precisamente en los problemas que se abordan y los prototipos que se crean donde se pueden
explicitar estos puentes entre tradiciones y bifurcaciones, tratados anteriormente.
El capítulo \ref{prototipos} detalla varios de los constructos creados con Grafoscopio que 
cristalizan dichos puentes, mientras que la siguiente sección detalla este proceso de construcción
de Grafoscopio, mostrando las apropiaciones conceptuales y tecnológicas necesarias para su desarrollo
y pormenoriza la apropiación de la cultura material detrás de estas formas de desarollar el software,
desde los primeros prototipos a los mejoras en los mismos y las condiciones mínimas para avanzar
en el desarrollo.

%PENDIENTE: Conclusiones
% infraestructuras de bolsillo como forma de decolonizar la infraestructura.




\subsection{Una aproximación artesanal y sus alcances}\label{grafoscopio-alcances}


Grafoscopio se desarrolló durante casi tres años y medio hacia el término de esta tesis y 
todo parece indicar que se continuará desarrollando después, debido a los usos actuales y
potenciales del mismo, no sólo en los contextos locales, sino internacionales (en ese sentido 
ya se superó la idea de una ``tesis de anaquel'', mencionada en el Prefacio).
El desarrollo de este  software no es cercano a practicas ingenieriles tradicionales,
sino que se enmarca en la idea de aprendizaje como un acto de enculturación en una comunidad
de práctica (\cite{wenger_communities_1999}), en este caso la de las comunidades alrededor de 
Pharo, de la que se hablará más adelante y del software como artesanía (\cite{blackwell_craft_2015}),
de la que nos ocuparemos acá.

Desde dicha aproximación, el software embebe y encarna conocimiento crítico de su autor y es un 
``material recalcitrante'' (\cite{blackwell_craft_2015}), con el que dialogamos y que nos permite 
investigar a través del la práctica reflexiva, muy en línea con las perspectivas, explicitadas en
la primera parte, de los saberes diseñísticos y sus metodologías, así como aquella del investigador
en diseño como sujeto  político, los objetos activistas y la transparencia como forma de rigor 
investigativo, en lugar de la supuesta neutralidad o reproductibilidad para todo contexto.
Se trata más bien de tener una reproductibilidad contextual abierta a la reinterpretación constante,
facilitada no sólo gracias al acceso al código fuente, sino a las prácticas educativas comunitarias
permanentes, donde este saber se apropia y se cambia.

La materialidad del software, mencionada por \cite{blackwell_craft_2015}, permitiría establecer
diálogos y prioridades, dejando que el material nos guíe, específicamente en la relación de
dichas materialidades y las comunidades alrededor de ellas.
Según tales autores (p, 2-3):

\begin{quote}
	Las herramientas prácticas artesanales han `evolucionado' para adecuarse a la mano
	experta a través de generaciones de uso --- de hecho, `co-evolucionaron' porque el
	entrenamiento artesanal procede junto con las prácticas reflexivas de hacer y adaptar
	las herramientas propias.
	Podría entonces esperarse que la artesanía del software estuviera parcialmente `encarnada'
	en las herramientas de programación que codifican las prácticas expertas evolucionadas, tales
	como el prototipado, la modelación y el \emph{refactoring}.
	
	[...]
	
	La comprensión del software como materialidad inicialmente parece contraintuitiva, por el
	hecho de que el software es por supuesto inmaterial.
	Sin embargo, podemos usar la comprensión de la materialidad en la interacción (Gros et al 2013)
	para observar que el código es usualmente un medio recalcitrante, que ofrece resistencia
	a la manipulación por el programador, en la misma panera que lo hacen los materiales mediales
	de la práctica artística.
\end{quote}

\begin{figure*}[tbh]
	\centering
	\includegraphics[width=\linewidth]{./Parte2/software-as-craft.png}
	\caption[El software como artesanía]
	{El software como artesanía. Trozo del mapa mental empleado en el Data Week en el que se
		habla del software como artensanía que embebe saberes de sus creadores y usuarios,
		respecto a herramientas previas que han servidor como inspiración, respecto al conocimiento
		como un derecho y la tecnología como una forma de encarnarlo y las búsquedas conceptuales
		respecto a los computadores como artefactos cognitivos, como medio expresivos y las metáforas
		subyacentes detrás de la informática.}
	\label{fig:software-artesania}
\end{figure*}


Fue así como durante el desarrollo de Grafoscopio se tuvieron momentos frenéticos con exploración 
intensiva de las posibilidades y prioridades (particularmente al comienzo) y también ritmos 
más sosegados, logrados gracias a la interacción con la naciente comunidad de Grafoscopio.
El prototipo, avanzó como decimos en dicha comunidad, ``sin prisa, pero sin pausa'' y no buscó
una experiencia absolutamente fluida y limpia, sino que se entregó un prototipo
funional básico que satisfaciera las condiciones mínimas enunciadas en la sección
\ref{bootstrapping-condiciones-muxednimas-para-jalonar-la-complejidad}, para que fuera la
interacción entre prototipo y comunidad la que dictara las prioridades siguientes, en
concordancia del prototipo como hipótesis y los ciclos de realimentación de la investigación
en diseño, teorizados por \cite{teemu_leinonen_software_2008}, referidos al final de la
primera parte: indagación contextual, diseño participativo, diseño de producto y software como 
hipótesis.

Como se ha comentando previamente, ya había una experiencia preliminar del autor con algoritmos,
lenguajes de \emph{scripting}, programación y e incluso modelación computacional, empleando 
la variante Squeak de Smalltalk.
Sin embargo Grafoscopio fue el primer prototipo desarrollado (por el autor) en la variante Pharo 
de Smalltalk y de hecho la primera aplicación de usuario, que brindaba desafíos distintos de 
las experiencias previas, debido a que sus demandas iban más allá de ejecutar un sencillo

al lenguaje de etiquetamiento ligero Markdown para dichos elementos de formato y se confió en
que esa interface sencilla, unida al valor diferencial del software como otra manera de organizar
el texto y vincularlo con visualizaciones, fuera suficientemente llamativa para los miembros
de la comunidad que quisiera continuar usando el software.

Los lenguajes de domino específico (DSL, por sus siglas en inglés) para el procesamiento de
texto y la visualización de datos también fueron surgiendo de manera emergente de acuerdo a
la necesidad y han continuado afinándose en eventos locales e internacionales en los
que son requeridos.
La escritura, el desarrollo y compresión explícita de los DSL es parte de las intensiones de
uso detrás de Grafoscopio y no se espera proveer metáforas visuales que los oculten o hagan
que los usuarios no se enfrenten a este aspecto del código.
Sin embargo, si se espera mejorar la Interfaz Gráfica de Usuario (GUI, por sus siglas en inglés),
de modo que el trabajo con toda la funcionalidad de Grafoscopio, incluidos los DSL sea más
fluida.

La integración el y jalonamiento desde Pharo de otras herramientas (Fossil, \LaTeX, Pandoc)
es parcial, pero cada vez mejor; no se aborda su uso como servicios en Internet; y muchos
de los elementos restantes para producir el PDF deben ser instalados localmente en la máquina 
donde se trabaja el documento y para dar cuenta de su historia vía Internet la configuración
en  línea se hizo manualmente, gracias a repositorios en Fossil, además se desarrollo una
funcionalidad puente entre Fossil y Grafoscopio.
En ese sentido, no está dentro de los alcances presentes del prototipo el ser complemente 
portable, ni multiplataforma, y por lo pronto permite de modo autónomo sólo la escritura,
(re)organización del texto en la interface gráfica y su exportación al formato ligero Markdown,
mientras que apela al software externo Pandoc para la conversión a HTML y junto con \LaTeX
se puede realizar la exportación a PDF.

Se espera que futuras versiones del software integren los elementos faltantes y puedan 
jalonarlos de maneras progresivas, de acuerdo a las necesidades de la comunidad y los recursos
para ello, siguiendo con la idea de poner a circular e iterar prototipos mínimos y funcionales

			La visualización ágil es acerca de usar los recursos computacionales
			para agrandar la mente y las capacidades cognitivas de nuestro cerebro.
			Crear una visualización a la medida, en ciclos extremadamente cortos de
			producción es lo que caracteriza las ténicas de visualización,
			presentadas en este libro.
			[...]
			La visualización ágil esta hecha para científicos de datos, periodistas,
			científicos computacionales e ingenieros de software. Tan pronto usted
			necesita procesar datos, numéricos o no, la visualización ágil lo guiará
			paso a paso para fertilizar sus datos
		\end{quote}
\end{itemize}

Una vez decido que se usaría Pharo, la exploración inició con las interfaces gráficas 
que servirían para el proyecto. 

cargarlos dentro de Pharo de nuevo.
Así, cada nuevo objeto definido, como los nodos del árbol, que representan las libretas interactivas
de Grafoscopio, fueron mapeados en archivos de texto plano, para que pueden ser compartidos con 
sólo enviarlos por correo, versionados fácilmente para guardar su historia y cargados de nuevo 
en Grafoscopio para continuar con su edición visual e interactiva.
Las inquietudes principales fueron referidas a si se podía representar el texto incluidas los saltos 
de línea de manera que no ocuparan líneas largas con caracteres especiales (como \texttt{\textbackslash{}n})
y cómo quitar algunos metadatos del texto, como la fuente, el color, etc. de manera que su representación
se mantuviese sencilla.
La resolución de ellas, por el propio autor de STON, permitió un formato altamente eficiente
y amigable para la producción de documentos estructurados en este esquema arbóreo\footnote{ 
	Por ejemplo, el código fuente del Manual de Grafoscopio ocupa 140 kb para un documento de PDF
	de 60 páginas y 1.9 Mb, y el código fuente del Manual de Periodismo de Datos ocupa
	cerca de 600 kb para un documento PDF de 13 Mb y 316 páginas.
%	 lo cual muestra la eficiencia del

capítulo y habilitó la de otros documentos, como los manuales y tutoriales interactivos, 
desarrollados a lo largo de la investigación (véase figuras \ref{fig:versiones-grafoscopio},
\ref{fig:joss-grafoscopio} y capítulos  \ref{prototipos} y \ref{materialidades}).
La escritura de tales documentos y visualizaciones permitió afinar la funcionalidad de 
Grafoscopio, la documentación y de las prácticas de aprendizaje y comunitarias alrededor de 
ellos, siguiendo los ciclos de realimentación ilustrados en la figura 
\ref{fig:realimentacion-artefacto-escritura}.
Es decir, en la medida en que se contaba con un software mínimo para escribir, se empezaba
la escritura de un texto (por ejemplo el borrador de este capítulo) para mirar las limitaciones
del software y sus consecuentes extensiones, con lo cual el software modificado, cambiaba las
mecánicas y posibilidades de la escritura, por ejemplo añadiendo nodos de ideas que no eran
capítulos o nodos invisibles.
Esta realimentación entre el software de escritura y (d)escribir el software dentro de sí mismo
genero este ciclo virtuoso en el diseño del prototipo.
Una descripción detallada de este proceso está en el apendice \ref{materialidades}, debido a su 
caracter clave durante toda esta investigación y sus repercusiones en otras investigaciones y 
prácticas comunitarias venideras.

\afterpage{
	\begin{figure*}[tbh]
		\centering
		\subfloat[]{

	exportar a distintos formatos (HTML y \LaTeX).}.

En paralelo se montó, desde mediados de 2014, un primer repositorio de código 
fuente\footnote{\url{http://mutabit.com/repos.fossil/grafoscopio/}}  que contiene las versiones
históricas de la documentación sobre Grafoscopio como manuales, tutoriales, artículos etc., en
distintos formatos: STON con metadatos, etiquetas ligeras Markdown/Pandoc o PDF.
También se incluye en dicho repositorio otro material integrado al mismo, como gráficas y 
figuras y archivos de citación bibliográfica, que permiten rastrear la historia de tales 
recursos y cómo se vinculan entre sí.
De este modo, los textos allí hospedados son consistentes con los principios de trazabilidad
y reproducibilidad de la ICACG, acá mencionados, permiten la participación desde dinámicas
comunitarias y facilitan un puente entre estas y otras prácticas académicas de frontera respecto
a artículos de software que se pudieran someter a revisión de pares y publicación.

Por ejemplo, el sitio web de Grafoscopio (\cite{luna_cardenas_grafoscopio_2014-1}\footnote{\url{http://mutabit.com/grafoscopio/}}, 
véase figura \ref{fig:grafoscopio-web}) surgió como una página web de bienvenida, que brindara 
una primera información importante y panorámica sobre el mismo.
Grafoscopio, según su sitio web, es una herramienta amoldable para investigación y publicación
reproducible y para narrativas computacionales que combinan prosa, código, datos, y visualizaciones,
usada en campos diversos, entre los que están el activismo de datos, las visualizaciones de dominio
específico y ejercicios de ciudadanía digital.
Puede ser ejecutada en una amplia varidad de software, desde memorias USB hasta computadores modestos



y servidores.
El sitio web también contiene enlaces a manuales, documentación, muestras de lo que es posible 
y canales de comunicación, soporte y vinculación comunitarios, así como enlaces al código fuente
tanto del software como de la documentación.

\begin{figure*}[tbh]
	\includegraphics[width=0.7\linewidth]{./Parte2/grafoscopio-web.png}%
	\caption[Parte de la página Web Grafoscopio]
	{Parte de la página Web Grafoscopio en \url{http://mutabit.com/grafoscopio/}.
		Dicha página tiene también una versión en inglés en \url{https://is.gd/grafoscopio_e}.
		Sin embargo, las versiones más actualizadas se hacen primero en español,
		suguiendo una apuesta por priorizar lo local.
		Tomado de \cite{luna_cardenas_grafoscopio_2014-1}.}%
	\label{fig:grafoscopio-web}%
\end{figure*}

%PENDIENTE > Conclusiones: Priorizar lo local

Por otro lado la publicación del artículo indexado titulado 
\emph{Grafoscopio: A moldable tool for literate computing and reproducible research},
publicado en el \emph{Journal of Open Source Software} (JOSS), fue escrito pensando en dinámicas 
académicas innovadoras que vayan más allá del artículo indexado ``clásico'' y empiecen a mostrar
otros objetos no hegenónicos de conocimiento, para los cuales la descripción en palabras, no
sólo es insuficiente, sino incompleta e inadecuada comparada con otras formas de publicación
disponibles, como las del software mismo\footnote{Obsérvese acá que la crítica no es a la
	escritura como objeto profundo, sino a la publicación académica indexada actual,
	que no muestra muchas de las profundidades de esa escritura, ni valida otros objetos
	en los que el texto escrito en prosa no es la forma principal de expresión del conocimiento,
	por ejemplo el software, los ensayos sonoros y otros.
	Esta crítica a las actuales formas de publicación se han unido ya varias voces que hablan
	de diversificar aquello que es publicable e indexable, como una forma de diversificar las
	voces y sujetos que participan de los ciclos de la ciencia y la investigación.}.
Como se dijo al comienzo del capítulo, es una muestra de que las prácticas ad-hoc referidas
al objeto de investigación y la investigación reproducible, en particular de indexación e
identidad, pueden cristalizar, a través de Grafoscopio, en objetos más formales que hacen
parte de los ciclos de publicación internacionales y las prácticas de frontera emergentes
en dichos ámbitos.

\begin{figure}[!tbh]

diálogo con las comunidades locales del hackerspace y ayudar a consolidarlas.
Dichas actividades comunitarias, realizadas a partir de un prototipo mínimo funcional,
permitieron afinar el prototipo y mejorarlo a lo largo de este tiempo, brindaron un
sentido de ritmo e importancia sobre lo que era fácil o díficil, adecuado, aplazable y 
venidero en términos de las modificaciones del prototipo y conectaron acciones y comunidades 
locales con globales, gracias a la participación en eventos y comunidades nacionales e 
internacionales.

\section{Prototipos como formas de vincularse a comunidades y conformarlas}

Hemos visto como una pregunta llevó a un acto de apropiación cultural dentro de una comunidad
de práctica (la de Pharo y Smalltalk), que permitió explorar y expresar búsquedas sobre lo
escritural, sobre las relaciones entre artefactos digitales y conocimiento, sobre los datos
y la forma de contar historias, sobre las infraestructuras que permiten participar o no en
dichas posibilidades.
Estas exploraciones ocurrieron primero a nivel personal, apropiando las materialidades y
rituales propios de dichas comunidades, y luego se pensaron en maneras de tejer puentes, de
doble vía entre preocupaciones locales que podrían ser expresadas por artefactos como Grasfoscopio,
y formas comunitarias de hacer y aprender.
Los prototipos comunicaron maneras de pensar el software desde lo artesanal y su
creación como un acto de enculturación comunitaria, así como maneras de expresar compresiones
y materialidades progresivamente más detalladas que permitieron construir los prototipos
y desde ellos participar de otra maneras de publicar tanto localmente en forma de Manuales
y otros prototipos como en publicaciones indexadas internacionales, en últimas reconfigurando
los espacios desde los que se hace y apropia la investigación y se participa de ella e
incorporando formas de intervención en los circuitos clásicos de construcción pública de
discurso político o académico desde las premisas de la Investigación y Ciencia Ciudada Abierta
y de Garaje (ICCAG) y concretando maneras específicas en que los artefactos amoldables desarrollados
por y desde las comunidades en espacios del Sur Global como hackerspaces permiten esas otras
voces y posibilidades.
A su vez, estos prototipos no sólo expresan conocimiento detallado de una materialidad,
sino una recombinación de ideas de distintas tradiciones (Unix, Dynabook, ICCAG, objetos
activistas, ciudadanías digitales e investigación y publicación reproducibles).
Es precisamente la posibilidad de recombinar varias tradiciones del pasado y conectarlas
con movimientos y preocupaciones del presente y el futuro lo que da cuenta del caracter
polisémico de Grafoscopio y muestran una de las posibilidades de las epistemologías
del diseño por la exploración de mundos posibles (o futuralidades de Escobar).
Grafoscopio es una manera concreta de hablar de aquello que se enunciaba de modos
más teóricos en la primera parte, lo cual implica conectarse con las materialidades
subyacentes en la tecnología, pero también pensarlas más allá de las ciencias de la
computación o una perspectiva positivista del mundo y el código para mirarlas desde
discursos críticos en diseño.

Espero que este capítulo lo haga más claros los aportes de Grafoscopio: se trata de
un artefacto altamente interactivo, flexible y modificable por sus usuarios, con mayor 
facilidad que otros entornos debido al entorno continuo e integrado que habita (el metasistema Pharo).
Los parecidos con otras tecnologías para narrativas computacionales y visualización de datos
se establecen acá, así como sus diferencias (específicamente la alta modificabilidad interactiva
y continuidad del entorno).
Pero los aportes más importantes de Grafoscopio están en poner dicha tecnología en diálogo
con comunidades de base para amplificar sus voces, permitiéndoles participar de maneras
diferentes de la construcción del discurso público y problemas complejos, por un lado
y por otro desde su diálogo con perspectivas de diseño donde la recombinación de distintas
tradiciones es importante para diseñar y donde los ciclos de realimentación considerados
en la metodología del software como hipótesis permiten diseñar entre, con y para una comunidad
de base (en este caso la congregada en HackBo) y también que las apropiaciones individuales
sobre el software y sus materialidades permita convocar a comunidades más amplias alrededor
de las propuestas que cristalizan en ese software.
Es decir acá el software no sólo es un prototipo que comunica un saber y apuestas individuales,
sino que convoca y permite construir colectivos alrededor de las mismas, para revisarlas y
modificarlas.

Esas dinámicas humanas alrededor de los artefactos, serán el motivo del siguiente
capítulo.

\clearpage

\begin{figure*}[tbp]
	\centering

	los cuales se constituye presentan un desafío. Las historias que nos han dicho acerca de los
	hackers hacen difícil resignificar este sujeto de poder de nuevo. Desde 
	1980, la imagen de los hackers ha dominado mundos ficticios y semificticios de
	la escritura y cinematografía. Nuestro focus acá, sin embargo, es atrapar las aperturas
	que los `actos de hacking' han creado.}
{-- Isin y Ruppert, Being Digital Citizens }

La apuesta por la investigación basa en diseño, desde la perspectiva de Leinonen,
mostrada en la sección de metodología (véase página \ref{metodologia}), implica
dar cuenta de la indagación contextual, hecha desde la comunidad.
Esto se hará en clave etnográfica, abordando la cultura hacker desde dos lugares:
por un lado desde cómo esta toma cuerpo en en mí como investigador y sujeto político,
trazando la historia de mi pertenencia a dichas comunidades; y por otro desde como
dicha cultura encarna en el hackerspace HackBo, donde esta investigación ocurre,

caracterizando maneras de hacer en la comunidad de práctica y colocando lo anterior en 
diálogo con perspectivas teóricas y críticas que dan cuenta del fenómeno hacker como una 
definición abierta que puede ser leída como práctica ciudadana y cotidiana.

Si bien se tocarán algunos prototipos de manera tangencial, en énfasis en los mismos
se hará en el capítulo siguiente, que mostrará las sucesivas interaciones de los ellos,
en el contexto comunitario e interpersonal antes mencionado, dándo cuenta así de los
procesos de investigación no líneal mencionados por Leinonen, en los que la indagación
contextual en comunidad, pasa por ciclos de trabajo por expertos, que luego producen
prototipos que regresan a la comunidad.

\section{Mi lugar en la comunidad}\label{mi-lugar}

La metodología de esta investigación, al igual que algunas mencionadas en la primera
parte, está \emph{informada} etnográficamente (sin ser del todo una investigación
etnográfica) y por ello es importante establecer mi lugar en la comunidad.
Para esto lo ubicaré en dos ejes: uno de ellos como activista y miembro
de la comunidad de software libre y otro usuario de lenguajes de programación
y entornos interactivos de computación y modelación.
Dicho lugar establecerá también cómo me posiciono y desde qué lugar y experiencias
realizo los ejercicios de diseño de artefactos y dinámicas, mediados por tecnologías
digitales, en esta investigación.


Mi vinculación a la comunidad de software libre empezó en 1996, cuando instalé
el Gnu/Linux en computador de la familia.
Ya antes había tenido inquietud por los computadores,
y armaba computadores clones de PC e instalaba Windows en ellos.

En 1994, desarrollé software para hacer boletines de calificaciones, usando la plataforma 
Windows, adaptando unos macros en el procesador de palabra \emph{MS Word}, que los conectaban 
con la base de datos \emph{MS Access}. 
Esto me permitió darme cuenta de los excesivos costos de licenciamiento
asociados al software comumente usado en aquel entonces,
(como \emph{Windows} y  \emph{Office}) y, de hecho, la manera usual de adquirir conocimiento
sobre los computadores y su funcionamiento era empleando software "pirata".
Lo cual abrió mi búsqueda y mi mente al encuentro con el software libre un par
de años después.

La experiencia de contar con software cuya licencia alentaba la copia, el estudio
y la distribución del mismo, sin convertirlo en un acto de pirateria, sino por el
contrario, normalizando y potenciando, lo que era una práctica habitual entre estudiantes,
curiosos y usuarios de la computación, resonó fuertemente con mis búsquedas y mi contexto.
Por la forma como se hacía la instalación de Gnu/Linux en aquel momento, se iniciaba
con una interface de texto o CLI (por las siglas en inglés de \emph{Command Line Interface}),
y a partir de allí se empezaba a configurar manualmente el resto del sistema, hasta tener
un sistema con interface gráfica o GUI (por las siglas en inglés de \emph{Graphical User Interface})
y las aplicaciones habituales de ofimática, juegos y la naciente navegación en la \emph{World Wide Web}.
Esto implicaba la lectura de libros introductorios al sistema operativo, que incluían CD-ROMs 

en ninguna de mis máquinas.

A comienzos del milenio me uní a distintas comunidades nacionales e internacionales de software,
donde se discutían aspectos técnicos: cómo configurar computadores livianos conectados
a máquinas pesadas, en la comunidad LTSP\footnote{\url{http://ltsp.org/}}; o cómo usar 
editores de texto científico, en la comunidad de TeXmacs)\footnote{\url{http://www.texmacs.org}};
o temas legales y filosóficos del software libre, en la comunidad Colibri (en alusión a la Comunidad
de personas interesadas en el Software Libre en Colombia, véase figura \ref{fig:colibri}). 
En Colibri hablábamos de qué libertades definían al software libre, y cómo su opuesto no era el 
``software licenciado'', pues el software libre también tenía  varias licencias que alentaban y 
protegían dichas libertades, ni era el ``software comercial'', pues el software libre también tenía 
esquemas comerciales, sino el software privativo, porque priva a los usuarios de las libertades que 
el software libre brinda.
Para el 2002 construimos y llevamos una propuesta de proyecto de Ley de Software Libre, articulado
desde la comunidad Colibri, que justificaba cómo el software libre debía ser implementado en 
entidades estatales sobre las bases de inclusión, transparencia y seguridad\footnote{
	Una alternativa similar a esta, que enfatiza como los dineros públicos deben financiar
	el software libre y de código abierto implementando y desarrollado en el estado, sobre
	la base de la seguridad, la transparencia y la competitividad ha nacido quince años después en
	Europa, impulsada desde el portal Public Code (\url{http://publiccode.eu/})}.
Esos años consolidaron la comunidad de software libre de Colombia y hubo varios eventos regionales
a los que me desplazaba, invitado o con fondos propios, dando charlas y conferencias sobre el
software libre.
Del 2004 al 2008, ayudé en el lanzamiento y sostenimiento de El Directorio, un wiki que funcionaba
como unas páginas amarillas de software libre, para documentar recetas de configuración, comunidades, 
empresas y servicios brindados nacionalmente y otros saberes de la comunidad.
En 2005 ayudé a la concepción y lanzamiento del Festival de Instalación de Software Libre
Colibri o FISLC, y en los años siguientes acompañé su transformación el en 
FLISoL\footnote{\url{https://flisol.info/}}, por Festival de Instalación de Software Libre 
de Latinoamérica, uno de los eventos más importantes y grandes de instalación y acercamiento 
al software libre en la región y quizás en el mundo.

Mi vinculación a las comunidades de software libre continuaría y se transformaría en la medida
en que estas comunidades y mis intereses también cambiaban y se desarrollaban.
Sin embargo he sido un miembro activo del movimiento de software y cultura libre desde mediados
de los noventas a hoy en día.

\begin{figure}[tbp]
	\centering
	\subfloat[]{\includegraphics[width=0.45\linewidth]{./Parte2/el-directorio-2011.png}}
	\quad
	\subfloat[]{\includegraphics[width=0.45\linewidth]{./Parte2/flisol.png}}
	\caption[El Directorio y FLISoL]

a mediados de los noventas y Scheme\footnote{\url{http://plt-scheme.org/}},
Python\footnote{\url{https://www.python.org/}} y Smalltalk\footnote{\url{http://squeak.org/}}
como docente universitario  a comienzos de este milenio.
Sin embargo estas experiencias fueron dispersas a lo largo del tiempo y a pesar de
entender los fundamentos de algoritmia y algunos paradigmas de programación, por
mi formación de pregrado como informático-matemático, mi mayor experticia estuvo centrada
principalmente en la modelación computacional de la resolución de problemas, desde
modelos multiagente (\cite{luna_cardenas_resolucion_2007}), intentando explicar fenómenos cognitivos 
y vincularlos a un correlato de aula y estrategias de enseñanza-aprendizaje, para lo cual usé Squeak,
la variante libre de Smalltalk.
La idea de computación científica llegó principalmente a través de programas como 
Matlab\footnote{\url{https://la.mathworks.com/products/matlab.html}},
Mathcad\footnote{\url{https://www.ptc.com/en/products/mathcad/}} y 
Mathematica\footnote{\url{https://www.wolfram.com/mathematica/}}, y fue en este último donde 
encontré la primera idea unificadora de la computación, con la programación simbólica y el hecho de que 
en este lenguaje todo son expresiones, compuestas de cabeceras y argumentos.
Me parecía particularmente interesante la idea de documentación interactiva de Mathematica
y Mathcad, donde se podía combinar la escritura de prosa, con código, gráficas y modelos 
computacionales, en documentos que reaccionaban a la interacción con el lector y generaban
otros modos de lectura y escritura y otras formas de pensar con ellos.
Intenté ubicar experiencias de documentación interactiva similares con sistemas de software libre,
con lo cual conocí software para hacer matemáticas computacionales, con programas para
modelación y simulación y los cálculos numéricos y simbólicos, como 
Scilab\footnote{\url{http://www.scilab.org/}}, Octave\footnote{\url{https://www.gnu.org/software/octave/}},
Yacas\footnote{\url{http://www.yacas.org/}}, Mathpiper\footnote{\url{http://www.mathpiper.org/}}, 
Maxima\footnote{\url{http://maxima.sourceforge.net/}} y otros programas y formatos para escritura matemática, 
entre los que estaban LaTeX\footnote{\url{https://www.latex-project.org/}}, 
MathML\footnote{\url{https://www.w3.org/Math/}} y uno que permitía particularmente la escritura de 
documentos estructurados científicos interactivos, integrando varios de los paquetes ya mencionados, 
llamado TeXmacs\footnote{\url{http://texmacs.org/}}, en el que escribí mis tesis de pregrado y maestría 
y fui uno de los principales traductores de la documentación al español.

TeXmacs fue el primer software que personalicé (usando Scheme) brindándome la experiencia de escribir
un pequeño archivo que creara una nueva funcionalidad disponible para el usuario (consistía en agregar
un nuevo menú en la interfaz de usuario) y me introdujo a una idea poderosa,las 
\emph{expresiones S}\footnote{\url{https://es.wikipedia.org/wiki/Expresi\%C3\%B3n_S}}, 
que permitían tratar a documentos como estructuras uniformes arbóreas, donde tanto datos como código,
son considerados de manera uniforme y uno puede convertirse en el otro.
Esta idea sería después reforzada por Leo y parte importante del diseño de Grafoscopio, casi 15 años
después, lo cual es una muestra de la exaptación mencionada por \cite{jonas_design_2004},
cuando habla de los ``repositorios latentes de soluciones'' con las que deben contar los diseñadores.
Grafoscopio combinaría ideas y experiencias encontradas en los distintos paquetes de software,
incluidos, documentos interactivos, como aquellos de los paquetes matemáticos ya mencionados, documentos
arbóreos programables inspirados en expresiones S (que diluyen la frontera código--datos) y software
altamente personalizable, entre otras.
La experiencia y las frustraciones con dichos paquetes de software, entornos y lenguajes de programación, 
sistemas para escritura, etc. se convertiría así en ese repertorio latente de soluciones que encarnaría 
en Grafoscopio, con sus nuevas posibilidades y frustraciones.

Durante esa época, usaba ciertos \emph{scripts} en el lenguaje de programación Python para automatizar 
ciertas tareas, y cuando pensaba en código determinadas ideas y prototipos, lo hacía más desde una
perspectiva teórica y académica (por ejemplo la de los modelos cognitivos computacionales de
mi tesis de maestría), que la de un programador como tal, que fuera responsable de la labor
artesanal\footnote{La idea de programación como artesanía en lugar de como ingeniería, retoma
	lo dicho en la primera parte en alución al ``hacer es pensar'' de \cite{sennett_artesano_2009} 
	y será extendido posteriormente sobre unas ideas de la materialidad de código de programación
	expuesta por \cite{blackwell_craft_2015}.}
y cotidiana de la misma, atendiendo distintos detalles respecto a cómo se implementa
una funcionalidad o dónde se coloca un botón o ícono en una interfaz gráfica.

Intenté conectar mi experiencia con estos sistemas de matemática computacional, como docente-investigador
universitario y como activista de software libre, al crear algunas distribuciones a medida de Gnu/Linux,
que podían ser ejecutadas desde un CD-ROM, sin tener que instalarse en el computador.
Esto permitiría a mis estudiantes acceder a software libre y crear memoria de lo hecho
en clases, con sistemas similares a los que yo usaba en mi propia máquina, sin que ellos
tuvieran que pasar por las dificultades propias de instalar Gnu/Linux en las propias.
Del 2002 al 2008 fui el autor y compilador principal de las distribuciones SciLix,
Tangram Linux y Virtual Tangram.
%PEND: Logo Virtual Tangram 
Mi labor como docente, especialmente en pregrado, durante esos años, estuvo mediada permanentemente 
por la creación de entornos virtuales de aprendizaje, que complementaran el aprendizaje cara a cara en 
clase (también llamados de \emph{b-learning} por \emph{blended-learning} o aprendizaje bimodal: 
digital-análogo).
En estas prácticas había una patrón: el disponer una infraestructura (en la forma de distribuciones 
de Linux hechas a medida, como las ya mencionadas, o lugares virtuales) y desarrollar un conjunto de 
prácticas alrededor de las mismas, que sirvieran a propósitos educativos (usualmente en espacios formales 
e institucionalizados, pero en diálogo con lo que ocurría en espacios informales y no institucionalizados).
De ellas hago un recuento detallado en la presentación \emph{Nómadas digitales, Aprendizaje} 
(\cite{luna_cardenas_nomadas_2010} ver figura \ref{fig:nomadas-digitales}).

\begin{figure}[tbh]
	\centering
	\subfloat[]{\includegraphics[width=\linewidth]{./Parte2/nomadas-digitales.png}}
	\caption[Nómadas Digitales]
	{Nómadas digitales: Mapa de un recorrido por varias experiencias de \emph{b-learning} con
		mis estudiantes durante la primera década del milenio.
		Disponible en \url{https://is.gd/Syq0SS}}
	\label{fig:nomadas-digitales}
\end{figure}

Mi propio lugar en la comunidad de Smalltalk empezó con algunas experiencias de enseñanza de 
la programación en un curso de introducción a la informática, dictado del 2005 al 2007, en la 
que exploraron distintas herramientas y lenguajes, como Python, Scheme, 
Scratch\footnote{\url{http://scratch.mit.edu/}}, Etoys\footnote{\url{http://squeakland.org/}} 
y Bots Inc\footnote{\url{https://is.gd/BotsInc}}, encontrando que estás tres últimas eran extremadamente 
adecuadas para la enseñanza a novatos, 
por el uso de metáforas visuales para explicar los elementos de la programación orientada a objetos 
y su sintaxis minimalista, como está documentado con mayor detalle en 
\cite{luna_cardenas_resolucion_2007}. 
Sin embargo, después de dicha experiencia, mi vinculación a la comunidad de Smalltalk fue 
principalmente a través de las listas de correo y a pesar de considerarlo para varios proyectos
como un enrutador de identidad digital (\cite{luna_cardenas_ubakye:_2011,luna_cardenas_ubakye_2012}),
y un clon del software de presentaciones Prezi, dichas intenciones nunca llegaron a una primera
línea de código. 
Otras herramientas, como we2py, Leo o IPython eran más maduras y pertinentes para asumir las tareas
de exploración, uso y prototipado de tecnologías digitales a las cuales me veía constantemente abocado. 
No fue sino después de la salida de Pharo en el 2009 como variante basada en Squeak (base para 
Scratch, Etoys y Bots Inc, en ese entonces\footnote{Posteriormente, Scracth pasaría de estar hecho
	en Smalltalk a basado totalmente en Javascript y ser ejecutado en línea desde el navegador web,
	perdiendo muchas de las características de explorabilidad continua del entorno que brindaba la 
	implementación original en Squeak Smalltalk. 
	Otras variantes emplean ahora Pharo, como Phratch (\url{http://www.phratch.com/}), manteniendo
	esa tradición de explorabilidad continua.}) 
y el cambio de énfasis hacia la construcción de herramientas a la medida de Moose y la visualización ágil, 
que las condiciones estuvieron listas para reemprender un prototipo más factible, con un valor diferencial 
que ninguna de las herramientas conocidas tenían, como se explicará en el capítulo \ref{grafoscopio}.

Para el 2008, como coordinador de tres áreas temáticas (Software Libre, Desarrolladores
de Software e Inclusión Digital) de la \emph{Campus Party}, una de las fiestas en red
(o \emph{LAN Parties}, por su acepción en inglés) más grandes del mundo, tuve la oportunidad de conocer 
a Jose David Cuartas, Adriana Castrillón y Manuela Monsalve, estudiantes de Diseño Visual en la 
Universidad de Caldas, con quienes entablaría una duradera amistad, que perdura hasta el momento.
En las conversaciones tempranas sobre lo que hacíamos con tecnología, ellos me dijeron que
esa orientación a hacer cosas con infraestructuras digitales y comunidades alrededor,
atento a lo que pasaba en dichas interacciones, era muy parecido a las formas de hacer
en diseño.
Tener un marco de enunciación, una epistemología si se quiere, para lo que ya hacía y saber
que ocurría desde el diseño me orientó en los intentos de conciliar mi labor docente, mis inquietudes
investigativas, activistas y comunitarias y los requerimientos de la universidad para la que trabajaba 
(que, como la gran mayoría ha caído en la inflación absurda de títulos para sus profesores y en formar 
más doctores de los que el mercado puede contratar).

Fue así como este trayecto me llevó a iniciar el Doctorado en Diseño y Creación en la Universidad de Caldas,
cuyo caracter jóven y sin miedo a proponer y experimentar y cuya epistemología abierta desde el diseño,
permitiría tender redes hacía las prácticas activistas, desde el \emph{hackerspace}, HackBo, que 
ayudé a fundar, por una afortunada coincidencia en el mismo año en que empecé el doctorado (2010) y del 
que me ocuparé en la siguiente sección.

Lo anterior muestra a una persona largamente involucrada con la comunidad de software libre del país
y en contacto con otras comunidades nacionales e internacionales.
También a alguien con cierta visibilidad y reconocimiento en nichos particulares, preocupado
por las infraestructuras que soportan las prácticas comunitarias, en búsqueda de infraestructuras
más sencillas luego de probar muchas complejas (recorrido que se muestra en \cite{luna_cardenas_nomadas_2010}) 
y siendo parte de varios proyectos nacionales e internacionales.
Esto, por su puesto, no está libre de inconvenientes y puntos ciegos, pero es consecuente con
la idea de investigación activista e investigador como sujeto político que habita/observa a un
sistema que lo incluye a él, esbozada en la primera parte.
La siguiente sección profundiza en el contexto de lo hacker, describiendo un espacio particular
donde dicho concepto encarna (un hackerspace) y poniéndolo en diálogo con algunas perspectivas
teóricas que han estudiado dichos espacios y las relaciones entre ciudadanía y tecnologías.




\section{HackBo, un hackerspace en Bogotá}\label{hackbo}

Numerosos académicos han hablado ampliamente del fenómeno hacker desde perspectivas
académicas.
Los trabajo seminales de \cite{coleman_coding_2013} ubical al código como una forma de
ejercicio de la libertad de expresión dentro de otras tradiciones libertales
(no en el sentido económico, sino político del término).
Maxigas y su genealogía del fenómeno hacker desde los hackerspaces y Hacklabs,
asocia los últimos a movimientos autonomistas europeos en la tradición
okupa y los primeros a esfuerzos gentrificadores dentro de la noción del
emprendimiento y la innovación social.
Mackenzi Clark, en su Manifiesto Hacker (\citeyear{wark_hacker_2004}), pone en diálogo la 
tradición hacker con las ideas marxistas, ya no desde el enfrentamiento entre el proletariado 
y los capitalistas, sino entre los hackers (aquellos que ven, gracias a la abstracción, en el 
mundo presente el mundo posible) y los vectoristas, aquellos que usufructuan
y extraen el valor del trabajo de los primeros, al colocar las plataformas
donde dicha abstracción circula y se expande, es decir los vectores de
la misma (usualmente en la forma de redes sociales) e invita a pensarnos como
clase en las luchas por lo posible, ya sean las del agricultor, las del transgenero,
las del programador y en últimas las de todos y todas que propende por los muchos
mundos posibles conviviendo en este en lugar de uno sólo.
\cite{kubitschko_chaos_2018} muestra cómo el fenómeno en Berlin, particularmente en el 
Chaos Computer Club (CCC) ha adquirido capacidad de interlocución pasando de lugares 
marginales a lugares centrales del discurso público y nos da claves para entender en 
fenómeno en términos estéticos y políticos desde las estrategias desplegadas por el CCC.
\cite{schrock_hackers_nodate} hace un recuento de algunas de esas genealogías, preservando 
la invitación de Coleman a mantener la definición de lo hacker como abierta y multisituada
e indicando que los hackers son cotidianos, en el sentido de que el hacker
no es esa figura mítica que gracias a una comprensión especial de la tecnología
la domina, sino que en una relación dialéctica, es la tecnología la que hace al
hacker en actos cotidianos, al soldar, programar, y \emph{cacharrear} todos los días.
Por ello, él indica que los hackerspaces son espacios de aprendizaje disfrazados
(\cite{schrock_education_2014}), donde al establecerse esas relaciones cotidianas 
con la tecnología, los participantes se hacen hackers sin darse cuenta.

La aproximación a la cultura hacker asumida en esta tesis no pretende profundizar en
lo que ya han dicho estos y otros autores, ni resumirlo, sino ponerlo en diálogo con un
lugar particular donde lo hacker encarna, se recontextualiza y se re y co-construye:
HackBo, un hackerspace en Bogotá. 
HackBo es también es un ejemplo de los lugares citados por \cite{manzini_emerging_2013} 
para innovación social emergente donde se codiseñan alternativas para habitar el mundo, 
y, cómo se mencinó en la primera parte, donde el  diseñador convive dentro del prototipo 
mientras se ve a él o ella

De esta manera, el enfoque se puede mantener en las maneras en que dicha cultura
y quehaceres encarnados desde HackBo permiten abordar el problema central de esta
investigación dentro de dicho diálogo.
Para ello, se dará cuenta de la historia del espacio y de cómo las prácticas allí
conversan con las lecturas de algunos autores, en particular la espacio cotidiano y bien
recursivo, es decir aquel bien que construye a quienes lo construyen y de lugar para
la ciudadanía.
Se mantiene así el potencial de una definición abierta, pero también se indican los
lugares donde dichos autores interpelan a las prácticas cotidianas en el espacio.

HackBo empezó en diciembre de 2010, meses después de empezar el doctorado, en una
feliz coincidencia que permitió entrelazar procesos académicos y comunitarios.
Sus miembros fundadores (entre los cuales me encuentro) reunidos en un bar 
y empezaron a cristalizar una idea de la que algunos que nos habían comentado 
por primera vez en la Campus Party de Bogotá este mismo año.

Muchos sentíamos que la Campus usufructuba a las comunidades que congregaba, 
de maneras instrumentales, sin ofrecer valor real, dentro de las lógicas de la 
``publicidad experiencial'', donde lo importante era tener una ``experiencia con 
la marca'' y bastaba con que las cosas lucieran bien en la superficie, así no tuvieran 
mucho de fondo.
Esta sensación era compartida por muchos de los que estuvimos tanto detrás de la 
organización de la Campus Party en varias de sus ediciones, así como de los
invitados, que sentían un control extremo y hablábamos de condiciones de
explotación: no se pagaba a todos los conferencistas, existía una ``zona VIP''
donde se diferenciaba a unos expositores y talleristas de otros y el ``voluntariado''
de muchos era pagado con unas entradas que no estaban en condiciones reales de
disfrutar ante las demandas de tales voluntariados.

y en ese sentido varios de los patrones detectados por Ostrom aplican al Hackerspace como
espacio físico y a lo que en él se produce desde y hacia los espacios simbólicos.

Östrom no sólo clasifica los bienes en privados y públicos dependiendo de la exclusividad
sobre los mismos y si esta es fácil (privado) y difícil (públicos), sino que agrega otra
dimensión referida a cuanto queda de un bien después de que se goza de este, es decir la
sustracción y si esta es alta (no queda mucho) o baja (queda bastante del bien).
Esta otra dimensión configura cuatros tipos de bienes: privados, públicos, clubes y 
comunes.

\begin{figure}[tbp]
	\centering
	\subfloat[]{\includegraphics[width=0.75\linewidth]{./Parte2/type-of-goods2.png}}
	\caption[Tipos de bienes según Östrom]
	{Tipos de bienes según Östrom, organizados en términos de sustracción (cuánto queda del bien
		después de su uso) y exclusión (qué tal fácil o no es excluir de su disfrute). 
		La flecha roja indica el tipo de transito que hacemos en HackBo, pues se trata de un bien
		club en lo físico, donde se producen bienes comunes en la forma de software, documentación,
		datos y hardware libres y abiertos. Adaptado de \cite{ostrom_artifacts_2001}.}
	\label{fig:types-of-goods}
\end{figure}

%PEN: Gráfica

HackBo es entonces un club, pues el exclusión sobre acceso al bien es fácil y tiene que
ver con quiénes tienen las llaves, cómo se entregan o se quitan, pero una vez adentro,
la sustracción del bien es baja y queda mucho de HackBo para todos sus usuarios.
En cuanto a los espacios simbólicos, debido a la fuerte relación de la mayoría de sus
miembros con movimientos de software y cultura libre, se producen bienes simbólicos
comunes en la forma de software, diseños de circuitos y documentación.
Hackbo es entonces un tercer espacio que opera en una diagonal complementaria a
la que clasifica los bienes privados y públicos, mediados por las lógicas del mercado y 
del estado (véase figura \ref{fig:types-of-goods}).
Incluso, miembros más recientes del espacio, dedicados a la producción audio-visual,
hacen parte de la logística del Festival de Cine Creative Commons y New Media, si bien no 
todo lo que se presenta en dicho Festival tiene licencias abiertas y ellos mismos no han 
producido trabajos con tales licencias, aunque sí referidos a proyectos de hardware libre
y abierto que los tendrían, en colaboración con otros miembros de HackBo.

Es decir, HackBo es un bien club, desde lo físico, pues la exclusión es fácil, (ya que se tienen 
o no las llaves de la entrada y se es parte si dos miembros presentes recomiendan a aquel que quiere
pertenecer), que está marcado y de algún modo orientado hacia los bienes comunes desde lo simbólico, 
aunque no todos los miembros participan igualmente de la segunda parte, se produce constantemente
documentación, software, audivisuales, diseños de hardware que están cubiertas por licencias bajo
el esquema de las obras culturales libres, que garantizan su uso, disfrute y/o modificación por
parte de esa y otras comunidades.

Esta multiplicidad de aproximaciones al mismo espacio y las formas de vinculación mediadas

Existen acuerdos tácitos que son renovados y recordados permanentemente: pagar la mensualidad,
lavar la loza, mantener el espacio mínimamente organizado y usable, especialmente los baños y cocina.

La bifurcación toma cuerpo no sólo en las acciones sino tambíen en las infraestructuras
y en ese sentido ejemplifican la idea expresada por \cite{isin_being_2015} frente a cómo
decir con acciones.
Estos autores, recogen los actos de habla, aquellos que no sólo afirman o niegan algo,
sino que hacen cosas: prometen, aseveran, dirigen, declaran y expresan.
De manera recíproca a cómo las palabras hacen, las acciones dicen.
Cuando se elige compra comida orgánica, si se bota basura a la calle, o se emplea una
infraestructura tecnológica, no sólo se están realizando acciones, ellas hablan.
Para el caso de HackBo, infraestructuras digitales implementadas sobre nuestra
presencia en línea, hablan de hasta donde apropiamos o delegamos la autonomía en
plataformas propias o cedemos esas formas de presencia a terceros y enajenamos sus
condiciones.

Lo anterior configura también una serie de dificultades, pues quien no sabe cómo hacer, no puede
argumentar tan claramente como quién sí lo sabe, incluso si los argumentos son buenos. 
Es decir la claridad para argumentar está vinculada a la capacidad para hacer y con la tecnología, 
y se puede correr el riesgo de que los argumentos sean buenos, pero el lenguaje de los prototipos no 
los exprese claramente, como cuando intentamos argumentar en una lengua que no es la nativa.
Por otro lado, la ausencia de una falta de estructura explícita, hace difícil la contestación: %REF
si la estructura es explícita y hay un desacuerdo, es posible contestarlo desde los mecanismos
provistos para ello, pero para el caso de HackBo, simplemente se cuenta con la bifurcación 
(en caso de desacuerdo) o el apoyo/afiliación (en caso de acuerdo).
Si bien esto no es grave en un lugar donde muchas decisiones conviven a la vez, puede hacerse difícil
para organizar labores logísticas que impliquen un esfuerzo grande como organizar la bodega, el taller 
y los equipos.

HackBo es, entonces un espacio polisémico y plurárquico que tiene lecturas y posibilidades distintas
para quienes lo construyen y habitan.
Como todo espacio, esta regido por tres fuerzas, según \cite{isin_being_2015}: 
performativas, legales e imaginarias, que se refieren, respectivamente, a lo que ocurre en el espacio,
a su condición legal y a lo que nos imaginamos que puede ser y ocurrir.

En lo legal HackBo es símplemente un apartamento coarrendado por varias personas que contribuyen 
con una cuota  mensual para pagar su sostenimiento (servicios, arrendamiento y eventuales mejoras).
Este es un estatus legal mínimo y algunos miembros (entre lo que me encuentro)
se han opuesto a que adquiera un caracter legal más allá de este, sin convertirse en fundación,
corporación u otra cosa, esencialmente para mantener la dimensión comunitaria y la productiva y
de financiación separadas.
Las reuniones iniciales para la constitución legal crearon reglamentos, pero ninguno de los asistentes
llevó a términos el conjunto de acciones que permitián el registro y la contitución del espacio:
consultas jurídicas, firmas en papel, levantamiento de otros documentos y su radicación, etc.
Si bien el tema de la constitución legal era recurrente, particularmente en los primeros años,
ante la ausencia de compromisos, interés y acciones que formalicen dicha figura, se ha usado una 
figura emergente y conveniente en la cual las fundaciones o empresas de los miembros del la
comunidad nuclear puedan recibir recursos que transfieren luego al espacio para los pagos habituales, 
o en los pocos casos en los que hay superhábit, para ser coadministrados por ellos.
Dicho modelo ha permitido el sostenimiento del espacio desde 2012, si bien se trata de un espacio
frágil que logra pagar los gastos mensuales a ras, sin mayores plusvalías económicas para el
hackerspace mismo.

La fuerza legal es relativamente estable y minimalista mientras que las fuerzas performativas 
e imaginarias dentro del espacio son más dinámicas y entretegidas (por su puesto, un cambio 
dramático en ellas podría implicar un cambio en las fuerzas legales, pero hasta ahora no ha ocurrido).
Esto es particularmente notorio respecto a qué es hackear dentro del hackerspace
y la naturaleza política o despolizada de dichos actos.
Particularmente porque una definición abierta como la de hacker puede permitir que cualquier cosa sea
``hackear'', con lo cual la definición se diluye y despolitiza.
Hackear, en esas acepciones diluidas tiene que ver con cómo amarrar un nudo de corbata o bajar la grasa 
abdominal, como en el sitio \emph{Daily Life Hacks}\footnote{\url{https://twitter.com/dailylifehackz}} 
y no con la gambiarra y el meta-reciclaje brasilero o con los actos cotidianos que nos permiten adquirir
maestría de modos comprometidos pero invisibles en la acepción de Schrock.
Los hackerspaces se vuelven exclusivamente lugares de \emph{co-working} para el ``emprendimiento''
capitalista, donde la relación es entre arrendatario y arrendador y no entre pares, dentro de lugares 
cocreados y co-administrados con plurarquía, gozo y tensión comunitarias.
Ya no se trata de pensar desde la perspectiva de clases, siguiendo la invitación de \cite{wark_hacker_2004} 
y cómo ver en lo presente lo posible, bien sea desde lo biológico  y la lucha por la 
autonomía de las  semillas (y la nefasta Ley 970), o el ciberespacio y la libertad de expresión 
(y la terrible Ley Lleras recientemente aprobada en el Congreso de Colombia para entrar a la OCDE), 
o con el matrimonio igualitario y las reinvidicanciones feministas (que también han sido llevadas
al Congreso de Colombia en distintas ocasiones.).
Para Wark, pensar lo hacker desde la perspectiva de clases implica pensar que biología,
libertad de expresión, ciberespacio y feminismo no son luchas aisladas, sino que ellas y muchas
otras, que potencian el mundo presente y lo conectan con los mundos posibles, son luchas similares,
y por ello feministas, campesinos, hacktivistas hacen parte de una clase que aún no se ve a sí
misma como tal, la clase hacker.
De hecho esta idea de confrontar a lo que \cite{escobar_autonomiy_2016} llama el Mundo de un
Único Mundo, expandido por la doctrina capitalista neoliberal y sus distintos vectores
(entre los que él cuenta a la academia) con un mundo en el que habitan muchos mundos dialoga
con la perspectiva de Wark, si bien no explícitamente desde de la lucha de clases, sí desde
la idea de las potencialidades del mundo presente para engendrar los mundos posibles
de varios futuros simultáneos, algo que Escobar llama futuralidad, en oposición a la convergencia 
hacia un único futuro y forma de vivir en el mundo.
En la mirada gentrificada que se está popularizando, la postura hacker ya no está en la 
potencialidad de esas conexiones con otras miradas de ser y hacer en el mundo, como 
espacios de aprendizaje o lugares de reinvidación de posturas políticas, éticas y estéticas, 
como nos invitan a considerar los autores citados al comienzo de esta sección,
sino de reunirnos temporalmente en una ``hackatón'' \emph{fashionista}, para 
competir unos contra otros por un premio consistente en un mal contrato (como el denunciado 
en la sección \ref{gobernaton}), un parlante o una consola de vídeo juegos.

Que un sólo tipo de definición sobre lo hacker agote e invisibilize las otras o las diluya hasta
gentrificarlas va en contra de las ideas de futuralidad y mundos posibles planteadas por 
\cite{escobar_autonomiy_2016} y de las luchas compartidas por lograrlo de Wark y las ambigüedades 
de una definición abierta se constituye en un espacio dialéctico para señalar esas tensiones.
Los hackerspaces y hackatones son eventos donde las definiciones se pueden repolitizar y en esa

medida son un lugar donde la resolución de dualidad estructura-agencia y la perspectiva dialéctica 
a la que nos invitaban \cite{fuchs_autopoiesis_nodate} toma cuerpo, desde los artefactos y quehaceres
de tales espacios y encuentros.
Es por eso conveniente indicar por qué en la acepción de esta tesis, no todo es hackear, sin 
agotar la definición, pero sí articulándola con los alfabetismos digitales mediados por código 
y datos, que es un asunto fundamental de la pregunta por cómo cambiamos los artefactos digitales 
que nos cambian y cómo esta se constituye también en una pregunta por la autonomía y desde allí 
se exploran maneras de ciudadanía, tanto en las personas como en las comunidades de práctica.
Es decir, estas son las maneras en que la dualidad entre estructura y agencia, mencionadas
en la primera parte, toman cuerpo, a través de artefactos que permiten co-diseños desde
las comunidades de práctica sobre la autonomía.

Como podemos ver en la cita que inaugura este capítulo, \cite{isin_being_2015} (pág 139)
se separan de la mirada caricaturizada de los medios ``informativos'' y hollywoodenses sobre el 
hacker  (una distinción que nos toca hacer semanalmente en el espacio, cuando nos piden por 
enésima vez infructuosa, por correo o en persona, que entremos a la red social de la (ex)pareja 
o cambiemos notas o estados bancarios), para pensarla en clave ciudadana desde la idea de sujetos 
de poder, que dichos autores contrastan con la idea de sujetos al poder y sus relaciones con lo 
actos digitales, en relación con los actos de habla desde  la perspectiva de la teoría crítica 
política.
Para Isin y Ruppert la diferencia entre el sujeto y el ciudadano es que éste último está
compuesto de obediencia, sumisión y subversión.
Para ellos 




\begin{quote}El nacimiento del ciudadano como un sujeto de poder no significa la desaparición del
	sujeto como sujeto al poder. El ciudadano sujeto encarna esas formas de poder en
	las cuales él está implicado, donde la obediencia, la sumisión y la subversión no son
	disposiciones separadas, sino potencialidades siempre-presentes.
	
	[...]
		
	Para Focault, eran los `actos de verdad' los que permiten posibilidades para el
	sujeto para constituirse a sí mismo como sujeto de poder. Para nosotros, esto también
	significa que los actos de verdad permiten posibilidades de subversión. Ser un sujeto de poder significa
	responder al llamado `como debería uno ``gobernarse a sí mismo'' realizando acciones
	en las cuales uno es en sí mismo el objeto de esas acciones,  el dominio en el cuál ellas
	se llevan a cabo, el instrumento que ellas emplean y el sujeto de que actuan?'. Al
	describir esta como su aproximación, Focault fue claro en que el `desarrollo de un
	dominio de actos, prácticas y pensamientos' plantea un problema para la política. Es en 
	este respecto que nosotros consideramos el Internet en relación con miriadas de actos, prácticas, y
	pensamientos que plantean un problema para las políticas del sujeto en las sociedades contemporáneas.
	
\end{quote} (pág 27)


Isin y Rupper consideran que indagar cómo la gente se enactua a sí misma implica indagar cómo

``la gente usa el lenguaje para describirse a sí misma y sus relaciones con los otros y 
cómo el lenguaje los convoca a hacer cosas con palabras y palabras con cosas que los enactuan 
a sí mismos''.

Para estos autores esta configuración desde la auto-descripción y la auto-convocatoria 
(de la gente hacia y para la gente) implica entender cómo actuán en Internet, no sólo frente 


a cómo hablan, sino desde cómo se involucran y actuan desde dicha red y en conexión con el
mundo fuera de ella, pero interconectado con la misma.

Para Isin y Rupert, en la medida en que las fuerzas de obediencia, sumisión y subversión están 
presentes en los ciudadanos, estos no solo están sujetos \emph{al} poder, sino que son sujetos
\emph{de} poder, pues la presencia de una fuerza no excluye las otras.
Dicho poder lo ejercen de distintas maneras, atendiendo a `actos de verdad' en los
que se manifiestan sus personas políticas y que dan cuenta de esa miriada de actos,
prácticas y pensamientos que atienden al llamado sobre cómo gobernarse a sí mismo,
por un lado, y por otro hacen del sujeto que se pregunta eso, el lugar y laboratorio
primero de las exploraciones y respuestas sobre el autogobierno.
Esto no sólo ocurre en el plano de lo analógico, sino que también tienen correlatos
en el plano de lo digital y de hecho está en fuerte diálogo con la dualidad estructura
agencia a la que se hacía alusión en la primera parte de esta tesis, pues los
actos de auto-gobierno no sólo ocurren en la persona, sino en distintas las comunidades
y en la relación dentro de dicha dualidad con las instituciones y el grueso de la sociedad.
Reafirmando lo antes dicho, debido a los correlatos tecnológicos de dicha pregunta por el 
autogobierno, enclavada en las entrañas del problema político, la pregunta sobre ``cómo 
cambiamos los artefactos digitales que nos cambian'' es una pregunta por la autodeterminación, 
donde los sujetos de dicha pregunta son personas y colectivos en comunidades 
de práctica que se constituyen en el lugar primario y explícito de tales preguntas, mediadas por
el lenguaje y la acción, encarnada en dispositivos digitales, infraestructuras y técnicas.

Isin y Rupert se ubican en la teoría de los actos de habla, que enuncia las palabras no sólo 
dicen, sino que también hacen para establecer un contrarrecíproco: las acciones no sólo hacen,
sino que también dicen, y estas acciones mediadas por tecnologías digitales involucran a su vez
aquello que decimos con los artefactos que posibilitaron dichas acciones.
Un artefacto por antonomacia con el que se dicen cosas es el código de software, lo que a su
vez tiene que ver con las maneras en que se concibe el acto de programar:

\begin{quote}
	Para nosotros, probablemente la distinción
	más pertinente es entre programadores y hackers. En decir
	algo el código realiza actos ilocucionarios y perlocusionarios.
	La diferencia entre los programadores y los hackers es, sin embargo, los efectos de esos actos,
	lo cuales han cambiado dramáticamente en el tiempo.
	Los programadores son aquellos -- ya sean empleados por compañías o trabando independientemente -- quienes
	se ganan la vida escribiendo código, lo que incluye cualquier cosa entre los \emph{snippets}
	[código corto] y las \emph{apps}.
	Los Hackers también pueden programar código en esta manera, pero la cultura que los denomina
	emanada desde un conjunto distinto de valores éticos y estéticos que combinan para crear una
	clase diferente de política de la que hace el programador.
	La diferencia es difícil de expresar, pero es también la diferencia que nos interesa.
	Es difícil de expresar quizás porque se ha dicho y escrito demasiado sobre los
	hackers --mayoritariamente en negativo.
	Como consecuencia, una imagen unificada, típicamente clandestina, egoista, joven, masculina 
	y rebelde se ha vuelto dominante, la cual muchos estudios recientes han mostrado que es 
	grotescamente simplista\footnote{Isin y Rupert no citan explicítamente tales estudios en
		este apartado, pero los autores mencionados al comienzo de esta sección
		(\cite{coleman_coding_2013}, \cite{kubitschko_chaos_2018}, 
		\cite{schrock_hackers_nodate, schrock_civic_2016}, \cite{wark_hacker_2004}),
		muestran la extrema simplificación a la que ellos se refieren frente a quiénes son
		los sujetos hacker y qué es hackear.}.
	Queremos argumentar que los hackers son aquellos cuyos actos rompen las convenciones de la programación. 
\end{quote} (pág 139)

\begin{quote}
	¿Cuáles son efectos tienen estos actos digitales de hackeo?¿Cuáles convenciones esos
	actos rompen?¿Qué convenciones esos actos resignifican? Ellos son tan amplios como
	los tipos de hackers.

cuando esta es escrita por el sujeto hacker, que inscriben esa programación dentro de los 
actos digitales, que Isin y Rupert trazan en analogía a los actos del habla.
Como se ha dicho, estos últimos no sólo enuncian, sino que también hacen, en la acepción de
Austin y se catalogan en: saludos, solicitudes, quejas, invitaciones, complementos, y negaciones.
De modo similar, Isin y Rupert establecen que hay actos digitales y que decimos con las
acciones y por extensión, agrego yo, con las infraestructuras que las posibilitan.

Brevemente, los actos digitales, según \cite{isin_being_2015} (capítulos 4 al 6), son: 
\begin{itemize}
	\item Los llamamientos: relacionados con participar, conectar y compartir;
	\item Las clausuras: referidas al establecimiento de límites, bien sea a través del filtrado, 
	donde los ciudadanos se protegen a sí mismos o por terceros (estado o privados) en su acceso a 
	la información y el rastreo donde se entra en un juego sobre la actividad identificable.
	\item Las aperturas: referidas a la ruptura de las expectativas y el establecimiento de
	otras nuevas, usando las fuerzas legales, imaginativas y performativas.
	\item La hechura de nuevas reivindicaciones (\emph{claims}): donde se suponen ejercicios
	de derechos adquiridos en nuevos medios o se argumentan nuevos derechos en contextos digitales,
	derivados de los ya adquiridos.
\end{itemize}

%Desafortunadamente, los límites de espacio/tiempo en esta tesis para detenerse en los elementos
%propuestos por Isin y Rupert sin desviarse demasiado de tales límites.
%Basta con decir que 
La ruptura de las convenciones a través de la programación y la escritura
de código cuando se repolitiza desde las subjetividades hacker, supone enmarcarlos dentro
de estos actos digitales, asociados a decir a través de las cosas.
En particular, se refieren a los actos de romper los actos clausura, brindando nuevos accesos,
reimaginando nuevas fronteras y desplazándolas, pensando en nuevos derechos: como el acceso al
código fuente, para los hackers del software libre desde los 80's y a los datos y algoritmos,
para los hackers cívicos de movimientos más tempranos como los indicados por \cite{schrock_civic_2016}
y que han venido tomando fuerza desde la idea de datos y gobierno abiertos.
En esta tesis veremos, a través de los prototipos digitales, como se dicen a través de cosas,
específicamente de esos prototipos y como los llamamientos, en la figura de los Data Weeks
y otros espacios y encuentros en análogo y digital se corresponden con una perspectiva de
derechos que si bien contiene clausuras (particularmente de tiempo), invita permanentemente
a aperturas y la hechura de reinvidicaciones y peticiones, en el entramado no secuencial de
actos digitales descrito por Isin y Rupert, desde la forma como tales entramados cristalizan
en el hackerspaces, sus actos, prototipos, software, datos visualizaciones y subjetividades.

La repolitización del acto de programar, de escribir código y su inscripción en las prácticas
ciudadanas emergentes con tecnologías digitales, introduce la idea de hacktivismo, vinculada a 
la acepción de lo hacker que esta tesis se suscribe y hace cercanas, en concordancia con 
\cite{isin_being_2015}, que trazan la genealogía de lo hacker identificando 4 formas de 











funcionamiento hacia los 90's ``hackers originales (disidentes y libertarios), microsefs 
(subordinados y sumisos), un grupos creciente de desarrolladores de código abierto (críticos y
resilientes) y los hacktivistas políticamente motivados (políticos y subversivos)'' (pag 140)
y es en estos dos últimos grupos --desarrolladores de código abierto y hacktivistas-- donde 
ellos ubican la emergencia de los sujetos ciudadanos en el ciberespacio.
En sus palabras:


\begin{quote}
	[...]
	
	[Jordan y Taylor] admiten que aunque los hacktivistas provienden de los hackers, es
	difícil dibujar una frontera entre los dos: `Porque el hacktivismo usa técnicas
	computacionales prestadas de la comunidad hacker pre-existente, es difícil identificar
	definitivamente dónde el hackeo termina y el hacktivismo comienza.'[55] Ellos entienden el hacktivismo como
	`la emergencia de la acción popular política, de la actividad propia de los grupos de personas en
	el ciberespacio. Es una combinación de portesta política de comunidad de base con el hackeo de computadoras.
	Jordan y Taylor también proveen una panorámica histórica del disenso y la desobediencia
	como repertorios de la política, los cuales llamaríamos `actos de los ciudadanos digitales'. Ellos
	discuten como, por ejemplo, la desobediencia civil de los Zapatistas, un grupo disidente Mexicano,
	cambio los términos de la políticas al involucrar tecnologías incipientes de Internet en los 90's
	para argumentar que el Zapatismo --la convención combinada de acción de base y activismo electrónico-- fue
	de muchas maneras el lugar de nacimiento del hacktivismo como convención disruptiva. [...] En este punto
	del tiempo, es difícil saber cuánta perturbación esos actos de desobediencia civil electrónica
	específicamente realizan. Lo que sabemos es que el poder neoliberal está extremadamente preocupado por 
	tales actos.
\end{quote} (pag 144)

De nuevo la relación entre lo hacker y lo hacktivista y las fronteras difusas y transiciones que
los autores señalan, desde lo teórico, apreciando comunidades internacionales, tienen correlatos
en las prácticas locales.
No todas ellas tienen que ver con la desobediencia civil, pero sí con los actos digitales
antes enunciados.
Un ejemplo son los llamamientos hechos en redes sociales por el colectivo RedPaTodos\footnote{\url{http://redpatodos.co}}
sobre los peligros de la Ley Lleras y la invitación a articulación en digital y en análogico
al respecto, que pretendián realizar aperturas (al debate y las plataformas) en oposición a las 
clausuras a las que llevaba las dinámcas del Gobierno nacional.
Patrones similares se vieron en otros frentes sobre enunciar con acciones y código el ejercicio 
disenso y la bifurcación.
En el caso de La Gobernatón (veáse sección \ref{gobernaton}), lo que hicimos fue auditar los 
términos de la contratación pública usando técnicas de verificación de integridad de software, 
basadas en sumas de verificación criptográfica (una combinación alfanúmérica única asociada a 
un archivo, que se modifica  bastante, si el archivo cambia en lo más mínimo, por ejemplo, 
agregando un espacio). 
Fue el hecho de aunar técnicas computacionales clásicas, como esas las que activaron la idea 
de la Gobernatón y luego del Data Week (véase capítulo \ref{dataweek}).
Esto ocurrió localmente, al margen de las prácticas anteriores y paralelas que hacían los 
zapatistas, o los periodistas de datos. 
Era una idea ``cuyo tiempo había llegado'' (parafraseando a Victor Hugo) y se empezaba a 
originar en distintos lugares, con las variaciones propias de cada contexto.
HackBo, como lugar conexo y encarnado de prácticas de repolitización de la tecnología digital,
la programación y el código fuente nos permitía también realizar transiciones de lo hacker
al hacktivismo, desde las preguntas locales que resonaban con prácticas desconocidas por
nosotros pero alineadas a esas ideas de tecnologías políticas presentes en las raíces de la
comunidad de software libre que nos había convocado.
Algunos encarnábamos así, desde nuestras prácticas y artefactos digitales y discursivos la
dualidad de hackers y hacktivistas.

Esto hace eco por lo comentado por \cite{schrock_civic_2016} frente a cómo la apuesta por 
la apertura gubernamental, en este caso a través del código de sus infraestructuras de software
no es suficiente:

\begin{quote}
	Sin embargo, el igualamiento natural de ``apertura'' o transparencia gubernamental (Hood and Heald, 2006)
	con responsabilidad se volvió progresivamente dudoso (Tkacz, 2012).
	El movimiento hacia los ``datos abiertos'' fue a menudo un imperativo que no hizo claras donde estaban las
	palancas para el cambio social, que beneficiaban a los ciudadanos (Lessig, 2009).
	Aún así, argumento que los hacker cívicos están a menudo posicionados de forma única para actuar en
	asuntos de preocupación pública; ellos están en contacto con comunidades locales, con habilitades
	técnicas y en muchos casos con alfabetismos legales e institucionales.
	Concluyo conectando el movimiento d elos datos abiertos con un conjunto específico de táticas políticas
	-- petición, digestión, contribución, modelamiento y contestación de datos.
\end{quote} (pág 4)

Apertura, transparencia y reponsabilidad no son lo mismo y no hay vínculos entre 
lo uno y lo otro directos. 
Los ofrecimientos gubernamentales de datos y software abierto son sobre ``emprendimiento''
y no sobre reponsabilidad y trazabilidad de la gestión, ni la participación incluyente 
a lo largo de los procesos.

Esta diferencia entre los ofrecimientos gubernamentales y las necesidades de las comunidades
de base, puede ser leía desde cómo los saberes locales que ponen datos como una forma 
de acción política ciudadana, dentro de los varios procesos enunciados por \cite{schrock_civic_2016}
(págs 11-13): 

\begin{enumerate}
	\item 
		Solicitud: tiene que ver con hacer los datos ampliamente disponibles y en formatos 
		procesables por máquinas.
	\item 
		Digestión: relacionado con la interpretación y el procesamiento de los datos de modo que
		puedan servir a una historia (cívica, periodistica, etc).
	\item 
		Contribución: Tiene que ver con agregar y hacer disponibles nuevos conjuntos de datos.
	\item 
		Modelación: Referido al uso de código y datos abiertos para crear prototipos (parcialmente)
		funcionales.
	\item 
		Contestación: Se refiere a la creación de prototipos (parcialmente) funcionales para usos
		no existentes aún de los datos. 
		Es similar a la modelación pero su uso es por oposición en lugar de por persuación.
		Uno podría colocar acá los actos que crean discursos alternos, basados en datos y código,
		pero que confrontan las narrativas de hegemónicas.
		 
\end{enumerate}

Las prácticas evidenciadas en HackBo, con el Data Week y las Data Rodas, en los ejercicios de
extraer datos, republicarlos, crear visualizaciones, enviar derechos de petición, que se
ejemplifican en los capítulos venideros, dan cuenta de esas maneras de hacktivismo, hacking cívico que
constituyen la repolización del código y los datos.


La relación entre los bienes y las comunidades que los crean y usan, unida a las materialidades
discursivas (cosas que dicen) donde estas toman cuerpo, en una forma de causación realimentada, 
ha sido caracterizada también por \cite{kelty_geeks_2008}, específicamente dentro de contextos 
Geek/Hacker\footnote{Dicho autor prefiere el primer término sobre el segundo, para separarse 
	rápidamente de las acepciones negativas de éste},
desde su idea de públicos recursivos y citando a Taylor, no se puede distinguir si las ideas
causan las prácticas humanas o viceversa y la intensión es sobrepasar la dicotomía entre ideas
y prácticas materiales, particularmente en escenarios entrelazados con lo digital, donde
las distinciones entre las materialidades se hacen difusas y múltiples capas se apilan
en documento digital, el software del procesador de palabra, su código fuente, los chips
de la computadora y las plantas de manufactura.
Para Kelty

\begin{quote}












	[e]sta es la primera de las razones por las cuales un público recursivo se distingue de la formulación
	clásica de la esfera pública, que es, que requiere una clase de imaginación que incluye la escritura,
	publicación y argumentación con las que estamos acostumbrados, como también la creación de
	nuevas clases de infraestructuras para la circulación, archivamiento, movimiento y modificabilidad
	de nuestras enunciaciones
\end{quote} (pág 7)

Si bien Kelty usa Internet como la infraestructura, la materialidad y el lugar que configura a los 
públicos recursivos, me alejaré de este lugar para centrarme en otros como los hackerspaces, que 
nos atañen acá.
Nótese cómo el entramado de infraestructuras y materialidades es clave en la definición de un público 
recursivo.
No sólo se trata de construir los lugares, materialidades y prácticas de argumentación que contruyen 
un discurso público, sino de hacer lo propio con aquellas que posibilitan la creación, circulación
y modificación de tal discurso.
Esta característica va más allá de la circularidad entre los públicos y las materialidades que
los construyen como tales, a las materialidades debajo de ellas, que construyen otros públicos
en condiciones de atraversar dichas materialidades.
El ejemplo del libro ofrecido por Kelty, resuena poderosamente con nuestras propias prácticas,
pues para el la existencia de una materialidad específica, como la del libro impreso no basta
para que un público exista y se requiere que ese público se interese en lo que están diciencido
quienes a él se dirigen:

\begin{quote}






	O cómo Waner indica, ``La circularidad es esencial al fenómeno.
	Un público podría ser real y eficaz, pero su realidad yace justo en esta reflexividad por
	la cual un objeto señalable es conjurado a la existencia a fin de procurar el mismo
	discurso que le da existencia''.
\end{quote} (pág 12)


La apreciación particular sobre la circularidad es potente en términos de los fenómenos sociales
autopoiéticos enunciados en la primera parte.
Un público es causado por una materialidad que lo convoca, pero este está atento a dicha materialidad
para constituirse en su público.

Debido al caracter estratificado de las infraestructuras, en particular las digitales,
no sólo un libro crea a un público recurviso, sino que existe un conjunto de capas

que también crean públicos recursivos y van más allá del libro y que para el caso de
Internet, según Kelty incluyen el software, sus protocolos y estándares, las aplicaciones
y el software, las licencias, las regulaciones, lo cual hace a los públicos recursivos
distintos por dos razones:

\begin{quote}

	(1) ellos incluyen no sólo los discuros de un público, sino la habilidad para hacer,
	mantener y manipular las infraestructuras de estos discursos también; y 
	(2) ellos están ``estratificados'' e incluyen tanto los discursos como las infraestructuras,
	hasta un cierto alcance técnico (es decir, no todo lo de abajo).
	El sentido de cuáles capas son importantes se desarrolla más o menos inmediatamente del
	involucramiento directo con el medio.
\end{quote} (pág 15)

Para el caso de Grafoscopio, como se verá en los capítulos \ref{prehistoria} y \ref{grafoscopio},
no bastó la preexistencia de un público dentro de la comunidad originaria de HackBo para que 
Grafoscopio fuera posible, y tampoco bastó la existencia del software mismo para convocar a un 
público alrededor del mismo en tal comunidad.
Grafoscopio, como materialidad argumentativa, requirió de esfuerzos individuales que la encarnaran,
para luego convocar a públicos nuevos y diversos al respecto, con quienes constituimos una
comunidad de práctica, que en la exploración del medio mismo que era Grafoscopio, pudo revisar
las materialidades que valía la pena explorar juntos en las capas de infraestructura
(software, datos, licencias, protocolos, repositorios, entre otros), en la medida en que 
socializábamos (hacíamos público) y realizábamos varios de los prototipos explorados
en el capítulo \ref{prototipos}, es decir, en el contacto con el medio mismo.
Llama poderosamente la atención el ejemplo particular del libro empleado por Kelty para la 
constitución recíproca de medios y públicos, pues en el prototipo del Manual de Periodismo de 
Datos (véase sección \ref{mapeda}), efectivamente argumentamos en la misma línea, sobre la
insuficiencia de licencias abiertas para libros, cuando las infraestructuras que permiten su
escritura y modificación no están abiertas, precluyendo la pluralidad y la participación.
Efectivamente, no sólo reconstruimos el libro, sino las infraestructuras que lo hacen posible,
usando para ello el entramado de infraestructuras que cristalizaba en HackBo y daba cuenta
de sus fuerzas legales, performativas e imaginarias: desde las llaves del hackerspace, hasta
sus sillas y mesas (éstas últimas creadas por unos miembros del espacio), pasando por la 
licencia del Manual que permitía reconstruirlo, hasta la existencia de Grafoscopio, que podía 
ser adaptado para enunciar como materialidad, las necesidades, búsquedas y hallazgos de nosotros 
como comunidad.

Así, la pregunta por cómo cambiar los artefactos digitales que nos cambian, enmarcada
en el contexto de HackBo, y el hacktivimo (la programación como actividad política), puede 
reformularse como la pregunta sobre cómo nos construimos como públicos recursivos, no sólo
participando del discurso público (sobre bibliotecas, presupuestos nacionales, discursos 
políticos en redes sociales, periodismo de datos, entre otros prototipos, mostrados en el 
capítulo \ref{prototipos}), sino atravezando y (re/co)construyendo  el conjunto de 
infraestructuras y artefactos digitales que nos permiten y empoderan (o no) para tal 
(re)construcción de lo público.

HackBo es entonces un bien recursivo, no sólo porque como la mayoría de los bienes club
(desde la taxonomía de Östrom), fue formado por aquellos que serían sus beneficiarios,
sino porque es una materialidad donde encarnan las preocupaciones de sus miembros por
explorar las prácticas, artefactos e infraestructuras que permiten re y co construirnos 
como hackers y hacktivistas, repolitizando el concepto y las prácticas, desde la cotidianidad.
HackBo es un bien recursivo porque (co)crea a los hackers que lo (co)crean, diciendo
cosas en el quehacer cotidiano desde y sobre la tecnología y lo público.

La manera en que estos procesos ocurren, para el caso particular de la comunidad y
materialidades de Grafoscopio, será el motivo de exploración de los siguientes capítulos

% Bosquejo original del capítulo:
% - Bienes comunes: Gobernanza, filiación y propiedad
% - Gobernanza: plurarquía y tiranía del hacedor.

		\includegraphics[width=0.45\linewidth]{./Parte2/hackbo-casa-7.jpg}
		\label{subfig:hackbo5}}
	\quad
	\subfloat[]{
		\includegraphics[width=0.45\linewidth]{./Parte2/hackbo-casa-4.jpg}
		\label{subfig:hackbo6}}
	\caption[Momentos en HackBo]
	{Varios momentos en HackBo, tomados de una galería compartida.
		\ref{subfig:hackbo1}, \ref{subfig:hackbo4} y \ref{subfig:hackbo6}
		corresponden a reuniones sociales de cenas y celebraciones en el 
		espacio;
		\ref{subfig:hackbo2} es el set construido para la filmación de una
		campaña de \emph{crowdfunding} usando \emph{stop motion};
		ref{subfig:hackbo3} es una mesa de trabajo durante el ensamblaje
		de la clásica impresora 3D DIY (Do It Yourself) 
		y \ref{subfig:hackbo5} es una foto de la sala de talleres, durante
		la realización de uno de ellos.
		Los eventos sociales son de los pocos que congregan al grueso de la
		comunidad, pues la mayoría de los miembros del espacio pagamos la
		mensualidad, pero no asistimos regularmente al mismo, sino que
		pagamos para tener un espacio propio donde podamos auto-organizarnos
		y celebrar con relativa autonomía (como se ha conversado en persona
		y en la lista de correo y canal de Telegram).}
	\label{fig:hackbo-momentos}
\end{figure*}

epistemologías, se sugerirá una manera de conectarlas
y se usará una aproximación de \emph{zoom} para modificar la teoría de diseño de
Jonas, conectándola con la perspectiva crítica de Fuchs y Hockhaimer.
También se mostarán aproximaciones metodológicas al
diseño que suponen al investigador/diseñador como sujeto
político, que co-diseña y habita un problema/prototipo
dentro de una comunidad (de práctica o interés) apostando
por un mundo más plural e incluyente, finalizando en una
metodología de diseño basada en investigación, que propone
al software como hipótesis, lo cual conecta las epistemologías
del diseño, contextuales y no orientadas a producir saberes
positivistas y verdades, sino saberes contextuales e hipótesis,
con la forma que tales hipótesis toman como artefactos de software
desarrollados dentro de una comunidad.
Esto permitirá entender los lugares de mirada
y acción de la segunda parte.

%----------------------------------------------------------------------------------------
%	CAPITULO 1
%----------------------------------------------------------------------------------------
\chapter{Ecología y sistemas complejos como posibilidad dialéctica}\label{ecologuxeda-y-sistemas-complejos-como-posibilidad-dialectica}

estados más avanzados de sí mismos, la de que \emph{la sociedad es una
	red compleja autopoiética y esto tiene consecuencias en las
	epistemologías y acciones del diseño}.

Al respecto del tratamiento de sistemas complejos \cite{berlow_simplifying_nodate} 
nos sugiere una abordaje desde la dinámica del acercarse (\emph{zoom in}) y
del alejarse (\emph{zoom out}) que de hecho estaría en consonancia con
las propuestas de explicitar y ubicar las tensiones dialécticas entre las estructuras
sociales y los actores humanos en ellas de forma que se puedan repensar las formas
en que ellas se configuran y transforman mutualmente, hecha por \cite{fuchs_autopoiesis_nodate} 
y con la idea de visualizar para argumentar y preguntarse, hecha en los viscursos de Bonsiepe y 
los medios para para pensar lo impensable de \cite{victor_media_nodate}, que dan cuenta acerca

de cómo las mediaciones cambian las maneras en que pensamos, entendemos y formulamos sistemas









complejos (sociales o de otra índole).


\begin{figure*}[tbh]
	\centering
	\subfloat[Una red compleja en ecología.]{
		\includegraphics[width=0.5\linewidth]{./Parte1/complejidad-ecologia.jpg}
		\label{subfig:compleja-ecologia}
	}
	\subfloat[Una red \emph{complicada} en política.]{
		\includegraphics[width=0.5\linewidth]{./Parte1/eeuu-guerra-afganistan-2-20.jpg}
		\label{subfig:complicada-politica}
		2	}
	\\
	\subfloat[La red complicada expresada como red política compleja.]{
		\includegraphics[width=0.5\linewidth]{./Parte1/eeuu-guerra-afganistan-complejidad-2-39.jpg}
		\label{subfig:compleja-politica}
	}
	\subfloat[Zoom en la red política compleja para asuntos relevantes.]{
		\includegraphics[width=0.5\linewidth]{./Parte1/eeuu-guerra-afganistan-complejidad-influencia-2-55.jpg}
		\label{subfig:zoom-politica}
	}
	\caption[De lo complicado a lo complejo]{El dialogo entre lo simple y lo complejo para desenmascarar lo complicado.}
	\label{fig:simple-complicado-vs-complejo}
\end{figure*}




En su ejemplo, Berlow toma la inspiración en el tratamiento de redes 
complejas en ecología (figura \ref{fig:simple-complicado-vs-complejo} a) 
y los aplica a la política,  en particular al problema de incrementar 
el apoyo popular en Estados Unidos  al gobierno afgano, de modo que este 
deje de aparentar ser un problema complicado 
(figura \ref{fig:simple-complicado-vs-complejo}b) y se manifieste como un problema complejo. 
Decía que la dinámica del \emph{zoom in} y el \emph{zoom out} permitía, 
no sólo ubicarse en la interacción de dos elementos de la red, 
sino considerar varios grados de influencia y descartar algunos no 
directamente relacionados, de este modo podía mapear la red compleja del problema, 
en este caso el político, 
(figura \ref{fig:simple-complicado-vs-complejo}c) y encontrar conexiones 
interesantes/relevamentes (figura \ref{fig:simple-complicado-vs-complejo}d).
Una idea similar se ha seguido en este escrito y para explicitarla 
se desarrolló un mapa mental de las lecturas que lo informan , en esta primera parte,
(\emph{zoom out}), mostrado en la figura \ref{fig:mapa-lecturas}, para enfocarse luego 
en dos propuestas y las consecuencias de las mismas en una parte de las epistemologías 
del diseño (\emph{zoom in}) y las conexiones con otros autores (se hará referencia a 
las distintas partes del \emph{zoom in} a lo largo del texto). 
Las propuestas conectadas fueron una que se podría denominar una

	{Interpretación de la teoría de Jonas: El diseño 
		como puente entre entidades autopoiéticas (circulares)
		y artefactos (rectangulares).}
	\label{fig:jonas-design}
\end{figure}

Cuando aborda el vínculo entre diseño e investigación, Jonas nos
enfrenta a tres garantias constitucionales paradójicas de la 
modernidad (Jonas 2005 pp 192):

\begin{itemize}

	\item
		Incluso cuando construimos la naturaleza, es como si no lo hiciéramos.
	\item
		Incluso cuando no construimos la sociedad, es como si lo hiciéramos.
	\item
		La naturaleza y la sociedad deben permanecer absolutamente separados;
		el trabajo de purificación debe permanencer separado del trabajo de
		mediación.
\end{itemize}

La segunda de estas paradojas es resuelta cuando se desplaza la unidad 
constitutiva de la autopoiesis en lo social de lo comunicativo a lo humano.
(a dicha resolusión se dedica la sección \ref{consecuencias-fuchs-en-jonas})
Y si bien la paradoja de la frontera entre lo cultural y lo natural sigue
latente, lo cierto es que nuestro involucramiento en ese mundo cultural-natural
es ineludible.
Para Jonas el diseño se ocupa del mundo posible y hay en el una
asumpción antropológica: La habilidad de diseñar es una característica
esencialmente humana cuya función es la concepción y proyección
de las condiciones humanas de vida. El diseño ``es el medio para obtener
conocimiento sobre el mundo [y] no podemos superar nuestro
involucramiento en ese proceso'' (Jonas 2007 pp. 194).
Como diseñadores no podemos separarnos y ser sólo observadores de lo observado,
sino que el diseñador es visto como un sistema que se auto-organiza, ``que está
observando un artefacto que evoluciona más él o ella observando el
artefacto que evoluciona''(Jonas 2007 pp .193).

Jonas también afirma que el diseño es una práctica reflexiva, en línea con lo 
establecido por Dewey cuando dice que conocer es una manera de actuar y que se 
trata de pasar de la verdad a la ``afirmabilidad garantizada'' (`\emph{warranted assertibility}').
Esta tesis se mueve en esa línea y de hecho se adentra profundamente en la técnica
y las comunidades para establecer esas práctica reflexivas que permitan establecer
hipótesis plausibles en lugar de verdades científicas, específicamente en lo
referido a cómo los artefactos digitales y las comunidades de base pueden modificarse
de manera recíproca.

En este mundo de artefactos contigentes y peregnes y de
acciones/conoceres ineludibles como criaturas vivas y hacedoras de
sentido, ¿qué papel nos corresponde como diseñadores entonces, en
particular desde una formación doctoral en diseño? La crítica que se
presentará de Luhmann puede ayudarnos a entrever una respuesta y, como
se dijo, servir de puente para entablar el diálogo entre estos dos

atañe al diseño, sino, de acuerdo a estos autores, también a las
ciencias sociales.

Como afirman Fuchs y Hofkirchner, un lugar donde es notoria la
insuficiencia de la teoría del Luhmann para hablar de lo posible se hace
manifiesto en su tratamiento a la protesta (pp. 115):



















\begin{quote}
	Para Luhmann, los movimientos de protesta son reactivos, sin objeto y
	peligrosos. Cada movimiento de protesta tiene valores y ciertos
	objetivos políticos; por tanto, quiere cambiar la sociedad. Los
	movimientos sociales no son reactivos, sino activos y proactivos. La
	caracterización de Luhmann apunta a desacreditar la protesta; si la
	última no es vista como una función positiva de la sociedad, las

	autopoiética es en nuestra aproximación reemplazado por la unidad de
	estructura y actores.
\end{quote}

Este cambio de unidad de autopoiesis de las comunicaciones y las
estructura y los actores (humanos) reinvindica la agencia humana en la
posibilidad de transformar el mundo y brinda puentes con otras teorías.
En primera instancia porque los humanos reconstruimos y co-construimos
el mundo y la estructura de éste a la que nacemos, nos es dada, pero puede
ser transformada.
La unidad autopoiética de lo social no son las comunicaciones, sino lo humano.
Nacemos a un mundo social humano que nos hace humanos, pero también desde nuestra
condición de seres humanos podemos cambiar dicho mundo.
Nos encontramos frente a estructuras sociales preexistentes, pero podemos cambiarlas
como actores humanos en ellas.
Si bien el diseño continua ocupándose de los puentes que mencionaba Jonas
entre lo autopoiético (lo biológico, lo mental y lo social) y lo heteropoiético
(lo artefactual), dado que lo que le brinda condición autopoiética a lo social
es lo humano, estamos es condiciones de cambiar como actores humanos las estructuras
sociales en las que nos humanizamos.
Y debido a que dichas estructuras se encuentran insertados en culturas materiales
de artefactos contigentes y necesarios, que reflejan dichas culturas, podemos a través 
de los cambios en los artefactos, explorar cambios en las culturas y en las estructuras
sociales.
Es decir, los artefactos pueden mediar la relación entre actores humanos y estructuras
sociales.
En particular, los artefactos digitales, debido a su flexibilidad y posible maleabilidad,
son buenos candidatos para explorar dicha mediación y revisar las posibilidades de
agencia de los actores humanos en los cambios de estructuras sociales.

Esta cita larga, entonces apuntala las posibilidades que esta tesis explora,
al establecer cómo la agencia de actores humanos puede cambiar las estructuras sociales
a través de los artefactos.
Dedicaré la siguiente sección a ver en detalle cómo el hecho de que la autopoiesis de lo social 
esté basado en lo humano y no en las comunicaciones, repercute en las posibilidades de diseño
como puente entre lo autopoiético y lo heteropoiético y como los artefactos digitales pueden
mediar la relación entre estructuras sociales y actores humanos.

\section{Consecuencias de la crítica de Fuchs y Hofkirchner en la teoría de Jonas y los diseños autonómicos}\label{consecuencias-fuchs-en-jonas}

La primera consecuencia es nominal, pero no por eso trivial. Desde la
teoría de sistemas sociales crítica de \cite{fuchs_autopoiesis_nodate} las
brechas/puentes de Jonas que aborda el diseño, podrían actualizarse como
aquellas entre los artefactos/mecanismos, lo biológico (organismos), lo
mental (conciencias) y lo social como hecho humano (desenfatizando así
las comunicaciones, que son parte de lo social, pero no su centro).

\marginpar{
	\captionsetup{type=figure}
	\centering
	\includegraphics[width=\marginparwidth]{./Parte1/dualidadParticipacionCosificacion.png}
	\caption[Dualidad cosificación participación de Wenger]
	{Dualidad cosificación participación. Tomado de \cite{wenger_communities_1999}.}
	\label{fig:dualidad}
}


Por otro lado, dicha crítica permite repensar puentes entre la agencia humana
y la sociedad en su conjunto más grande a partir de las comunidades de práctica
y lo que \cite{wenger_communities_1999} ha caracterizado como la dualidad
cosificación/participación (Figura \ref{fig:dualidad}), ya que nuevos artefactos, 
propiciarían nuevas participaciones. 
Esto en consonancia con los patrones emergentes y evolutivos de los sistemas complejos 
auto-organizados de los que hablan tanto Jonas cuando aborda la variación, selección 
y re-estabilización, como Fuchs y Hofkirchner cuando abordan la emergencia de abajo-a-arriba
y de arriba-a-abajo en los procesos de recreación social. 
Veámoslo más detalladamente.

\begin{figure*}
	\centering
	\includegraphics[width=\linewidth]{./Parte1/jonas-zoom-evolucion.png}
	\caption[Zoom al mapa en Jonas y la evolución]
	  {Zoom al mapa de lecturas al Jonas y las partes de la evolución.
	  	(las líneas que van hacia afuera muestran relaciones explicitadas en el
	  	mapa entre distintos autores. Los íconos amarillos representan anotaciones
	  	textuales extendidas, hechas para complementar el mapa).}

prima en la creación conjunta de artefactos que transitan en dichas comunidades, aunque es la
comunidad la que diseña para sí misma, desde sus dinámicas de cosificación y participación en
lugar de ser ``intervenidos'' por el diseñador externo.
Un ejemplo puntual de esto se puede encontrar en las comunidades de Unix/Linux, donde las
personas crean artefactos para, según su propio argot, \emph{rascar su propia 
	comezón} (\cite{coleman_coding_2013}), para resolver un problema de cada cual, cuya 
solución luego comparten con otros. 
El criterio de utilidad es el primero que se usa en esta otra forma del diseño: si no alivia la 
comezón, no es el artefacto adecuado. 
La usabilidad y el deseo en cambio no ocupan altas prioridades, sobre todo para quienes no 
han pasado por el acto iniciático de entrar en la subcultura del uso del sistema operativo
y que les puede parecer un lugar poco deseable y usable.
Sobre la poca usabilidad y deseabilidad de Unix hay un largo libro que puede ilustrar muchos 
puntos ciertos: ``The Unix \emph{Haters} Handbook'' (\cite{garfinkel_unix-haters_1994}). 
Esto no deja mejor parados a otros sistemas operativos y en general al paradigma dominante
de la computación. 

con dichas estructuras (y en ocasiones dando lugar a las mismas).

Es decir que la reinterpretación de lo social desde Fuchs y Hofkirchner en 
las teorías autopoiéticas del diseño de Jonas, nos permite abordar algunas 
cuestiones, que desde la perspectiva de Sanders, son preguntas abiertas 
sobre los procesos de selección, pero cuyas respuestas son cotidianas,
si se piensan desde las comunidades de práctica. 
También resuelven la segunda paradoja de la modernidad, enunciadas por
Jonas que se mencionó previamente, pues efectivamente en este diálogo
entre estructura y agencia, construimos la sociedad que nos construye,
y por ello \emph{parece} como si no lo hiciéramos.
Estas comunidades son además un sitio donde no sólo se puede experimentar, 
sino persistir con la variación, es decir con la creación de posibilidades 
alternativas al mundo y los artefactos que tenemos y mantener más controladas,
aunque no por ello predecibles, la selección y restabilización.
Son un lugar desde donde explorar y persistir en la diferencia,
si valoramos y respetamos la agencia de personas y comunidades en la construcción 
de mundos posibles, distintos, más plurales y autónomos.

	Los diseñadores profesionales no deben usurpar la habilidad de otros \emph{stakeholders}
	para diseñar su propio futuro
	
	--Krippendorff (pg 75)
\end{quote} 

Para el caso de las comunidades de práctica este involucramiento es evidente como
muestran las investigaciones de \cite{manzini_emerging_2013} sobre innovación social emergente,
donde comunidades codiseñan, desde sus apuestas cotidianas, otras maneras de habitar el mundo,
que se convierten en críticas proactivas desde la acción, frente a un modelo depredador actualmente 
generalizado.


%PEND:
Esto resuena fuertemente con la idea de futuralidades de \cite{escobar_autonomiy_2016},
en su apuesta por la autonomía y el diseño.

Escobar extiende el concepto de autonomía de Varela, referido a como un



``sistema vivo encuentre su camino hacia el momento siguiente actuando adecuadamente a partir de 


sus propios recursos'' (Varela 1999: 11, citado por Escobar pág 192), afirmando que una posibilidad

similar para las comunidades y los mundos de definir su futuro a partir de sí mismas,



particularmente en ``bajo condiciones de ocupación ontológica''.

Para \cite{escobar_autonomiy_2016} la autonomía de comunidades 

\begin{quote}
	se refiere a la creación de las condiciones que permiten el cambio de las normas 
	desde dentro o la capacidad de cambiar las tradiciones tradicionalmente. 
	Podría implicar la defensa de algunas prácticas, la transformación de otras y la verdadera 
	invención de nuevas prácticas.‘Cambiar las tradiciones tradicionalmente’ podría ser una descripción 
	adecuada de la autopoiesis; su correlato, ‘cambiar la forma como cambiamos’
\end{quote} (pag 197)


y dicha posibilidad autonómica la relaciona con el ``diseño diseño de herramientas,
interacciones, contextos y lenguajes que cumplan con el principio del diseño ontológico de cambiar la 
forma como nos ocupamos de nosotros mismos y las cosas'' (pág 192).
Nótese como autonomía tiene que ver entonces con ``cambiar la forma como cambiamos'' y en ello
hay labores de diseño de prácticas y herramientas entre otras.
Dado el reconocido cambio  que los artefactos digitales ejercen sobre nosotros, 
la pregunta por cómo cambiamos los artefactos digitales que nos cambian se relaciona con la acepción
de \cite{escobar_autonomiy_2016} sobre un diseño para la autonomía que pluralice las formas de ser
y resista la ocupación ontológica, es decir, la ocupación de las formas de ser en el mundo.

Es decir, tanto Krippendorff, como Manzini y Escobar, apelan a la posibilidad de las comunidades de participar
en el diseño de mundo y de sí mismas.
Los diseñadores profesionales no tienen un monopolio sobre las formas de pensar-hacer mundo, particularmente
cuando se relacionan con comunidades, sino que estas, en la mirada de los tres autores, permanentemente se
ocupan de rediseñar el mundo en la medida en que lo habitan y persisten en la diferencia frente a modelos
de mundo cada vez más convergentes hacia un único mundo posible con practicas depredadoras, que acaban con
la coexistencia de muchos mundos posibles dentro de este.
La idea de modelo deprendador del mundo, de Manzini, dialoga con la idea de ocupación ontológica de Escobar:
en la medida en que modelos capitalista y neoliberales están monopolizando los futuros y convergiendo a una 
única manera de ser en el mundo, es decir, las formas de ser han sido ocupadas, nos hayamos entonces frente
a un proceso de ocupación ontológica y las herramientas, interacciones y contextos pueden (re)abrir puertas
hacia esas otras formas de ser en el mundo.

La pregunta central de esta tesis, sobre cómo cambiamos los artefactos digitales que
nos cambian, dialoga con las inquietudes de Escobar por un diseño preocupado por la autonomía, 
y las conecta con las teorías de Sistemas sociales críticos de \cite{fuchs_autopoiesis_nodate} 
y las aproximaciones al diseño de \cite{jonas_design_2004, jonas_design_2007}.
Es un lugar concreto donde estas tres posturas se exploran, pues nos ofrece una teoría cibernética 
crítica del diseño, que conecta lo mental, lo biológico y lo social mediados por el
lenguaje y los artefactos, donde lo social se concibe como basado en lo humano, y en cómo perteneciendo a una 
red/sociedad humana nos (re)hacemos humanos, pero también podemos lidiar con la dualidad estructura-agencia, 
cambiando las prácticas sociales, transformando tradiciones desde las tradiciones mismas, reinventando
artefactos, prácticas y comunidades desde las comunidades mismas y ampliando la autonomía de ellas para ser, 
(como se muestra en la segunda parte de esta tesis) en un mundo donde las ocupaciones ontológicas pretenden 
qué sólo seamos como otros quieren y donde las tecnologías digitales son vectores importantes de expansión
de dichas ocupaciones, al embeber formas de poder hegemónicos\footnote{La manera en que la tecnologías
	e infraestructuras digitales son un vector colonialista está siendo ampliamente documentada
	y explotada en los estudios críticos de tecnología.
	Particularmente el proyecto \emph{Big Data From The South} (\url{https://is.gd/bigdatasur}), coordinado 
	por Estefanía Milan, Anita Say Chan y Emiliano Treré, está articulando redes de activistas e
	investigadores para compartir estas perspectivas y acciones críticas.
	Un reciente artículo dando cuenta de la relación entre tecnologías e infraestructuras digitales
	y colonización es \emph{Data Colonialism: Rethinking Big Data’s Relation to the Contemporary Subject}
	(\cite{couldry_data_2018}).}
 (y también, como todo poder, sus posibilidades 
de resistencia).
La pregunta por cómo cambiamos los artefactos digitales que nos cambia es, en últimas, desde esta
reintepretación del diseño crítico, una pregunta por cómo nos hacemos más autónomos desde nuevos
artefactos y prácticas creadas comunitariamente.

La preocupación del diseño por el mundo posible presente en varios autores,
debe estar acompañada los compromisos éticos del diseño respecto a cómo
construiremos entre todos y todas un mundo para todos y todas.
De esto precisamente se ocupa la siguiente sección, donde se retomará
la pregunta por el papel del diseño, en particular desde la formación
doctoral, que se dejó abierta previamente.

	terminar con alguna de ella y son un tema sensible para el cual no hay espacio
	suficiente}
y en ese sentido debe incorporar las inquietudes de la teoría crítica, muchas de las
cuales toman cuerpo en la protesta, que estos autores reivindican, mientras que Luhmann no.


Ya hay indicios de cómo la transformación posible del mundo pasa de la 
protesta a la propuesta, y sin invalidar la primera, muestra prototipos viables 
de otras maneras de habitar el mundo compartido, que repiense los modelos de 
gobernanza, filiación y propiedad (en la trilogía caracterizada por Bauwens, Ghalim) 
o que establezcan críticas a los modelos de desarrollo neo-liberal que ponen el derecho a
la propiedad y al lucro por encima de otros derechos más fundamentales (Coleman, 2013). 
Así, sin una explicitación clara de una agenda materialista, 
vemos algunas de esas inquietudes incorporadas en las acciones 
cotidianas de las comunidades de la denominada innovación social difusa de Manzini.

Todas estas comunidades participan y construyen su propia cultura
material y cambian los artefactos, espacios y pactos sociales que
permiten hacer viable su otro modelo de vida.
En la medida en que esos modos de vida tienen sentido para quienes 
participan de ellos, los artefactos cobran sentido, pues hacen parte del diálogo 

sin embargo yo no sólo diría, como Jonas, que el artefacto es una 
materialización necesaria, pero contingente, sino ineludible.
Los ejercicios de diseño compartido están mediados por artefactos que
se comportan como  prototipos y argumentos sobre cómo hacer viable el 
mundo posible, para comunicarlo a aquellos con quienes diseñamos y vivimos 
(\cite{saikaly_approaches_2005}, \cite{keller_for_2007}), en ese sentido los 
prototipos ``hablan el lenguaje de la experiencia, el cual nos une en el mundo.
Sirven como portadores y realizando esas experiencias compartidas
facilitan la comunicación'' (\cite{pieter_jan_stappers_doing_2007}). 
Los artefactos son contigentes por su caracter de prototipo, nos hablan
de otros artefactos posibles para rediseñar el mundo al mismo tiempo que nos
unen en este.
Debemos estar atentos a esa dualidad.

Los artefactos-prototipos acá son entendidos en el

\cite{fuchs_autopoiesis_nodate}, con las propuestas por \cite{jonas_design_2007} que apelan 
a la teoría fundada y la investigación acción, ya que ``admiten el involucramiento del 
investigador junto con la emergencia de teorías de datos empíricos, en contraste con el
tradicional concepto de construcción de la teoría como verificación de la hipótesis
previamente formulada.'' (pp. 192).
La pista que se me ocurre en este momento es asumirse como sujeto político que mira-hace 
al sistema que evoluciona con uno adentro mirando-haciendo.
Esa explicitación política involucra un discursos de poder que pone manifiesto
el papel del investigador en la reconfiguración del mundo posible.

Dicha reconfiguración está emparentada con la historia del diseño, pero se propone acá no 
tanto una historia real, de lo que fue, sino una historia virtual, de lo que hubiera podido ser. 
Se trata de ubicar sobre todo los puntos de bifurcación pasados que se agotaron,  cortaron u 
ocultaron para encontrar allí, como proponen Jonas y Krippendorff las claves de lo posible. 
Hasta ahora tenemos historias lineales hacia atrás que nos hablan sobre todo de como 
llegamos a donde estamos, tenemos que junto a ellas ubicar la pregunta por dónde podríamos 
haber estado si siguieramos un punto de bifurcación y reactivarlas, cuando sean pertinente, 
lo cual tiene el trabajo adicional de comunicar el mundo actual con el que hubiera podido

Que enuncien, de manera enactiva, un \emph{qué pasaría sí}, un \emph{supongamos que} 
y los pongan a circular.
¿Qué pasaría si tuviéramos lugares no institucionalizados para la vida social 
(como los \emph{hackerspaces})?; supongamos que las comunidades pudieran cambiar los artefactos
digitales que las cambian, ¿cómo serían dichos artefactos? Si dichos artefactos existiesen,
¿que papel juega a auto-referencialidad en los mismos?
Para indagar sobre estas preguntas y ponerlas a circular, se ha decidido convertir dichas hipótesis
en prototipos, en una epistemología consecuente con el diseño, que se explica en la siguiente sesión.
El desarrollo de esta metodología durante varios años dentro de una comunidad de práctica, 
se desarrolla en la segunda parte de esta tesis.

\section*{Metodología de diseño basado en investigación: el software como hipótesis}\label{metodologia}

La sección de metodología termina este capítulo y concreta las apuestas por ese mundo del que
se ocupa el diseño construido de maneras plurales y más humanas, desplegado específicamente en el 
contexto de comunidades hacker y artefactos digitales.


La metodología seguida en esta investigación está explicada en \emph{Software as Hypothesis: 
Research-Based Design Methodology} \cite{teemu_leinonen_software_2008}.
Esta asume, precisamente, a los prototipos de software como hipótesis y los pone a circular
en contextos colectivos y comunitarios, con permanentes ciclos de realimentación durante todo
el proceso. 

Está caracterizada por las siguientes fases (véase figura \ref{fig:leinonen-design})

\begin{figure*}
	\centering
	\includegraphics[width=0.7\linewidth]{./Parte1/design-thinking.png}
	\caption[El artefacto como hipótesis]
	  {Dinámica de diseño para la modificación recíproca entre

	usar técnicas etnográficas rápidas. En la medida en que se hace el
	trabajo de campo, se realizan indagaciones focalizadas sobre la
	literatura y pruebas de desempeño (\emph{benchmarking}) sobre
	soluciones pre-existentes o posibles
	\item
	\textbf{Diseño participativo:} En esta fase se trabaja con los
	interesados (\emph{stakeholders}) a través de talleres y prototipos
	ligeros o mentales del tipo ``que tal si\ldots{}''. Acá los
	prototipos como tal no existen, sino que se formulan hipótesis sobre
	cuáles podrían ser los productos y prototipos que den cuenta de las
	necesidades del contexto encontradas en la fase previa.
	\item
	\textbf{Diseño de producto:} En esta fase se crean prototipos
	tempranos por parte del grupo del proyecto y se mantiene distancia de
	los \emph{stakeholders} pues la discusión suele ser de caracter
	altamente técnico usando lenguajes especializados para la misma.
	\item
	\textbf{Prototipo como hipótesis:} Acá se ponen a circular los
	prototipos para ser validados o no por los \emph{stakeholders}. 
	Su caracter de hipótesis es lo que permite su constante revaluación,
	dentro de los límites del proyecto.
\end{enumerate}

Como se dijo, estas fases tienen ciclos de realimentación permanentes
y que se puede empezar en cualquiera de las fases para volver a las
anteriores o ir a las siguientes. 
Por ejemplo, dado un producto particular, digamos desde la capacidad instalada 
de hacer hardware o desde un dispositivo de hardware particular, los co-diseñadores,
que pueden incluir o no a miembros de la comunidad, pueden preguntarle a ésta qué 
tipo de cosas es posible hacer con dicho aparato de hardware y cómo esto afecta las 
prácticas del contexto comunitario. 
Esto ha pasado, por ejemplo con dispositivos como Arduino\footnote{\url{https://www.arduino.cc/}} 
y la Rasperry Pi\footnote{\url{https://www.raspberrypi.org/}}, que una vez existentes como 
producto (fase 3), pasaron por el diseño participativo (fase 2) y la indagación contextual 

(fase 1) para preguntarse como sacarlas del contexto particular donde habían surgido para 
afectar otros contextos, por ejemplo el educativo o el del diseño de modas (como se muestra
en los múltiples projectos listados en sus sitios web).
Otros procesos de investigación inician en la indagación contextual y terminan en
el prototipo como hipótesis, de maneras más lineales, pero una vez tiene dicho
prototipo, lo reinsertan en la comunidad para continuar el ciclo.
Otros inician en cualquiera de las fases intermedias y continuan adelante o
atrás en el diagrama de acuerdo a las necesidades propias del proceso de
diseño y la investigación en que se basan.

En esta relación de iguales entre investigación y comunidades de base, 
el desafío investigativo es más grande que el comunitario. 
Las comunidades continuaran codiseñando y haciendo sentido desde el cotidiano, 
al margen de si existe sobre ellas una lectura y acción activa desde la 
investigación en diseño o el diseño basado en investigación, que ocurre al
interior de la academia y confinado a sus métricas y lógicas y quizás cooptado
por ellas\footnote{La forma en que dicha relación entre comunidades de base 
	y academía que investiga sobre ellas ha configurado relaciones utilitaristas 
	ha terminado por conocerse como extractivismo cognitivo.
	Una lectura introductoria a dicha tensión puede encontrarse en 
	\cite{vance_crossing_2017}}.

Las comunidades que hoy exploran ese mundo deseable y futuro, habitando
el \emph{no todavía} de la utopía enfrentan tensiones y fragilidades
y las externalidades de sus redes pueden ser cooptadas por discursos hegemónicos,
por ejemplo, los hackerspaces pueden ser gentrificados y convertidos en \emph{labs} 
de innovación para que respondan a lógicas institucionales donde el conocimiento no 
es visto como un bien común, sino puesto dentro de métricas de la publicación indexada
y los registros de patentes.
Hay un problema latente y vigente que abordar allí y que es de la competencia
del diseño (académico o no) en su preocupación por la configuración de un mundo 
posible. 
Y como acá ya no se pregunta por cualquier mundo posible, sino que lo hace 
pensando en uno que sea emancipador y posibilitador de lo humano, el diseño 
debe velar por proteger, dinamizar y extender el asomo de mundo que dichos lugares y
personas representan. 

Como se podrá notar, las consecuencias expandidas conectar autores como Jonas, Fuch y 
Hofkirchner y Leinonen, entre otros, presentan desafíos grandes. 
Para asumirlos, el metabolismo cognitivo de Bonsiepe no debe aplicarse sólo desde el diseño 
a otros saberes, sino también desde el diseño hacia sí mismo. 
La metáfora del metabolísmo implica dos procesos, uno catabólico en el que se libera energía 
desde la degradación de compuestos en partes más simples y otro anabólico en el que se usa 
la energía liberada para construir componentes a partir de otros elementos más sencillos.

Los ejemplos de Bonsiepe son en su mayoría anabólicos, como lo ha sido este texto hasta acá.
Ahora quiero ofrecer un ejemplo catabólico en el que se ve parte de los componentes
que hicieron este texto posible.
Ellos toman la forma de algoritmos e infraestructuras, que ocultamos en nuestro
esfuerzo de textos puros, pero que serían inconsecuentes con un viscurso impuro.
Pues explicitar estas palabras dentro de algoritmos e infraestructuras en ``la nube'' 
no sólo es un ejercicio de escritura, sino que permite mostrar los componentes que
permitirían otras recombinaciones si se les aplica energía.

Explicitar no sólo las concialiciones, sino los componentes y procesos para otras
recombinaciones, son parte de hacer posible la construcción compartida de variedad
en principio y en últimas de mundo.
Es, además consecuente con la metodología planteada, pues muestra los procesos de
indagación contextual, diseño participativo, diseño de producto y software como
hipótesis mencionadas anteriormente y pone a dialogar la investigación en clave
etnográfica con dichas fases, dando cuenta de lo que ocurre en la comunidad,
cómo se pertenence a ella, qué prototipos previos existieron antes de los prototipo
finales y sus refinamientos, y los procesos comunitarios y personales que llevaron
a los mismos.

De esto se ocupa la segunda parte.

\clearpage

\restoregeometry

En la primera parte se habló de como el diseñador ``habitaba el prototipo'' cuando se
acercaba a las comunidades y codiseñaba con ellas.
También se reconoció el caracter de investigador como sujeto político, que no
intenta describir objetivamente un fenómeno, sino que está involucrado con él
intimamente.
Una metodología consecuente con esta forma de conocer 
% está de la mano de las epistemologías feministas y se 
crea un viraje desde la observación participativa a la participación observante. %REF: participatory observation

Los capítulos de esta segunda parte describen el problema y los prototipos 
desde esa perspectiva inmersa en la comunidad y si bien inician con una pregunta/objetivo
relativamente claro en esta narrativa organizada que demanda la academia,
esta misma fue aclarándose en la medida en que dicho habitar se daba, como es propio
de los problemas difusos de los que se ocupa el diseño.
El relato tiene una recurrente voz en primera persona, pero también
se intercala con lecturas del trabajo colectivo y nombres de personas
que ayudaron a tales descubrimientos.
Esta voz individual coincide con idea de un desarrollador principal y solitario 
en lugar de una comunidad, que no es infrecuente de la mayoría de proyectos
de software libre y código abierto, como han mostrado varias
métricas (\cite{eghbal_what_2016}, \cite{hill_when_2013}), pero también 
puede dar cuenta de la génesis de una comunidad.

Con respecto a la metodología propuesta, el capítulo 4 da cuenta del contexto
y ubican al investigador dentro de éste, dando cuenta de la aproximación informada
etnográficamente. 
El capítulo 5 enfatizan varios ciclos de indagación comunitaria, diseño participativo, 
diseño de producto y prototipo como hipótesis, con los artefactos y dinámicas que antecedieron 
y fueron clave para la creación de Grafoscopio y el Data Week, mientras que los capítulos 
6, 7 y 8 dan cuenta de los mismos ciclos para los artefactos y dinámicas centrales 
de esta tesis: el capítulos 6 se centra en Grafoscopio, el 7 en las dinámicas 
comunitarias que lo configuraron y se dieron gracias a este y el 8 en los
protipos individuales y colectivos que muestran la amplificación de voces críticas
gracias a Grafosocopio y el Data Week.
Lo anterior evidencia como los ciclos de realimentación de las fases de la investigación
basada en diseño producían prototipos de software que se iban modificando progresivamente
hasta llegar a aquellos que se consolidaron finalmente y cómo se entrelazan con
las dinámicas comunitarias y los cambios en ellas.

El recuento de esas transformaciones en esos cinco capítulos de la segunda parte es el 
recuento del despliegue de la metodología de esta tesis, que acá se pone en diálogo 
recurrente con perspectivas críticas, teóricas y tecnológica.
Mientras la primera parte es más teórica y no se centra mucho en tecnologías o artefactos
específicos, esta segunda parte es más práctica y se centra en ellas.
Sin embargo además de ciertas interpretaciones teóricas a lo largo de estos capítulos,
cada una cierra con un breve recuento que conecta el capítulo con la teoría de la primera
parte, preparando el diálogo que se presenta en la tercera parte.

\input{hacker}

\input{prehistoria}

\input{grafoscopio}

\input{dataweek}

\input{prototipos}

		De este modo el texto frente al lector puede que sea sólo una versión de un texto vivo
		y extensible, en el que se incorporan no sólo fé de erratas, sino que los anexos y pendientes
		ocupan lugares más centrales y se exploran las posibilidades de impresión por demanda y
		otras formas de mercados académicos basados en el acceso al conocimiento como bien común,
		en lugar de la restricción al mismo que vemos tras las cuestionables prácticas de las
		revistas indexadas.
		En contraposición a ellas se trata de ofrecer nuevas formas de escribir y publicar trabajos
		investigativos, periodísticos, académicos y de otras índoles bajo plataformas que reconfiguran
		y alientan otras relaciones entre la publicación y los públicos desde las infraestructuras
		amoldables y de bolsillo acá presentadas.
	\item Los usos de los prototipos en cada contexto variarían, pero estarían
		interrelacionados facilitando puentes entre los escenarios
		institucionalizados/académicos tradicionales y los no intituiconalizados comunitarios y 
		de garage. 
		Los no institucionalizados avanzarían de maneras más fluidas, realizando

lo mental y lo social) y lo heteropoiético (lo artefactual), mediado por el lenguaje y 
colocando como centro de lo social lo humano, en lugar de las comunicaciones, con 
consecuencias respecto a como se realiza investigación en para y desde el diseño, desde 
la apuesta por investigador-diseñador como sujeto político, que hace parte de una comunidad 
y habla desde ella, aunque no en su nombre, habitando el problema, la utopía como un no
todavía, codiseñando y prototipando junto a tal comunidad.
Esto también se refleja en la noción de comunidad de práctica como lugar reflexivo y de
aprendizaje, y de hackerspace como lugar encarnado desde se co-construyen y reconstruyen sujetos 
políticos desde prácticas auto-determinadas mediadas por las cosas que los artefactos digitales
dicen.

La hipótesis de partida para facilitar la transición de usuarios a hacedores de
artefactos digitales era introducir sistemas auto-referenciales o metasistemas, en una 
comunidad (en este caso HackBo). Es decir sistemas que aprovechan la cualidad que tiene lo 
digital de referirse a sí mismo no sólo a través de la documentación y sistemas de ayuda, 
sino al hacer difusa la distinción entre el código fuente, el programa ejecutable y la
documentación.
Grafoscopio embebió tales ideas facilitando un continuo entre los usuarios del software y
los hacedores de los mismos, tendiendo un puente entre el mundo de la imprenta con una
tradición larga de 500 años, al de la computación, cuyas encarnaciones recientes no cumplen
un siglo, empleando para ello las narrativas de datos, que vinculan lo textual, lo visual,
el código y los datos.
Esto implicó demandas e imaginarios distintos sobre quienes usuarían el software: se
pensaba en ellos como personas proactivas y curiosas por las materialidades mismas que 
soportan las prácticas escriturales y por los cambios no sólo que estas generan en ellos,
sino por la manera en que ellos pueden cambiar los artefactos de vuelta.
Los computadores son lugares no sólo de enunciación, sino reconfiguración de las formas de 
enunciar, lo cual requiere alfabetismos críticos distintos y largos, como pueden ser los
de pasar de lo oral a lo escritural, pero esta vez pasando de lo escritural a lo computacional,
con limitaciones en la práctica, que tienen que dichas las demandas implican.
El proyecto acá esbozado es un proyecto civilizador, como diría un amigo, en el sentido de que 
piensa sociedades distintas, como las pensó la escritura y sabemos que la incoporación del texto 
a nuestra cultura sigue ocurriendo y sigue estando en el marco de las centurias.
Obsérvese que no es un proyecto colonizador en el sentido de que no imagina como incivilizados
a quienes no hacen código, ni piensa expandir una agenda particular con la transición alentada
como sí ocurrió de lo oral a lo escritural alentado por la enseñanza de la biblia.
Este proyecto no precluye formas previas de pensar y expresar lo humano, ni las normaliza
en una sóla.
Por el contrario, quiere aumentar lo que \cite{escobar_autonomiy_2016} llama las futuralidades
y que resuena fuertemente por la apuesta enunciada en el examen de candidatura de 2014 y
en este texto al hablar de un mundo diverso, construido en comunidad y potenciador de lo humano.

Ello requerirá encontrar en saberes como los computacionales (asociados al código, los datos,
la visualización) un lugar puente hacia otros saberes, su repolitización y caracter crítico.
De hecho, en esa perspectiva, vale la pena pensar en cómo investigaciones futuras piensan
la manera en que esta manera particular de pensar el código como forma de puente y reconfiguración
de los mundos previos implica el diálogo de las técnicas culturales por excelencia, enunciadas
por Kittler (escribir, calcular, diagramar) con la técnica cultural de nuestra época: programar.
Grafoscopio es una primera exploración tímida en ese sentido, pues a través de la programación
se co-construyen y reconfiguran las maneras en que se escribe, se calcula y se diagrama, en este
entorno continuo que conecta tales técnicas.

Una manera de realizar dicha exploración es a través de lo que yo llamo ``diálogo de 
materialidades'' y que se experimentó varias veces a lo largo de esta investigación, 
durante la realización de prototipos individuales y colectivos, aunque no hubo tiempo para 
deconstruirlo detalladamente.
Acá sólo se brindará algunos ejemplos de cómo ocurrió, para sugerir maneras de exploración

y cuando se preserven dichas libertades sobre las copias y modificaciones, bajo los términos de la 
\emph{Academic Free License} 3.0 (AFL). 

Para ver una copia de la AFL, visite: \\
\url{https://tldrlegal.com/license/academic-free-license-3.0-(afl)#fulltext}

\textbf{Colofón} \\
Esta tesis fue escrita con TeXsutio y compilada con \XeTeX\ 3.14159265--2.6--0.99998 (\TeX\ 
Live 2017) usando el tipo de letra \mbox{{\fanciestfont{}Libertine}}. 
% \texttt{GT Pressura} and $\mathrm{Asana\ Math}$.
La mayoría de las figuras fueron creadas usando Roassal 1.2 y Grafoscopio 1.5.x sobre Pharo 6.1.
Los mapas mentales fueron hecho en Freeplane.
El esquema visual fue logrado sobre una plantilla provista por Ken Arroyo Ohori.

El código fuente de esta tesis, así como de muchos de los escritos y trabajos realizados por
el autor de esta tesis durante su doctorado está disponible en:\\
\url{http://mutabit.com/repos.fossil/doctorado-offray/}

	en los años de pausa, y más allá, este artefacto híbrido\\
	no existiría.
\end{custom-dedication}

\begin{custom-dedication}
	En memoria de:\\
	\addvspace{}
	Alirio Cárdenas Pachón, mi tío, ganadero y agricultor, asesinado en los violentos campos de Colombia.\\
	Aaron Schwartz, activista hacker, quien se suicido después de la persecusión excesiva del \\
	gobierno norteamericano por liberar artículos académicos.\\
	Bassel Khartabil, activista de la cultura libre, encarcelado y ejecutado por el gobierno Sirio.\\
\end{custom-dedication}

y Smalltalk, pero en general aquellas charlas encontraban poco eco en la comunidad.

Por aquel entonces también estábamos definiendo la infraestructura web que tendría
el sitio web de HackBo y consideré que esta sería una buena oportunidad para la investigación-acción,
que permitiera poner en diálogo mi investigación con los problemas cotidianos y apremiantes de
la comunidad.
La intención sería configurar un espacio web que habitáramos los integrantes de HackBo,
Un hábitat digital, en palabras de \cite{wenger_digital_2009}.
y ver cómo en la medida en que lo poblábamos, lo ibamos extendiendo y cambiando,
de maneras similares a las experiencias previas como las que tuvimos con El Directorio
(referenciado en la sección \ref{mi-lugar}), pero superando las limitaciones de aquel entonces.

Hice una fuerte argumentación sobre que deberíamos tener una infraestructura propia y lo 
más autocontenida posible, de manera que contáramos con un sólo sitio autónomo que contuviera buena
parte de nuestra presencia: blogs, wikis, videos, enlaces, archivos, etc.
Sugerí e implementé Cynin\footnote{\url{http://cyn.in/}}, pues su arquitectura era robusta 
(basado en Zope/Plone) y estaba hecho en un lenguaje de \emph{scripting} Python, que si bien no era 
tan popular como PHP para aplicaciones web, sí era usado en múltiples dominios además de la web, 
así que el aprendizaje del mismo podría permitirnos movernos a otras temáticas.
Además, estaba mi experiencia en el uso de Cynin para configurar el hábitat digital para 
el proyecto de investigación Narratopedia (\cite{luna_cardenas_habitats_2011})
y creía que dicha experiencia podía ser traída de los limitados marcos académicos al
grueso de la comunidad.

Pero Cynin reveló ser extremadamente complejo y con una alta curva de aprendizaje.
Habían muy pocos expertos locales en la infraestructura Zope/Plone que no eran muy
cercanos al espacio.
El punto de quiebre se dio cuando el sitio de HackBo en Cynin se hizo inestable

	\end{figure*}
	\clearpage
}

Se planteó una bifurcación, propia de las comunidades hacker y una resolución 
desde la \emph{tiranía del hacedor}: cualquiera podría implementar el sitio web, 
en la tecnología que quisiera, siempre y cuando mostrara resultados en el corto tiempo.
Leonardo Urrego hizo una página de llegada (\emph{landing page}) en HTML y Javascript que 
resolvía la contingencia y con él y Jorge Guevara implementamos el primer borrador del sitio 
usando un \emph{web framework} hecho en Python, llamado web2py\footnote{\url{http://web2py.com/}}.
Nadie más implementó el sitio en PHP.
Este es un ejemplo de cómo se dice con acciones/infraestructuras, desde las dinámicas del
hackerspace, mostrado desde una perspectiva más teórica en la sección \ref{hackbo}.
cuando se mencionó cómo se decía desde las acciones y las infraestructuras y cómo
ciertas argumentaciones quedaban resueltas (o no) a través de la posibilidad de
expresarse sobre y desde la tecnología digital misma, en este caso sobre la necesidad
de tener infraestructuras autónomas y programables por nosotros mismos.
Hablar desde las infraestruturas acerca de la autonomía en la presencia en línea,
implicaba tener la capacidad, el tiempo y el interés de desplegar y programar las 
infraestructuras para lograr dicha autonomía.

Esto marcó el inicio de un primer hábitat digital para HackBo, que era principalmente 

hecho por mi, con ayuda de miembros de la comunidad y otros cercanos, como Iván Pulido.
Allí se experimentaron algunas características, como adicionar enlaces o
noticias para el sitio y la de mayor uso colectivo: la programación de eventos y
actividades dentro del espacio de HackBo, con su respectiva publicación de actividades
pasadas y venideras.
Las pocas solicitudes externas no fueron implementadas rápidamente.
La idea era alentar que las mismas personas en la comunidad reportaran e implementaran
las soluciones, expandir el conocimiento sobre dicho hábitat y cómo está construido.
Pero la estrategia fue inadecuada y no despertó mayor interés.
El sitio se ceñía a su funcionalidad básica de eventos y otras funcionalidades,
como la del wiki, fueron delegadas en infraestructuras administradas
por nosotros en nuestros propios servidores web, pero prehechas por otros.

Esta combinación entre lo prehecho y lo hecho por unos pocos miembros dentro
de HackBo, permitió lidiar con cierto descontento por la ausencia de características
en el sitio implementado en web2py.
Para las cosas específicas haríamos desarrollos propios (usando web2py y Python),
y para otras apelaríamos a software libre y sus \emph{plugins}, como 
Dokuwiki\footnote{\url{http://dokuwiki.org/}}, el potente y sencillo wiki hecho en PHP,
lo cual generaba un punto medio entre las dos posturas en la comunidad.
Aún así, no muchos miembros usaron el wiki.

De nuevo el sitio de HackBo se cayó, aunque esta vez no fue por el SPAM.
Ya contábamos con una sede exclusiva en nuestra actual localización en el barrio Javeriana.
Como implementador, anfitrión y proponente de sitio en las tecnologías precedentes
(Cynin y web2py), era responsable por él y sentí que era también el momento de desentenderme del mismo.
Su impacto en la visibilidad de la comunidad era alto, al ser el lugar de entrada en línea a la misma.
Los requerimientos frente a su correcto funcionamiento o la ausencia de características,
sin ser frecuentes, eran demandantes cuando ocurrían y su gestión y modificación era solitaria.
La funcionalidad principal de gestionar eventos había sido delegada por otros miembros del
hackerspace en una infraestructura externa de Meetup y si bien no teníamos control sobre ella, 
la convocatoria había crecido, pues se adecuaba a las lógicas de esa web feudal, en la que otros 
ponen la infraestructura y nosotros los contenidos y las interacciones.

Esta normalización de esa forma de ver y usar la infraestructura hacía que muchas
personas y comunidades usaran ya este tipo de lugares y fuera fácil encontrar otras comunidades
y lanzar convocatorias genéricas en ese sitio, con el consecuente aumento de asistentes a los
eventos.

Así que migré el sitio web de HackBo a otra infraestructura web, llamada 
Grav\footnote{\url{https://getgrav.org/}}, que al estar en PHP, y no requerir de base de datos, 
tenía la ventaja de ser fácilmente desplegable en servidores web relativamente genéricos, 
sin preocuparse por las migraciones de datos (cosa que no pasaba con Cynin o web2py).
El uso de lenguajes de etiquetamiento ligeros para documentación 
(Markdown\footnote{\url{https://es.wikipedia.org/wiki/Markdown}}) y descripción de datos 
(Yaml\footnote{\url{https://es.wikipedia.org/wiki/YAML}}), similar al que usa en Grav, 
ya había sido prototipado por mi previamente en un proyecto en web2py (llamdo Brea) 
y era neutral respecto al lenguaje de programación, pudiendo intervenirse y extenderse en

Desde finales del 2012, había empezado a explorar formas de combinar la escritura 
arbórea de Leo\footnote{\url{http://leoeditor.com/}}, con la escritura interactiva de libretas 
en IPython\footnote{\url{https://ipython.org/}}, lo cual permitiría ir agregando estructura progresiva 
y emergente del primero a la computación  exploratoria propia del segundo.
En aquel entonces escribí en la entrada al blog titulada 
\emph{On ``deepness'' and complexity of IPython documents}\footnote{\url{https://is.gd/4JEVo1}}
(\cite{luna_cardenas_``deepness_2013}):

\begin{quote}
	Fernando Pérez, primer autor y co-lider de proyecto de IPython, ha hablado acerca de la naturaleza explorativa
	de la computación científica y cómo esto se mantiene también para muchos usuarios de computador.
	Estoy de acuerdo. La mayoría de las veces, los usuarios (científicos) no tienen un estricto conjunto de reglas
	predefinidas para orientar o restringir  su interacción con los computadores.
	Una pregunta entonces, es cómo esta naturaleza explorativa de la interacción con el computador,

	donde diferentes implementaciones, como aquellas exploradas/propuestas acá, puedan hablar
	con otras más visibles [...].
	Para ello, los protocolos y los metadatos serán más importantes en habilitar la interoperabilidad
	entre diferentes abordajes, pero siguiendo el 
	consejo\footnote{\url{http://indiewebcamp.com/Principles}}
	del movimiento por la Indie Web:
		\begin{itemize}
			\item 
				La experiencia de usuario (UX) es más importante que los protocolos.
			\item 
				Usa datos visibles para los humanos primero y las máquinas después.
			\item 
				Construye herramientas para tí mismo, no para todos tus amigos
				\footnote{Nótese la palabra "todos". 
					Los colectivos se forman, pero no con todos los amigos, sino unos pocos 
					y unos nuevos convocados por las herramientas, que surgieron de rascar
					una comezón individual, por emplear la metáfora ya mencionada, y que
					luego es compartida por otros con intereses/comezones similares.}.
			\item 
				Construye para la web duradera.
			\item 
				Diviértete.
		\end{itemize}
		
\end{quote}
	
Estos y otros principios compartidos con el proyecto fueron un descubrimiento clave respecto
a dejar intentar convocar o complacer a los miembros de la comunidad nuclear de HackBo, como
lo había hecho desde los hábitats digitales web antes mostrados y trabajar más desde procesos
de largo aliento, centrados en unos pocos que estábamos yendo a los talleres de 
\emph{Indie Web Science}, desde la experiencia que teníamos al usar y construir dichos lugares
más pequeños para proyectos más puntuales y personales que vincularan formas de contar y publicar
historias, mediadas por datos y visualizaciones, desde infraestructuras propias y alternativas.

También retomé estos principios cuando empecé a experimentar con otras metáforas escriturales
que me permitieran abordar las complejidades de la tesis y sus múltiples capas empleando 
Leo (\cite{luna_cardenas_forma_2014}), un metaeditor de texto para dar cuenta del caracter no lineal 
de la escritura y sus niveles de ``profundidad'', de los cuales el texto final en PDF es sólo la 
``superficie''.
Leo permite escribir de manera ``arbórea'', para dar cuenta de lo anterior, pero además la estructura
de árbol es auto-referente, con lo cual se puede usar una de las ramas para definir, a través del 
\emph{scripts} lenguaje de programación Python, recorridos en todo el árbol y decir cuáles de 
sus ramas ignorar para producir el PDF. 
%Para eso se elaboraron dos  en el lenguaje de programación Python, 
%El desarrollador lider de Leo es Edward K. Ream.

En estas exploraciones también se definieron elementos que luego serían importantes para la creación
de Grafoscopio: el uso de la variante Markdown de Pandoc como lenguaje de etiquetamiento ligero 
por su soporte para referencias bibliográficas, notas al pie, metadatos expresado en YAML; la 
integración con el gestor blbiográfico Zotero para manejar dichas referencias y la creación de 
una colección abierta en el mismo para el doctorado, (que alcanzó más de 3400 items desde entonces), 
así como reiterar el uso de Fossil, un sistema de control de versiones distribuido, minimalista, 
autocontenido ligero y fácil de usar para publicar archivos de textos, imagen, código fuente y 
su historia. 
En un repositorio público de Fossil, que había creado para el doctorado desde el 2011, coloqué 
los escritos hechos y exportados desde Leo, (véase: \url{mutabit.com/repos.fossil/doctorado-offray/}) 
y que ha contenido la historia de varios artefactos creados durante el mismo, incluida esta misma tesis.

Las piezas de infraestructura se estaban juntado.
Pero la infraestructura misma era un medio y un fin para comunicar y explorar las ideas 
sobre autonomía, cumpliendo los postulados de \cite{saikaly_approaches_2005}, y los 
prototipos desarrollados en ella permitían recorridos específicos en los que las
infraestructuras cambian y se combinan para permitir argumentos más específicos sobre
lo que importa de esa autonomía y dónde nos queremos enfocar para que esos ejercicios
desde la autonomía misma, aquieran sentido para varias personas.
En este caso particular, una inquietud gruesa por cómo habitábamos la web desde
HackBo, retomaba aprendizajes y pérdidas sobre lo que había ocurrido con otras
infraestructuras como El Directorio, llevándonos a sistemas autónomos pero
complejos/complicados (Cynin) a otros ligeros y programables (web2py) a unos
aún más sencillos (Grav) y conexos con otros (Meetup, GitHub, Dokuwiki), de
manera que las preocupaciones propias y las comunitarias, así como incidencias
no planeadas (SPAM y tiempo) daban forma a los usos de las infraestructuras
que usábamos y permitían enfocarse en otras por venir, que transmitirían de
mejor manera preocupaciones venideras y los intereses de esta tesis por
por la modificación recíproca entre comunidades y artefactos digitales,
al mismo tiempo que entrarían en diálogo con inquietudes sobre formas de
ejercer ciudadanías.

Pero la necesidad por estas narrativas computacionales, que mezclaran datos e interacción,
y empoderaran voces ciudadanas desde desarrollos locales, se hizó más evidente a partir 
de unas hackatones que surgieron como resistencia desde HackBo a la enajenación del discurso 
hacker por parte del estado, desde el discurso del ``emprendimiento'', pero con unas lógicas 
de explotación.
Estas serán ampliadas en la siguiente sección.

%NOTA: buscar fechas para Indie Web, Gobernaton y entrega del portal.

\section{La Gobernatón: La hackatón como acto de resistencia y crítica desde la sociedad cívil}\label{gobernaton}

Las \emph{hackatones} son maratones de prototipado y resolución de problemas.
El término, que a su vez combina los términos \emph{hack} y \emph{maratón} parece haber
surgido, según la Wikipedia (\cite{noauthor_hackathon_2017}), tanto entre los desarrolladores 
del sistema operativo OpenBSD, como entre los miembros del equipo de mercadeo de \emph{SUN Microsystems}.
Desde entonces este término ha sido reapropiado, diversificado y dislocado para
incluir diversos tipos de hackatones (10, en la taxonomía de la Wikipedia)
y ha sido aproximada de manera crítica por autores como \cite{lilly_irani_hackathons_2015}

y \cite{schrock_hackathons_2016}, denunciando lógicas de solucionismo tecnológico y una manera 
limitada y limitante de concebir la ciudadanía, pues como afirma Irani, ``las hackatones algunas 
veces producen tecnologías, y ellas siempre, sin embargo, producen sujetos''(p. 2), en la medida
en que configuran imaginarios y formas de acción respecto a qué es ser un ciudadano y cómo estas 
formas de ciudadanía pueden ser mediadas por tecnología desde una percepción de ``innovación'' 

y una ``política que favorece la acción rápida y forzada entre colaboradores socialmente similares, 
sobre las contestaciones de la democracia masiva o la lenta construcción de coaliciones sobre la 
diferencia''.(p. 3)

El fenómeno hacker, multisituado y de orígenes diversos, también está siendo 
gentrificado, como diría \cite{lilly_irani_hackathons_2015} en distintos lugares con la lógica 
uniformizante del ``emprendimiento''. 
No importa si se trata en India, (\cite{lilly_irani_hackathons_2015}: Hackatones y la creación 
del ciudadano emprendedor), Estados Unidos (\cite{schrock_hackathons_2016} Hackatones sin hackeo 
y \cite{scott_how_2015}: El Hacker hackeado: como los yuppies hackearon el ethos hacker 
original\footnote{Título traducido del original \emph{The hacker hacked: How yuppies hacked the 
		original hacker ethos}}),
o Colombia, donde el programa Gobierno en Línea lanzó la \emph{hackatón de gobierno móvil} (HGM).
Al igual que en otras latitudes, dicha hackatón, iniciada en Bogotá,
tenía un fuerte pensamiento desde el solucionismo tecnológico, 
con el sesgo hacia la acción emprendedora y a cruzar la distancia sin caminarla,
denunciada por Irani:

\begin{quote}
	La frase ``sesgo a/por/hacia la acción'' era empleada rutinariamente
	para describir la figura de un hacedor emprededor que usaba atajos a la
	cinta roja burocrática y las largas deliberaciones en busca del eficiente, progreso inspirado.
	Progreso, en este discurso profesional, con frecuentes soluciones visibles
	—servicios, infraestructuras, negocios y orden público—
	en lugar de justicia procedimental o redistribución de los 
	derechos.\footnote{Esta lógica de soluciones visibles mercadeables es consecuente con la
			provocación de Scott sobre cómo el espíritu rebelde del hacker ha sido orientado
			hacia la consecución y el servicio al capital.}
\end{quote}

\begin{quote}
	Este sitio realmente existente de prácticas de diseño reveló que sus políticas estaban en sus formas
	y sus normas — en su manufacturada urgencia, en la distancia entre el estudio y el mundo,
	y en la ecología de medios que hacia posible prometer cruzar la distancia sin caminarla.
\end{quote}

La lógica del espectáculo en la hackatón (\cite{scott_how_2015}) también estuvo presente,
en la HGM, con las respectivas campañas en redes sociales 
y, luego, (quizás reforzado por la crítica hecha desde HackBo con la Gobernatón) 
con la idea de adscribirse a otros eventos de asistencia masiva, 
como la Campus Party de 2013 y los eventos de emprendiento del \emph{Startup Weekend}.

Pero lo que llamaba fuertemente la atención y prendió las alertas en 
Twitter y Facebook, tanto en las comunidades de base tecnológica como en la emprededora, 
era el costo del contrato y los modelos de reparto de dividendos, lo que
generó una \emph{contrahackatón}, 
la \emph{Gobernatón} \footnote{El nombre fue resultado de una broma: Si desde el Gobierno
	no sabían organizar una \emph{hackatón}, desde HackBo íbamos a organizar una \emph{Gobernatón}.},
que organicé y lideré desde HackBo. 
Como afirmé en aquel entonces (\cite{luna_gobernaton:_2013}):

\begin{quote}
	La Gobernaton es una iniciativa ciudadana de innovación social y abierta. Inició como una crítica 
	constructiva a una iniciativa de MinTIC en 2013 que gastó 2700 millones de pesos en la supuesta 
	inversión en innovación social, pero que pararon, principalmente, en las arcas de intermediarios 
	en lugar de en la construcción de beneficio colectivo. 
	El balance de la Gobernatón como contrapropuesta cívica fue bastante alentador:
\end{quote}

La participación fue plural: vinieron miembros de HackBo y personas externas.
La mayoría hicieron código, otros se encargaron de publicitar el evento,
algunos querían explicar teorías políticas, otros querían aumentar la base de
datos y/o hacer la corta charla publicitaria (\emph{pitch}) para sus emprendimientos.
Algunas empresas y fundaciones donaron la pizza.
Entre usa sesión y la otra del evento la población varió y si bien participaron intensivamente
al comienzo, al final del mismo, fueron disminuyendo.
El listado de prototipos fue diverso: algunas de ellas eran aplicaciones web,
otras aplicaciones móviles (\emph{apps}).
La mayoría de prototipos no sobrevivió ni continuó más allá de este primer encuentro 
(como también han observado \cite{lilly_irani_hackathons_2015}, \cite{schrock_hackathons_2016} 
y \cite{vila_permanent_2013}).

\subsection*{De las apps y los portales a las narrativas computacionales}\label{hacia-narrativas-computacionales}

Durante la primera gobernatón se hizo claro para mi, que una estrategia
alternativa a la de crear una \emph{app} o un portal web era la de contar una historia
soportada por datos, pues nuestros argumentos sobre lo irregular del
llamado del Ministerio de las TIC a ``participar'' de la hackatón de gobierno

particularmente del gobierno, basados en datos y técnicas computacionales 
podrían sobrevivir al evento específico de la gobernatón.
Era la historia que se desplegaba sobre estas nuevas formas de participación 
ciudadana y las técnicas para contarla lo fundamental.
Encontré que este tipo de iniciativas también estaban tomando cuerpo en otras
latitudes bajo el nombre de periodismo de datos.
%NOTA[Captura de pantalla de dokuwiki con las referencias respectivas]

Se ve acá un tránsito progresivo de lo hacker a lo hacktivista, considerado en el
capítulo previo, pues técnicas e infraestucturas informáticas eran reapropiadas
para propósitos cívicos y ciudadanos convirtiéndose en un ejercicio de repolitización
del código, pero también se trataba de un ejercicio de reflexión auto-crítico, al
ver más allá de los procesos de gentrificación con los cuales algunas de esas repolitizaciones
se ven confinadas e incluso repensando dinámicas ocurridas dentro del espacio, de manera
tal que facilitaran la conformación del mismo como espacio para expandir las prácticas
ciudadanas, transformando los artefactos con los que nos dedicábamos a ellas.
Es decir, en la medida en que el investigador habitaba el prototipo, que la comunidad
del Hackerspace configuraba, respecto a otras formas de habitar el mundo, efectivamente
se veía a la comunidad y a sí mismo dentro de ella, transformándose y explorando nuevas
prácticas desde la condición de espacios y sujetos políticos habitando el hackerspace.
Esta es una concreción misma del diálogo estructura agencia desde el hackerspace,
tomando cuerpo en las formas de hacer nuevas y los artefactos nuevos que las soportaban,
en el tránsito específico de apps y portales a narrativas de datos se configuraban
nuevas voces ciudadanas y artefactos que las posibilitaran.
Se trataba de una tensión dialéctica como las que se han indicado desde \cite{fuchs_autopoiesis_nodate},
tomando cuerpo y siendo enunciadas desde los artefactos y las prácticas que
habilitadas por ellos, es decir dicha dialéctica tomaba forma desde las maneras
de argumentar propuestas por \cite{isin_being_2015} en contraste con otras prácticas
e infraestructuras que desplegaban los esfuerzos más gentrificadores y utilitaristas
de las tecnologías digitales, como las que se mostraron acá por parte de entidades
gubernamentales.

La combinación de estas tecnologías para argumentar e interlocutar con el
poder estatal recogía lo que habíamos hecho en los talleres de \emph{Indie Web Science}
referidos a crear y publicar libretas de notas/argumentos computacionales,
y también se convertiría en un puente con lo que vendría después, intentando
transpasar los límites de tales tecnologías complicadas y encuentros intensivos, 
pero sin continuidad y la difusión de la experticia: %NOTA: Incluir: http://mutabit.com/offray/static/blog/output/posts/medios-en-colombia.html ?
Grafoscopio, como artefacto y El Data Week y las Data Rodas y otros encuentros, como 
experiencias de aprendizaje.
Este será el tema de los capítulos siguientes.

								}
							],
							#parent : @93,
							#level : 2,
							#links : OrderedCollection [
								''
							]






























































































































































































						},
						GrafoscopioNode {
							#header : 'Lines of code',
							#body : '| totalLines myPackages myPackagesSizes b ds lb |
myPackages := {
\'Brea\'.
\'Dataviz\' .

myPackagesSizes ',
							#tags : OrderedCollection [
								'código'
							],
							#children : OrderedCollection [ ],
							#parent : @93,
							#level : 2,



							#links : OrderedCollection [
								''
							]
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},
				@96,
				@99,
				@103,
				@108,







				GrafoscopioNode {
					#header : '%borrar Anexos',
					#key : '',
					#body : '',
					#tags : OrderedCollection [
						'text'
					],

						}
					],
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},
				@116,
				GrafoscopioNode {
					#header : 'Gráficas',
					#key : '',
					#body : 'Los códigos para hacer las gráficas fueron movidos al archivo workbook.leo, que se abre por omisión.
Por lo pronto es mejor trabajar dichos trozos desde allí, pues leo tiene mejores atajos de teclado y maneras
de aumentar la fuente (al igual que TeXStudio), lo que es un factor de ergonomía bien importante para
escritura prolongada de texto.

"Esto apunta al repositorio en GitHub, pues será más fácil clonarlo y adaptarlo
luego al diplomado \'alvicoda\', sin embargo el repositorio aún no está completo.
La intensión de todos modos es tener los enlaces de referencia, para luego traducirlos
con Amara al español y presentarlos durante el diplomado."',
									#tags : 'código',
									#children : OrderedCollection [ ],
									#parent : @128,
									#level : 3
								}
							],
							#parent : @125,
							#level : 2
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						'',
						''
					]
				},
				@128,
				@131,
				GrafoscopioNode {
					#header : 'Artículos',
					#body : 'Dada la relevancia que ocupan los artefactos de software en la tesis y la intensión
explícita de la misma de crear y validar objetos no hegemónicos de conocimiento,
que vayan más allá del fetichismo por el artículo en la publicación indexada y sean
consistentes con las epitemologías del diseño, presentadas en la primera parte,
acá se ha optado por presentar los dos artefactos de software a la publicación

								GrafoscopioNode {
									#header : 'Announcing The Journal of Open Source Software | Weakly Typed',
									#body : '',
									#tags : OrderedCollection [
										'text'
									],
									#children : OrderedCollection [ ],
									#parent : @137,
									#level : 3,
									#links : OrderedCollection [
										'',
										'',
										'',
										'',
										'http://www.arfon.org/announcing-the-journal-of-open-source-software'
									]
								},
								GrafoscopioNode {
									#header : 'Author Guidelines',
									#body : '',
									#tags : OrderedCollection [
										'text'
									],
									#children : OrderedCollection [ ],
									#parent : @137,
									#level : 3,
									#links : OrderedCollection [
										'',
										'',
										'http://joss.theoj.org/about#author_guidelines'
									]
								},

											#body : '> The Journal of Open Research Software (JORS) features peer reviewed Software Metapapers describing research software with high reuse potential. We are working with a number of specialist and institutional repositories to ensure that the associated software is professionally archived, preserved, and is openly available. Equally importantly, the software and the papers will be citable, and reuse will be tracked.

> JORS also publishes full-length research papers that cover different aspects of creating, maintaining and evaluating open source research software. The aim of the section is to promote the dissemination of best practice and experience related to the development and maintenance of reusable, sustainable research software.',
											#tags : OrderedCollection [
												'text'
											],
											#children : OrderedCollection [ ],
											#parent : @148,
											#level : 4,
											#links : OrderedCollection [
												'',
												'',
												'',
												'',
												'http://openresearchsoftware.metajnl.com/'
											]
										},
										GrafoscopioNode {
											#header : 'SoftwareX',
											#body : '> SoftwareX aims to acknowledge the impact of software on today\'s research practice, and on new scientific discoveries in almost all research domains. SoftwareX also aims to stress the importance of the software developers who are, in part, responsible for this impact.

Es publicado por Elsevier, a pesar de ser Open Access. Mejor apoyar otras iniciativas que no tengan asociaciones a editoriales con prácticas de privatización de conocimiento y explotación de los académicos como esta.',
											#tags : OrderedCollection [
												'text'
											],
											#children : OrderedCollection [ ],
											#parent : @148,
											#level : 4,
											#links : OrderedCollection [
												'',
												'',
												'https://www.journals.elsevier.com/softwarex/'
											]
										}
									],
									#parent : @137,
									#level : 3,
									#links : OrderedCollection [
										'',
										''
									]
								}
							],
							#parent : @134,
							#level : 2,
							#links : OrderedCollection [
								'',
								'',
								'',
								'',
								'',

  # References
  ',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @134,
							#level : 2,
							#links : OrderedCollection [
								'',
								'',
								'',
								'',
								'',

  # References
  ',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @134,
							#level : 2,
							#links : OrderedCollection [
								'',
								'',
								'',
								'',
								'',

						'',
						'',
						'',
						'',
						''
					]
				},
				@137,
				@140,
				@144,
				@148,
				@151,
				@155,
				@161,
				@165,
				GrafoscopioNode {
					#header : 'Participación en Eventos',
					#body : '',
					#tags : OrderedCollection [
						'text'
					],
					#children : OrderedCollection [
						GrafoscopioNode {
							#header : 'Hackademia',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'Smalltalks 2015',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'ESUG 2016',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'Big Data from the South',

									#tags : 'código',
									#children : OrderedCollection [
										GrafoscopioNode {
											#header : 'Subcolección BDS',
											#body : '(ZoteroLibrary new groupID: \'\') subcollection:\'6GE8GRDX\'',
											#tags : 'código',
											#children : OrderedCollection [ ],
											#parent : @188,
											#level : 4,
											#links : OrderedCollection [
												''
											]
										},
										GrafoscopioNode {
											#header : 'Subcolección como BibTeX',
											#body : '(ZoteroLibrary new groupID: \'329470\') subcollectionAsBibTeX: \'6GE8GRDX\'',
											#tags : 'código',
											#children : OrderedCollection [ ],
											#parent : @188,
											#level : 4,
											#links : OrderedCollection [
												''
											]
										},
										GrafoscopioNode {
											#header : 'BibTeX as file',

\tifTrue: [ bibFile delete ] 
\tifFalse: [ bibFile ensureCreateFile ].
bibFile writeStreamDo: [ :stream | stream nextPutAll: bibTeXData ].
bibFile
',
											#tags : 'código',
											#children : OrderedCollection [ ],
											#parent : @188,
											#level : 4,
											#links : OrderedCollection [
												'',
												'http://ws.stfx.eu/4138G3OYJZ9I',
												'http://ws.stfx.eu/5NQ4UFNDRO9M'
											]
										}
									],
									#parent : @185,
									#level : 3,
									#links : OrderedCollection [
										''
									]
								}
							],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'ISEA',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [
								GrafoscopioNode {
									#header : 'Items de la subcolección',
									#body : '(ZoteroLibrary new groupID: \'204755\') subcollectionAsBibTeX: \'QE5NGJXF\'',
									#tags : 'código',
									#children : OrderedCollection [ ],
									#parent : @201,
									#level : 3,
									#links : OrderedCollection [
										''
									]
								}
							],
							#parent : @170,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},
				@173,
				@177,
				@181,
				@185,
				@188,
				@190,
				@193,
				@196,
				@201,
				@204,
				GrafoscopioNode {
					#header : 'Notas',
					#body : '',
					#tags : OrderedCollection [
						'text'
					],
					#children : OrderedCollection [
						GrafoscopioNode {
							#header : 'Los hackers son "bienes" recursivos',
							#body : 'Kelty [1] habla de cómo los hackers crean bienes recursivos, como el Internet y el software libre, es decir, bienes que les permiten crear más bienes, que les permiten estar juntos. Yo diría que el bien recursivo que los hackers crean por naturaleza es el de los hackers mismos.

[1] http://kelty.org/or/papers/unpublishable/Kelty.RecursivePublics-short.pdf',
							#tags : OrderedCollection [ ],
							#children : OrderedCollection [ ],
							#parent : @209,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},
				@212,
				GrafoscopioNode {
					#header : 'Kanban',
					#body : '',
					#tags : OrderedCollection [
						'text'
					],
					#children : OrderedCollection [

b dates: (dictByDate keys min to: dictByDate keys max).
^ b
',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												},
												GrafoscopioNode {
													#header : 'Usando commits en Fossil',

b dates: (dictByDate keys min to: dictByDate keys max).
^ b
',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														'',
														'http://ws.stfx.eu/BBZHG8UA1529'
													]
												},
												GrafoscopioNode {

b build.
(b view elements select: [ :e | e model isKindOf: Month ]) pushFront.
^ b view',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												},
												GrafoscopioNode {
													#header : 'Fossil: Paleta de colores',
													#body : '"La idea es obtener un color por cada valor en una paleta
de colores."
| testRepo colors valuedColors |
testRepo := FossilRepo new
\tremote: \'http://localhost:8080/\'.
colors :=  RTColorPalette sequential colors: 9 scheme: \'Greens\'.
valuedColors := testRepo commitsByDate collect: [ :v |
\tcolors at: v // 2 + 1 ].
',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												},
												GrafoscopioNode {
													#header : 'Calendario con datos en Fossil',

(b view elements select: [ :e | e model isKindOf: Month ]) pushFront.
^ b view
',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														'',
														'http://ws.stfx.eu/EQ5ZTLRQMSH2'
													]
												},
												GrafoscopioNode {
													#header : 'Commits calendar',
													#body : '| urls repo palette |
urls := #(\'http://mutabit.com/repos.fossil/mapeda\' \'http://localhost:8080/\' \'http://localhost:8081/\').
repo := FossilRepo new
\tremote: (urls at: 2).
palette := RTColorPalette sequential colors: 9 scheme: \'Blues\'.
repo commitsCalendarFrom: 201 to: 2017 colored: palette

',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												},
												GrafoscopioNode {
													#header : 'Paleta de colores',
													#body : 'RTColorPalette sequential colors: 9 scheme:\'Greens\'',
													#tags : OrderedCollection [
														'código'
													],
													#children : OrderedCollection [ ],
													#parent : @226,
													#level : 5,
													#links : OrderedCollection [
														''
													]
												}
											],
											#parent : @223,
											#level : 4,
											#links : OrderedCollection [
												''
											]
										}
									],
									#parent : @220,
									#level : 3,
									#links : OrderedCollection [
										''
									]
								},
								GrafoscopioNode {
									#header : 'Evolución de código',
									#body : '  - [Code Frequency](https://github.com/rqlite/rqlite/graphs/code-frequency): Código borrado vs código agregado, por fecha.
  - [Commits](https://github.com/rqlite/rqlite/graphs/commit-activity).
  - [Contributors](https://github.com/rqlite/rqlite/graphs/contributors).',
									#tags : OrderedCollection [
										'text'
									],
									#children : OrderedCollection [ ],
									#parent : @220,
									#level : 3,
									#links : OrderedCollection [
										''
									]
								}
							],
							#parent : @217,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						},
						GrafoscopioNode {
							#header : 'Brea',
							#body : '',
							#tags : OrderedCollection [
								'text'
							],
							#children : OrderedCollection [ ],
							#parent : @217,
							#level : 2,
							#links : OrderedCollection [
								''
							]
						}
					],
					#parent : @5,
					#level : 1,
					#links : OrderedCollection [
						''
					]
				},
				@220,
				@223,
				@226,
				@229,
				@233,
				@237,
				@241,
				@245,
				@249,
				@253,
				@259,
				@264
			]
		},
		#level : 1,
		#links : OrderedCollection [
			''
		]
	},
	@8,
	@11,
	@14,
	@29,
	@93,
	@113,
	@121,
	@125,
	@134,
	@170,
	@209,
	@217
]