For a moment there, Lotus Notes appeared to do everything a company needed
theregister.com
theregister.com
After a year of hacking, learning from mistakes, and countless hours of RTFM, we got it done. Email, calendar, file shares all migrated, cross-site replication, and some really great new features added in with workflows. I was really proud of it.
As soon as the last migration wave was complete, I called my manager to let him know that the long-awaited day had arrived. Exchange was dead, long live Lotus Notes! Literally, during that phone call he said "Ummm. Yeah. We are going to migrate back to Exchange because of some M&A coming up."
I was not pleased.
As mentioned in the article, this was a time when apps were built native to the OS, and deployment and updates were a full time job for the IT department. Notes encapsulated all these apps in a single app launcher in a standard way they could be deployed and managed.
The best comparison today is not Outlook/Exchange, but the whole Web itself which addressed the same problem of apps in a more universal way. However Notes enabled this at least a decade before the Web was advanced enough to handle this.
Data had bidirectional replication with the server. Apps ran from local NoSQL databases on your machine which you synced it up with the server including the App code. The Web runs apps on servers, Notes not so much.
A much part of the web uses a local in-browser db and syncs it up with a database on the server.
It took me very little time to develop and really revolutionized our team's ability to manage the incoming flow of tickets for our nearly 1000 users.
We soon gave access to the system to delegated principals in each of the departments who were then able to coordinate their department's tickets in real-time too. They loved it.
One day we got a mail sent to everyone at the company from the CEO, with some rather lewd content. As you can imagine it caused quite the stir.
As most here will know, SMTP by default doesn't verify sender. And the Domino mail gateway would happily match external addresses to internal accounts. The result was that it looked quite legit.
Turned out someone who was fed up with their job[1] had used this to appear to be the CEO, we have a 3 month notice period here in Norway, and well he got let go immediately...
Young me learned a lot about how mail worked thanks to that.
Certainly but I'd say the most important ancient software is just a few years younger: the IRS Master Files. https://www.governmentattic.org/5docs/IRS-HistoricalFactBook...
> FEBRUARY 1962 The first master file, the Business Master File, was established at the National Computer Center
Individual Master File operations began a few years later. Let that sink in: every tax transaction a company or an individual makes in the United States is handled by a piece of software written for the IBM 7074. These were using a CPU of about 27 000 instructions per second and had 9900 words of core memory. It's hard to paint a picture of just how old we are talking about. While the Beatles already existed at the time, the Beatlemania is still a phenomena for the future. This https://i.imgur.com/dtmPy3a.jpg is a luxury car from that year.
Because the IBM 7074 is so old, it predates the 8 bit byte length.
Dreaming in Code tells the story of the development of Chandler, an open source, cross-platform “personal information manager.” This software was the brainchild of Mitch Kapor (of Lotus 1-2-3 fame, and the founder of a short-lived non-profit called the Open Source Applications Foundation. While the OSAF was well-funded (to the tune of millions), and while Chandler was eventually built, it was marked by blown deadlines and cost overruns. And the project is now moribund.
In other words, as Rosenberg wryly notes, Chandler is another in a long line of failed software projects. Unlike building bridges, he notes, software engineering is hard.
When Trac came out, it did everything confluence, jira, and bitbucket do, in one open source, easy to use tool that had tons of community-developed plugins.
The thing is, though, that it wasn't meant to be administered. It didn't lend itself to management. It was meant to be deployed, and then not managed, which is _fine_ if you have one or two of them, because they're pets, but in a world of cattle, you can't have 100+ special snowflake systems deployed like that.
I spent years mowing down every Trac instance I could find, migrating them to the actually-centrally-managed Atlassian stack. After I left that team, I would incentivize other people to carry on in my footsteps by buying a bundt cake for anyone who led the charge to remove a Trac instance from the infrastructure.
I gave away a lot of bundt cakes, but the infrastructure was better and more reliable because of it.
I guess Notion would be today's modern equivalent, will turn into tomorrow's legacy system.
I sometimes wonder if people have done any research on these types of workflow abstractions and come up with fundamental data structures to work with them.
That's what my company does.
Edit: this was in 2013.
Strangely, as CPUs/PCs got faster, it seemed to get slower. By the time 2000 rolled around it would take SO LONG for a notes square/app to open.
It was an interesting piece of software. Nothing has really replicated it. I'm kind of shocked it hasn't been dumped on the open source market and then rebuilt from the ground up.
Otherwise it was 30 years ago, so I don't remember at all what was being done. But LN didn't really have a good query language. Sure it's all fun and wizards inside Lotus Notes itself, but one of the failings was that in the database part it wasn't really a database for anything but Lotus Notes.
I believe at the time there was the beginnings of an ODBC interface to it, but it was buggy or insufficient for whatever reason.
So LN wasn't good at sharing information, just like every office product really isn't good at it. Fine for people using UIs and Wizards. I mean, it is a TRAVESTY of possibly billions of dollars or more of wasted money that spreadsheet products and formats aren't trivially readable to get access to the data within them, but that is a rant for another day.
Anyway, so if you wanted to integrate with LN data between rando-system, it was obtuse APIs. A "good" API makes connecting and data marshalling/representation/access pretty easy, along with search/index, etc.
I believe there was locking annoyances that occurred as well when the API was in use. I'm not sure LN was built for multi-user all that well, but again I don't recall the technical limitations. I think a LN database was a single file, so if you're doing API-level mucking with the data, you had to lock it from the LN application/server from doing anything.
All I remember is that Lotus Notes was "meh" on that front. Domino may have improved things, but by then I had moved my C skills to something else.
Needless to say, we hated the client interface and the exchange interchange was wonky - the feedback was extremely negative - "it is a pile of shit" was common and it was canned.
It was super rock solid and reliable. even when you abused it by filling the disk space!
The client was god awful.
Not bad before for a platform before we entered the world of Oauth and SaaS services.
Sounds like Workday but less complicated (because Workday also does payroll, and payroll sucks)
None of the groups I was in ever used it, so I never saw how it was used in the wild unfortunately
Computer associates used to be the graveyard of dead software.. Guess they're dead too.
Writing a Notes app and getting manager approval could be a lot of hassle, so it was often far simpler to open a text editor, write some HTML, and share the local network path with fellow workers. In those days Windows machine on an intranet could have a dedicated URL, using a system called "WINS" I think
I think that writing static HTML websites then acted as the "gateway drug" to dynamic webapps further down the line.
Where there is a (global?) standard of data access - like
For emp in biz.hr.employees.current: print emp.401K.contribution
I mean something like this exists for SAP (probably), but I imagine there is some FOSS version waiting out there that is the POSIX of organisational APIsHow it’s implemented is almost irrelevant. But it’s existence means management become software literate, means that companies won’t waste half their software devs doing things like reinventing ETL tools
It just seems a good idea
https://en.wikipedia.org/wiki/Chandler_(software)
.