<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Decentralized Creation of Academic Documents Using a Network Attached Storage (NAS) Server</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Johannes Wilm</string-name>
          <email>mail@johanneswilm.org</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Afshin Sadeghi</string-name>
          <email>sadeghi@cs.uni-bonn.de</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Christoph Lange</string-name>
          <email>langec@cs.uni-bonn.de</email>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Philipp Mayr⁴.</string-name>
          <email>philipp.mayr@gesis.org</email>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>GESIS-Leibniz Institute for the Social Sciences</institution>
          ,
          <addr-line>Unter Sachsenhausen 6-8, 50667 Köln</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>University of Bonn</institution>
          ,
          <addr-line>Römerstraße 164, 53117 Bonn</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>University of Bonn</institution>
          ,
          <addr-line>Römerstraße 164, 53117 Bonn, Germany and Fraunhofer IAIS, Schloss Birlinghoven, 53754 Sankt Augustin</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2017</year>
      </pub-date>
      <abstract>
        <p>Scholarly document creation continues to face various obstacles. Scholarly text production requires more complex word processors than other forms of texts because of the complex structures of citations, formulas and figures. The perceived need for peer review, often single-blind or double-blind, creates needs for document management that other texts do not require. Additionally, the need for collaborative editing, security and strict document access rules means that many existing word processors are imperfect solutions for academics. Nevertheless, most papers continue to be written using Microsoft Word. In this position paper we analyze some of the problems with existing academic solutions and then present an argument why we believe that running an open source academic writing solution for academic purposes, such as Fidus Writer, on a Network Attached Storage (NAS) server could be a viable alternative.</p>
      </abstract>
      <kwd-group>
        <kwd>Network Attached Storage server</kwd>
        <kwd>Linux</kwd>
        <kwd>editing</kwd>
        <kwd>collaborative editing</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Issues with existing approaches</title>
      <sec id="sec-1-1">
        <title>1.1 Issues with Microsoft Word and other general word processors for academics</title>
        <p>Microsoft Word has the advantage that users are familiar with its easy to use
WhatYou-See-Is-What-You-Get (WYSIWYG) interface. However, articles authored in
Word have the problem that they lack semantic information, which means that
conversion for final publication into other formats will be more difficult and will
require human intervention. Because the conversion process is imperfect, there is also
the chance of loss of information or misinterpretation on the part of the human
executing the conversation. The same is true for open source alternatives with a
similar user interface and workflow, such as LibreOffice or OpenOffice.org.</p>
        <p>Additional problems occur if one needs to collaborate on a text among several
writers: Collaborative editors such as Google Docs or Microsoft Office 365 Online
place the documents on servers outside of the control of the user, and potentially
confidential information is shared with companies operating servers that could be
targeted by espionage. Espionage may be even easier if information is stored in a
standard data store companies.</p>
        <p>One may argue that information that is to be published will be available anyway.
This is true for a lot of fields, but there are some fields where even published material
is only made accessible to a small amount of people. And even in those circles where
it is made available publicly at the time of publication, not everyone is comfortable
with giving specific parties early access to the material.
1.2</p>
      </sec>
      <sec id="sec-1-2">
        <title>Issues with web services targeting academic writers</title>
        <p>Some new online writing services have appeared in recent years1 to target academic
writers specifically. These editors handle citations, formulas and the like, and
conversions to final output formats will therefore require less or no human
intervention.</p>
        <p>While these editors may have solved much of the conversion issues, in so far as
they are closed source applications hosted by a single company, they have the same
security issues as Google Docs and Microsoft Office 365 Online. Open source
1</p>
        <p>Among the academic text editing apps that have appeared are: Authorea, Fidus
Writer, ShareLaTeX and WriteLaTeX/Overleaf. Other, decentralized, editors exist,
such as Dokieli or Laverna, but due to the way they are opeting, they are not able
to provide realtime collaboration.
alternatives, such as Fidus Writer and ShareLaTeX, in theory have less of this issue, as
the application can be installed on a secure server. In practice, most users will not
have their own regular server, so that this option is not really accessible to them.
Should they hire server space from a third party, they may have more control over
which country their data will be stored in, but they will still be exposing their data to
the company operating the server.
1.3</p>
      </sec>
      <sec id="sec-1-3">
        <title>Issues with decentralized document editing in a collaborative way</title>
        <p>An alternative for decentralized collaboration is one where the editing application
