First, as for pg(1) itself, I thought it came from one of the non-Research labs, like Holmdel or Indian Hill. I certainly remember using it on AT&T based system before System V arrived on the scene. It's possible, tjk had it from USG, but I think it's more likely I saw it from someone like Phil Karn. We also had pg(1) at Tek until I was introduced to more(1) probably originally from Jim Kleckner and the CAD folks [which worked better and pg(1) -- which means I probably brought pg(1) to Tek, unless it came from one the Purdue folks like Ward, I don't remember]. I also know pg(1) was available for PWB 3.0 at some point, as we had it at Masscomp before we got System V and we had it the AT&T 'universe' but I don't remember the provenance of that code (again I could have brought it with me, but I think it came to Masscomp via MIT). That said, Warren's PWB 3.0/SYS III source tree does not show binary or source, which makes the thought that it was AT&T based, but originated at a lab other than Summit or MH.
Daniel Halbert wrote to comp.society.folklore in 1994:
"I was a first-year graduate student at UC Berkeley in 1978. I had
been an undergraduate at MIT, and had used the ITS timesharing systems
there, which ran on PDP-10's. ITS put a "--MORE--" at the bottom of
the screen when one typed out files [..]
I believe that to be true.
Wikipedia says "more" was written by Daniel Halbert and expanded by Eric Shienbrood and Geoff Peck.
I also believe that is partially true and Mary Ann is actually correct in the provenance.
I think Eric arrived later than Dan (maybe a year later), but was also ex-MIT, and he too had used/seen --MORE-- on ITS as Dan had. But I was under the impression Eric started over. Then a few years after Eric, Geoff worked with Eric's sources to add a few features. As for starting over/hacking on the program from Dan's original code base, it's hard to call that one, as I recall that Dan's version was not much more than a hack on to cat(1). i.e. the original version was pretty simple, and I don't remember that it 'knew' about the type of terminal being used, get info from TERMCAP et al. [My intro to Dan's version was at Tek, BTW but was quickly replaced with Eric's TERMCAP version which I think I got from Mary Ann, but might have also been via the CAD connection - we in TekLabs had written all of the TERMCAP support for the Tek 4025 and family and I was working to get it all back into the UCB database, so we got a bunch of early PDP-11 based TERMCAP/curses code to help debug things since the 4025 supported some interesting modes].
To be fair, ITS and Dan certainly should get credit for introducing the idea of the terminal pager to UCB, but it really was Eric that created the more(1) program framework that took off and eventually did begat less(1), pg(1), p(1) and others. As for less(1) itself, the Gnu folks seem to have started with Geoff's version (which I think is the version in 4.2 BSD if you look at SCCS delta in Kurt's disks), with the biggest addition was for the user to be able to go backward and look at some of the text that had already scrolled off the page. But as pointed out elsewhere, after the Gnu folks had peed all over it; as Doug says, (and I suspect most of us agree) it really became a sort of lesson in featuritis.
But as discussed on many things in the historical computer world, more/less/pg/p often comes back to taste -> more(1) and p(1) were much more directed a doing one job well. As Larry says, there are features of less(1) which can be handy depending on your environment -- if you don't have a window manager/BLIT or today's user interfaces with unlimited scrolling (i.e. still on an ADM3A or VT-100), then many of the features of less(1) probably are considered a nice to have, you got used to them and it became your standard [burned in the ROMs in your fingers like csh(1) and vi(1) into my own]. But as Rob and Doug have pointed out, p(1) is more than sufficient and the 'extras' that programs like less(1) in a modern and clean environment start having doubtful long term value. Certainly, the 'cost' in complexity and 'code bloat' seems like a poor trade-off. But the assumption to me is that the desire for those type of features are fulfilled with different tools in the current world, but if you grew up with using them (say like Larry) I can see the value.
Clem