really I should just make a GD blogpost about this...and I will but also I am doing laundry and am exhausted.

#LPF24 #PKPSprint

I will say, and I'm sure this will come up at #LPF24 tomorrow and Thursday:

for all we talk about "open infrastructure," many libraries are adopting tools/platforms that on the technical side are over-engineered, require substantial computing power, and often, considerable attention from people with technical expertise.

To say nothing of the fact that to load a single page, you are asking your users (who aren't using the latest MacBook Pros on 1+ gbit connections like many developers or first-world librarians, especially in the US/Canada) to load tons of webfonts and JavaScript, asking them to do all sorts of stuff in order to access an ostensibly open textbook.

The result of the first part is that our 'open' infrastructure becomes highly centralized, we surrender privacy protections that we (hopefully!!) have for things we host/manage ourselves, and we risk locking ourselves into a vendor/client relationship. Just like with Elsevier/Springer/et al. And lol, what happens in 5-6 years when you can't afford whatever they're charging? Or when the company that you pay for hosting realizes that maintaining this complicated code monster isn't worth the effort?

The result of the second part is that we make it actively harder for people who aren't at ARL Libraries, who don't have lots of resources, who have a hard time accessing sites because the only internet connection outside of campus is their phone?

Compare this to something like @PublicKnowledgeProject's Open Journal System which is a drastically simpler application based on 20+ year old technology that is rock solid.* That is easy to maintain. That is easy to understand. That is secure. Serving pages that are lightweight and easily accessible.

Not based on the popular programming language of the week. Not based on whatever the latest trend is.

Built on technology that very simply: JUST WORKS.

...and yes, we can make it have a slide carousel on the front page.

*technical: it's a (BSD/Linux/Mac/Windows)/Apache/MariaDB/PHP stack

#PKPSprint #LPF24 #C4L24

also as I just noted IRL:

THANK YOU to the @PublicKnowledgeProject folks for developing platforms and software that aren't, for lack of a better and more succinct expression, a roaring tire fire.

imagine that.

#LPF24 #PKPSprint

All I'm saying is don't reinvent the wheel every other week and don't over-complicate things.

PLEASE I am begging you people.

#LPF24 #PKPSprint

Specifically thinking of systems that I have openly criticized before, including one developed/funded by a different unit at my own university which I actively disdain.*

5 MB pages for...text....because you're loading in 20 webfonts from multiple CDNs. Using 2-3 GB of RAM on a brand new VPS and a brand new install because you've got an enormous Rails application doing nothing but sitting there with no users or publications. That's not kosher. Don't abuse users like that. Especially students from disadvantaged backgrounds or people with lower-bandwidth internet connections.

see also: node apps that do the same thing.
see also: rust web assembly apps that do the same thing

what if instead we use lightweight, easy to use, and accessible applications driven by cross-platform Apache/PHP/MariaDB/etc.??

Not shiny. Not sexy. It just works. and works well, tbqh.

*manifold. it's manifold.

#LPF24 #PKPSprint

today (now that I'm in the pre-conf after some administrative stuff): talking about @PublicKnowledgeProject's role in the #OpenPublishing #ScholComm #OpenAccess ecosystem (hint: it's really gd important) (2nd hint: and immensely better than the alternative)

#PKPSprint #LPF24