is installed on the end user's computer. This solves the problem of the server, but it
creates a number of other challenges:
2 General installation processes are too complex for novice users. The fact that the
developers of the editing software cannot know which OS their end users will be
running makes it hard to give standardized installation instructions.
3 Users today are often working on sections of the Internet behind routers with
changing IP numbers on the internet. Permanent IP numbers are given out by
Internet Service Providers (ISPs) only for an extra fee or not provided at all.
Without any other aids, it is therefore somewhat tricky to connect two computers
with each other if they are on different local networks. While there are ways
around this problem accessible to IT professionals, it will likely be too complex
for the average end user.
4 If two users are collaborating on writing a document, but they are working at
different times and cannot guarantee that either computer is on the Internet the
entire time, merging changes becomes a problem. Even though merging
mechanisms may find a way to automatically merge changes. There is no
guarantee that the human language and argument described in the text still make
sense if texts are not merged immediately and writers can be guaranteed that the
version they are working on contains all the additions made by other
collaborators.</p>
        <p>Taken together, these points mean that a direct real-time collaboration setup cannot
reasonably be established and run by computer novices without significant help from
IT professionals.</p>
      </sec>
    </sec>
    <sec id="sec-2">
      <title>5 Decentralized document editing using a Network Attached</title>
    </sec>
    <sec id="sec-3">
      <title>Storage (NAS) Server</title>
      <p>Another option is the installation of a small and local server on the side of one of
the document editors. Even search giant Google, known for its various cloud services,
recognizes the need for data stored locally on smaller servers as it offers its Google
Search Appliance product for companies with large amounts of data2. NAS servers
can fulfill a similar role, but scaled to the comparatively smaller amount of data
needed within an academic text editing setting.</p>
      <p>NAS servers solve some of the issues encountered when trying to run collaboration
from the end user's computer: If one targets one specific NAS platform, the
installation process can be simplified to a few clicks and filling in forms that even
novice computer users can handle. The lack of a permanent IP address is made up by
a dynamic DNS service offered by the vendor of the NAS server. As the installation
and management procedures of NAS servers generally take place through web
interfaces, they are made to be capable of serving at least basic web pages. As long as
the NAS Server can be turned on and connected to the Internet constantly, it does not
matter that the end users connect to the document at different times. Another
alternative may be a mini-computer such as inexpensive Linux computers that are sold
within a similar price range of around 90-200 Euros. Different from NAS servers, they
are targeting more advanced users and do not always come with the same dynamic
DNS service built-in.</p>
      <p>The usage of NAS servers for this purpose creates some other challenges however,
as the main purpose of the devices is that of a storage device for backup of files and
not a general web server for real-time collaboration. CPU power and RAM are
therefore somewhat limited. Also, the NAS represents an extra cost to the end user,
which means that the more costly devices will not be an option in many cases.
6</p>
    </sec>
    <sec id="sec-4">
      <title>Test setup</title>
      <p>In order to find out whether a NAS Server would be a practical alternative, we took
a NAS device from the lower end of the spectrum – a Synology DS215J that had been
running online for 2.5 years for backup purposes – and we tried to install Fidus Writer
on it. Fidus Writer was chosen because it targets specifically computer novices in the
humanities and social sciences who require a WYSIWYG user interface that still
provides all the features needed for scientific text editing [1]. Other features that are
particularly useful are citation and figure management, formula editing as well as</p>
      <p>https://enterprise.google.com/search/products/gsa.html
export into a number of formats commonly used by journals, such as LaTeX and Open
Document Text (ODT). It has also recently gained the ability to be combined with the
peer-review management system Open Journal Systems (OJS) [2].</p>
      <p>The DS215J has a 800 MhZ Marvell Armada 375 Dual Core CPU and 512 MB of
RAM. Currently the successor version of the DS215J, the DS216J, sells for around
163 Euros (May 2017)3. The NAS was installed on a home network connected to the
internet with a 51.4 MBit (Down)/10 MBit (Up) Deutsche Telekom connection, in
northern Germany. Tests were performed from southern Sweden with a 55.5 MBit
(Down)/47 MBit (up) Telecom 3 Sverige AB connection. Total air distance between
NAS and connected computer was 271 km and this part of the world is generally
known for having a good connection quality.</p>
      <p>The installation process was relatively easy. However, we decided against trying to
package the app properly for this initial test, as the purpose of the test was to see
whether the hardware limits of the NAS would be an issue for speed or connectivity.
Installing the application directly via the command line onto the Linux version
already running on the device also proved challenging, as header files for libraries,
etc. were missing. In the end we decided that the fastest way of arriving at our goal
was to install a Debian chroot environment for which there was a community-built
package available. The total package size of Fidus Writer was 235 MB at the time of
the test, and even though the chroot environment needed to be installed as well, space
was not an issue. The installation instructions provided with Fidus Writer4 are written
for Ubuntu 16.04, and these proved to be close to, but not the exact same as what was
needed for Debian Jessie. Most notably did we need to install a newer version of
Node.js than what the packaging system provided us with. We were then able to set
the system up, connecting it even with a MariaDB database provided by another
standard package on the NAS. The NAS was also able to reprogram the router to give
us access to the port we decided to run our application on from the outside. The entire
installation was done remotely without physical access to the NAS.
7</p>
    </sec>
    <sec id="sec-5">
      <title>Test results</title>
      <p>Our tests showed that at five clients could be connected to the NAS servers
