Activation barriers to new tools

Use case: trying to use Dat to work together.

We started by looking at a number of topics from the discussion list, and discovered that a common theme across all of the topics that this group was “Activation Barriers”. To try to ground this in a particular experience we also decided to try to use the dat project for sharing the writeup. After about 10 minutes it becomes clear that we were indeed experience “barriers” and decided to default to writing up our experiences using an ether pad (and try to copy/paste that to Dat ;-) ), but we were able to get some real examples of these barriers from this toy excercie.

About Dat

Dat is built on top of hyperdive a javascript peer to peer “file sharing network based on rabin file chunking and append only feeds of data verified by merkle trees.”. Dat is often referred to as the git for data.

Experiences in installing Dat

After a cursory reading of the docs it was clear that we should aim to use the command line Initially we tried to install the desktop client

We had to install the project across three machines. Two Macs and a PC. There is a command line interface available, and desktop interface available for Mac. Notably one of the group didn’t have a machine, so we immediately ran into a “hardware” issue. The windows machine was not able to install dat at all. The two Mac users got dat working locally, but both had previous experience with npm. On the offset it looked like we were not going to be able use dat across all the members of the team.

Experiences using Dat

  • able to install but unable to get access to the file
  • download not Windows-compatible; failure to install from terminal (for one of us)
  • contacting company contact through Twitter ;-) got a quick response! had a support-conversation on Gitter, at that point, it just magically seemed to start working.

Used this example to evaluate previously identified barriers at both institutional/organizational, individual level and tool provider level

Identified activation barriers:

  • At institutional/organizational level:
  • time / (hu)manpower
  • money
  • security
  • expertise

The four main barriers from an organisational perspective could be: time, money, security and expertise. Of these security is a prime aspect. From an ISG perspective and security protocol has the tool been fully tested. Additionally, there are costs that an individual may not face. Open source models may be free for indivduals but may come at costs for businesses or educational organisations. Furthermore, there are associated costs in terms of training, support, and expertise.

As we’re not at/from one organization, this didn’t really apply in this case. However, would we have been, Dat could have been pre-installed on all machines, and instructions and support provided. If it weren’t,it would depend on the organization whether it would allow individual installation, as Dat is not accessible online-only.

  • At individual level:
  • hardware / OS
  • time
  • security
  • availability
    • institutional
    • available to install / access
  • familiarity / knowledge

We ran into problems with hardware (OS compatobility) and familiarity/knowledge (different skills/knowledge levels).

  • At tool provider level
  • quality ;-)
  • availability (OS, cost, license)
  • documentation
  • customer support

We ran into problems with OS compatibility and documentation, but customer support was available quickly (personal contacts helped here). Which might or might not have to do with the fact that it suddenly worked ;-)

Final remarks

The choice to use this spefic tool was exploratory-driven. We only explored mostly technical possibilities/barriers. Ian will bring the experiences here up with Dat-people/experts later.