Easy and problem free self-installing OJS software upgrades

[gail]

Describe the problem you would like to solve
OJS upgrades are too difficult and problematic to install for non techies who have insufficient time, skill or budget to resolve difficulties.

Describe the solution you’d like
Please develop more effective self install package from within OJS that can upgrade the version without difficulties seamlessly. Like Wordpress upgrades where you don’t notice upgrades have happened. Upgrading is not user friendly.

Who is asking for this feature?
Journal manager. Journals who are not techie, who do not have budget to pay people.

Additional information

A key point to remember is that many OJS journals have no or low budget, rely on volunteers or staff who are not trained in coding, php etc. They do really well learning how to use the OJS User Interface. But it’s no use having open access software that remains difficult and problematic to upgrade.

I have tried four times to upgrade from 3.3.0.7 and just end up restoring the site. I’m a determined person so it is disheartening and off-putting to experience failure. And please don’t suggest paying for hosting. That is not an answer. Open access software needs to be easier to upgrade without payment.

Thanks for all the care you take with this project.

[asmecher]

Hi @gail,

Don’t worry about the feature request format posted above – let’s work through the individual errors you encountered on your other thread and I’ll give a general perspective on upgrades.

The difficulty in upgrading is a general problem for our community, and it’s twofold:

1. The community tends not to have the tech resources required, and
2. The upgrades are not as easy as they should be.

We’ve talked about upgrades quite a bit during our last dev leads webinars; the next of those is on Feb 5th, 8am Pacific time, if you’re interested.

The first problem is unfortunately just the nature of the beast. Historically our community is grassroots,
which means little institutional support and a lot of personal initiative. We are seeing a lot more institutional uptake recently, which is great – the journals get better support through institutional IT, and it’s likelier that the institutions themselves can become contributors to the software; the latter is especially important is it magnifies the effective size of the development team. We are historically a small team, and have been lucky to gather a large user community, but this has made it a challenge to match the resources to the needs. The end result is that we have a lot more work than developers, and parts of the system – such as upgrades – have not gotten the polish they deserve.

But fundamentally OJS is self-hosted free/open source software, and it’ll require some IT skill to run. Some aspects of it will be harder than others, and unfortunately upgrades are one of the tougher aspects.

On to the second point: that upgrades can be hard to do. This has been a long-standing problem for us on the dev team as well, as it means that the community runs old software, and we often have to support years-old software (and identify years-old bugs). The more the community can stay up to date, the better it is for everyone, and difficult upgrades are an impediment.

This might run counter to your experience, but OJS 3.3 and 3.4 have received a lot of effort in cleaning up the upgrade process. The effects of this work will be more visible in future releases, once you’ve made that leap – future upgrades will be easier. OJS is mature software and a lot of upgrade challenges have to do with inconsistent data in the database that has accumulated over the years, and both 3.3 and 3.4 attempt to clean that up during upgrades, and add stricter rules so that future inconsistencies won’t be possible.

We’ve often talked about Wordpress as an example of software that can be kept up-to-date relatively painlessly, and we are moving in that direction. But one major difference between Wordpress and OJS: OJS is huge software by comparison. Wordpress can revamp its entire database in a very short time – it’s a dozen database tables or less – and OJS has over 100. So it’s a much larger task, both for the dev team and for the upgrade toolset.

Just a quick FYI – part of our work on upgrades has been to distinguish between Long-Term Support (LTS) releases and non-LTS releases. OJS 3.3 is an LTS release, but 3.4 is not. For groups without a lot of tech resources to draw on, it might be best to wait for the next LTS release and go straight there from 3.3. LTS releases are maintained for a window of 3-5 years.

Hope that helps at least to understand the challenges!

Thanks,
Alec Smecher
Public Knowledge Project Team

[gail]

Hallo @asmecher Alec,

It’s really kind of you to take the time to explain all this. I found it very helpful and no doubt others will too.

Yes, I’ll pick up on other matters in the other thread but if there isn’t a need to upgrade right now then we’ll wait for a later LTS release.

OJS is great. It’s a real gift to us all.

Thank you team.

Gail

[radjr]

Alec, thanks for the explanation. One of the issues with faster adoption of newer releases is the change in functionality and determining if a particular feature has been removed. For example, 2.4.x to 3.x lost subscription support and pay-per-view support. For the jump from 3.3.x to 3.4, we are all holding as our consultant said there are many broken plugins in the jump to 3.4. In the past, when I had my SW team release code, we sent it to our SQA team who produced a report of what worked and what did not and reconciled it with the development teams plans, which ultimately were driven by the sales and marketing team’s market requirements. So, if the PKP crew decides to drop functionality from one release to the other, they may want to see how many are actually running that feature. In our case, our marketing team would report that we have seen 92% of the customer base using a feature, or 15% are using the feature, and why they don’t use it more. So, I is there a way to create an automated report of the OJS installations and their use of particular features and plugs so that the Dev team can support the base better? This is really no different from the early linux movement and their transition to the Centos/Redhat/Ubantu/etc disties (and their move to paid support.) So, do you grow the organization to be able to provide more support and spend more time in development versus bug fixes, support, etc? This is the age old SW company question!

[asmecher]

Hi @radjr,