simultaneously and read/write the same document without any noticeable anomalies.
We did not attempt to connect with more than five clients, as this number seemed
more than sufficient for our purposes. While there were a few situations where the
page would not load entirely the first time and it had to be reloaded, we attribute this
3
https://www.amazon.de/gp/offer-listing/B01BVDJGPE/ref=sr_1_1_olp?
ie=UTF8&amp;qid=1495437805&amp;sr=8-1&amp;condition=new
https://github.com/fiduswriter/fiduswriter/blob/3.1.0/README.md
to internet connection issues and not the NAS. The running of the combined
Tornado/Django server for that makes out the backend of Fidus Writer and which is
needed especially for the collaboration part, did not present a challenge to the NAS
server.</p>
      <p>Other parts of the editor – such as document export or import of citation sources in
the BibTeX format – ran smoothly as well, but this was less of a surprise for us as we
knew Fidus Writer had been programmed in client-heavy way, shifting most of the
computing processes onto the client (browser) and only doing what is the minimum
required on the server. Processes such as handling incoming document updates from
clients and exporting/importing files are therefore implemented as much as possible in
the browser and do not require server resources.
8</p>
    </sec>
    <sec id="sec-6">
      <title>Conclusion</title>
      <p>Academic document production continues to be challenging, especially when
dealing with confidential material and when wanting to write in a way that preserves
semantic information to avoid problems in the later stages of the publication process.
Running open source semantic editing software is challenging because not everyone
has access to their own server or can trust companies running such servers for them.
An installation of a semantic editing software on a NAS server seems in many cases
to be a viable alternative, as our tests running Fidus Writer on a Synology DS215J
showed. Client-heavy applications such as Fidus Writer are well-suited for the job, as
they will only require the minimal amount necessary from the NAS-servers and
perform all other calculations in the browser. Packaging Fidus Writer as an app for the
Synology system remains to be done before usability studies of the setup can
commence.</p>
      <p>This was our first investigation into the viability of a NAS-based solution. A survey
on what kinds of editors would be interested in such a solution is among the items we
are currently evaluating. The packaging of Fidus Writer as an app seems to be
timeconsuming and less of a technical challenge.
9</p>
    </sec>
    <sec id="sec-7">
      <title>Acknowledgement</title>
      <p>This work was funded by DFG, grant no. SU 647/19-1 and AU 340/9-1; the
OSCOSS project at GESIS and University Bonn [3]. We would also like to thank
other project participants and Fidus Writer participants who made the current version
of Fidus Writer possible. Among these are Mana Azamat, Niloofar Azizi, Daniel
Frebel, Babak Hashemi, Firas Kassawat, Takuto Kojima, Aleksandr Korovin, Fakhri
Momeni, and Anne Wittorf Kojima. Thanks also to Sarven Capadisli and Amy Guy
for their thorough reviews5 of an earlier version of this paper. Their comments have
led to valuable additions in the current version.
10
1.
2.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <string-name>
            <surname>Wilm</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Frebel</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>Real-world Challenges to Collaborative Text Creation</article-title>
          . In: 2nd International Workshop on (Document) Changes: Modeling, Detection, Storage and Visualization. p.
          <volume>8</volume>
          :
          <fpage>1</fpage>
          --
          <lpage>8</lpage>
          :
          <fpage>4</fpage>
          .
          <string-name>
            <surname>ACM</surname>
          </string-name>
          (
          <year>2015</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          http://dl.acm.org/citation.cfm?
          <source>id=2723154&amp;CFID=765669905&amp;CFTOKEN=75305975 .</source>
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <string-name>
            <surname>Afshin</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Johannes</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Philipp</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Christoph</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>Opening Scholarly Communication in Social Sciences by Connecting Collaborative Authoring to Peer Review</article-title>
          . Information - Wissenschaft &amp; Praxis.
          <volume>68</volume>
          ,
          <issue>163</issue>
          (
          <year>2017</year>
          ). preprint: https://arxiv.org/abs/1703.04428 .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <string-name>
            <surname>Mayr</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lange</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>The Opening Scholarly Communication in Social Sciences project OSCOSS</article-title>
          . Submitted. (
          <year>2017</year>
          ). preprint: http://arxiv.org/abs/1611.04760 .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <article-title>The open reviews of Sarven Capadisli and Amy Guy can be found</article-title>
          at https://www.fiduswriter.org/
          <year>2017</year>
          /05/24/decentralized-creation
          <article-title>-of-academicdocuments-using-a-network-attached-storage-nas-server/#comments .</article-title>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>