Review of "Open Knowledge Institutions" by Daniel S. Katz

Updated Mar 26, 2019 (1 Older Version)chevron-down
0 Discussions (#public)
1 Contributor
Review of "Open Knowledge Institutions" by Daniel S. Katz

This is one of a set of solicited reviews of the work in progress, Open Knowledge Institutions. This review was written by Daniel S. Katz of the University of Illinois Urbana-Champaign. If you have an interest in submitting a review in this form then please get in touch with the authors. Alternately feel free to comment directly on the book itself on this site.

I recently read the book Open Knowledge Institutions: Reinventing Universities by Montgomery et al. after having previously skimmed a section of it. Overall, I enjoyed reading it, and the diverse perspectives of the authors helped me think about some of the issues of where universities are and why, and where they could go, differently than I had before. Some parts of the book, in particular Table 1 and Section 9.4 seem to be very powerful concepts.

However, based on my past work and experiences, I also see some gaps and some things I disagree with. In particular, my background in software and open source, my work leading a recent workshop on the future of universities, and my thinking about how open scholarship works inside academia and in the wider environment influence my opinions.

My views and opinions that differ from those of the book authors follow, though note that these are just my views, and they generally don't mean that the authors are incorrect, just that there may be other things that also should be considered.

1 - The book talks a lot about knowledge, and the sharing of it, but exactly what this means isn't clear. The meaning of data is clear, as is sharing of data. The idea of layers, with data on the bottom, information in the middle, and knowledge near the top (N. L. Henry, 1974), might be worth considering. How each type is represented and potentially shared differs. In addition, in many cases models are important, fitting somewhere near information and knowledge, but models are not really mentioned in this book. For example, in Section 5.2, where are software, methods, and models? And in Section 6.2, the open knowledge that is being published seems to be in the form of papers (text).

Software, which is not just data, is also somewhat under-discussed. Models and information or knowledge can be expressed in software, and sometimes, this is more precise than when they are expressed in text. Overall, what do the authors want to be shared? And how do they expect it to be expressed?

Thinking about software a bit more, is academic software different than general software? While research software probably isn’t, general software perhaps is. Universities are part of the general software development community but don't lead it. In the context of knowledge sharing, it would be useful to think about what is unique for universities in software? Where should they lead? Collaborate/contribute? Follow?

2 - What is the role of the public in contributing to knowledge? Are they just a supplier of data? Can they also ask research questions? Or contribute to generating knowledge? Perhaps by suggesting models? Or is are some of these unique activities that only disciplinary experts can perform? Overall, who transforms data into knowledge and how?

3 - I have some differing views on common pool resources from my reading of Ostrom. Quoting from Wikipedia quoting Ostrom: "A common-pool resource typically consists of a core resource (e.g. water or fish), which defines the stock variable, while providing a limited quantity of extractable fringe units, which defines the flow variable. While the core resource is to be protected or nurtured in order to allow for its continuous exploitation, the fringe units can be harvested or consumed." Given this, how is knowledge a stock variable? What is the flow variable? What does harvesting/extracting knowledge mean? How is knowledge replenished?

I also am unsure about the suggestion that common pool resources are difficult to create. I think, rather, they are difficult to maintain.

4 - Open source communities would be good to bring into this discussion. While open source is a licensing model, open source communities add social aspects to software, including governance and culture. The book's discussion of the poise zone, dynamically placed between too closed and too open, has a number of parallels to open source communities. Raymond's The Cathedral and the Bazaar posited these two models for open source communities, which can be viewed as the extremes of closed and open. Modern well-governed open source communities fall in between, similar to the dynamic poise zone. They are encouraged and guided by their leaders and often, a community manager. Is there an equivalent of a community manager in OKIs? In addition, many successful distributed open source communities have moved to a model of no closed discussion, since due to time zones and other factors, everything needs to be public and available for the community to be able to fully engage in decision making, without which the community may dissolve. Some other related topics that come up in the book are:

  • The relationship between subsidiarity and open source community governance (Section 5.1).

  • The relationship between policy and governance, and with trust (Section 8.1). Is policy always top-down and governance always bottom-up (Section 8.3)? Can the community set and enforce policy?

5 - The open source world is more generally more collaborative than adversarial (cf. Section 2.3). For example, the reviewing in the Journal of Open Source Software (JOSS) is not anonymous; not mediated by an editor but rather a direct conversation between the reviewers, authors, and editors; and not adversarial, as the goal of the process is to improve the submission, not to judge and potentially reject it. Could this model be used in OKIs? Or is open source fundamentally different from academia?

6 - The discussion about open vs closed, for example in Section 3.3 is a bit muddled. It seems to say that open is always good, and closed is always bad, and that these are moral definitions. But I think they are context-dependent. If we think about safety and security, open can be bad. For example, I don't want the doors of my house to always be open, not should a bank's doors and vault always be open. Here, closed may be the default, both practically and morally, given that sharing is not the goal.

I'm also unsure that open is always better in a changing world. I wonder if this is more true in an improving world, where closed might be better in a worsening world? This also makes me wonder if openness is sign of optimism, and closedness is sign of pessimism.

In this section, I generally disagree with the definitions of CKS. For example, I am unsure that CKS are as top-down as described. I think a CKS could be club/community defined. And why can't there be responses to reviewers in a CKS? And in Section 10.1, why will systems always evolve to naturally closed state?

7 - I disagree with some of the ideas about the modern research university in Section 4.1. In particular, I wonder if there is a difference between public and private universities, particularly non-sectarian private universities in the US. I also would like to see some evidence for "In response to these pressures, as well as to increased scrutiny and accountability measures, the modern university is driven to become an increasingly closed institution, which allows it to operate more efficiently to meet short-term goals set by funders, regulators and the market," as this doesn't match my US experience.

Rather than freeing academics from publish or perish, perhaps we should generalize this to contribute or perish.

Thinking about how universities change (Section 5.3), the thinking of Martin Paul Eve in terms of how gradual change can occur in humanities publishing might be a useful concept. Additionally, my experience with the support of central computing in universities has been that leaders of high-prestige institutions don't have many incentives to change, while leaders of universities in the next lower tier are actively looking for ways to improve. On the other hand, the support of Research Software Engineers (RSEs) started more in the top universities, in my opinion.

8 - In our recent workshop on the future of universities, we categorized six topics of interest: credit and attribution; open scholarship communities; outreach and engagement with the public; education; preservation and reproducibility; and technologies. It's interesting that these only partially overlap with the topics in this book. One example is that there's little overlap with Figure 3. In addition, we determined a set of 22 principles, which when I compare with the list of items in Section 10.3, I again see few overlaps.

9 - Some minor points:

  • In Section 5.4, is the relative failure of NSF's public access plan vs. NIH's caused by lack of coordination, or perhaps rather by lack of enforcement?

  • In the same section, it might be useful to differentiate between platform ownership and platform governance. Some researchers seem to find the governance of the platform more important than its ownership.

  • In Section 6.2, publishing is not just the act of making something public - that’s publicizing. Publishing also includes curation, perhaps gatekeeping, judging, (mediating), identifying, collecting and storing metadata, etc.

  • The concept of Blockchain seems to be overemphasized in this book. Given that it's currently at the Peak of Inflated Expectations (or perhaps just past it), it's currently very unclear what its end utility will be in academia. I don't think that all of research is the nail that blockchain will hammer.

Roles: Writing – Review & Editing, Writing – Original Draft Preparation, Conceptualization



No Discussions Yet