Because the software is free to download and install, and very global in its use, user research is not as simple as sending out a poll to registered users, and we don’t have a sales and marketing team. The SFU Scholarly Publishing Lab publishes research on scholarly communication, including OJS use; there is also a public dataset on OJS journals available at Dataverse. This dataset uses a very limited interaction with the software called the “beacon” – see the configuration file for an enable/disable. We are extremely cautious about introducing invasive reporting into OJS; this is a very sensitive subject with a long history in FOSS, and for good reason.

Subscription/payment features are a bit of a special case, as they are in direct tension with PKP’s purpose – to promote Open Access publishing. While we do have support for subscription-based access in the software, and will continue to, it’s never been a major area of development, and has not seen much usage in the community. (A look at contributions to the relevant source code or a search for relevant forum posts and Github issues will back this up as a proxy for survey results.)

Can you say a few more specific words about the broken plugins?

Regards,
Alec Smecher
Public Knowledge Project Team

[radjr]

Thanks Alec. While I get the tension, there are basic facts of life that production costs have to be covered and the subscription based model still covers those costs. Trust me, I would have retired if I stayed in computer engineering versus going back into publishing.

I have requested an update on the plugins they say do not work in 3.4.

Please expand on FOSS. Thank you sir!

[asmecher]

Hi @radjr,

FOSS is Free/Open Source Software.

Thanks,
Alec Smecher
Public Knowledge Project Team

[radjr]

Hi Alec,

Two thoughts, Maybe if there was some documentation on the subscription and pay-per-view modules that we could use to create a subgroup to develop this further. Open access is fine but someone has to pay for the copy editing, layout, production, hosting, overhead, healthcare, etc. OA simply shifts the cost to the authors. Supporting subscriptions allows existing journals to move towards OA. In the recent report of the OA promoters, only 26% had met the goals of full OA. The financial reality is that OA does not yet work as a business model. OA also incentivizes publishers (and predatory publishers) to publish virtually anything as the revenue line is dependent on it. It impugns the peer-review process (or unduly puts pressure on it) to move everything forward. Finally you mentioned you would like details on OJS 3.4 issues. Here is a link we follow and OJS3.4 does not show up. PKP Plugins List and here is a link to a similar discussion. Seeking Insights: Plugin Compatibility Issue in PKP Version 3.3.0.4

I guess I don’t have much to add to the discussion except my desire to maybe break out a development group to support subscriptions. We recently ran into a bug where subscription expiration notices where being sent even when the subscriber was current. We traced it down to this issue but I can’t determine if the fix has been added to the 3.3 build. > OJS 3 - subscribers are getting renewal reminders even though they have current subscription - #5 by rm_is_too_short

Thank you!

[asmecher]

Hi @radjr,

That’s a lot to discuss and beyond the topic of this thread; have a look e.g. at Recalibrating the scope of scholarly publishing: A modest step in a vast decolonization process. PKP has always been a promoter of Open Access, and the majority of our community publishes successfully that way without charging authors or readers. It’s only because of the success of Open Access that OJS has been able to grow and succeed – you could even say that the OA movement subsidizes subscription-based users of OJS. But I risk getting on a soapbox here.

I’d agree that breaking subscription issues out to another topic sounds like a good idea.

Regards,
Alec Smecher
Public Knowledge Project Team

[radjr]

This is great. I have good friends at MIT and many are on board with free education and open access. But when you ask them if they are willing to take a pay cut to support their ideals, they run for cover. So, while open access is a fine concept, someone has to pay for all the labor that goes into making the journal work. And those efforts are significant. Our goal is to publish content that is beneficial to our fields and we do it on razor-thin margins. Do we stop collecting money and have the journals go away? Are all journals to be attached to institutions of higher learning where they get paid by the government or by their students? Do we really want that totality given some of the recent scandals of local high profile universities and data manipulation? I think the market shows that the OA model does not work per my previous industry citation. It works if all the ancillary costs are “covered” by the institutions but it is not free. I think that a balance is required if we want to get the best articles possible into the hands of those who can use them to benefit humankind. Quality costs money and labor both of which are not free.

[gail]

Thanks @asmecher for that article. It’s great. Really tells an informed story about ethics and productivity in the world of open access journals.

@radjr I think of open access journals - well, most professional journals, as a labour of love, supporting the development and sharing of professional and academic knowledge. So I don’t think that many people do get paid for doing the work of journal administration and leadership. For a few it may be included in their paid academic employment but in this era of squeezing productivity out of employees, not many will be given time to lead or support a journal. Also tying a journal into an institution’s self-interested agenda can make for uncomfortable compromises.

For me the joy of OJS is independence. Freedom from compromising institutional deals, from wealthy publishing corporations who hide as much as they can (that we need) behind a paywall. Instead we have the freedom to experiment, to put out there knowledge and practices that mainstream institutions may feel threatened by, that unsettle established traditions. So the decolonising agenda really strikes a chord. And for the privilege of being part of the revolution, no-one is going to get paid. Giving time and swatting up on tech know-how, running writing workshops, reviewing, editing, proofreading plus, is the activism needed to feed our souls, our minds - and our communities - and make journals happen.

It’s a wonderful gift is OJS. We mostly need to get true satisfaction from outside of being an employee. There will be a few exceptions to this. But isn’t going to change the world through the handed out payslip. Revolution for social and scientific change will rely on other sources of income or input.

[radjr]

Lovely. That is why I am a 30 year Rotarian. But while I donate my time to feed, cloth and bring clean water, peace, literacy to people across the globe, we have to be able to pay the bills to do it.