The concern has played out in other arenas to various levels, from software vendors who lock their data formats or update paths (as the case at hand) to hardware vendors who lock their replacement components.
We can only hope that those who make the executive decisions to purchase and subsequently dump technologies on their employees may wake up soon enough to their commensurate need to lead a revolutionary shift away from those technologies that are abusive in their lock in practices. Such changes are not going to happen due to a groundswell of resentment from individuals.
The premise of your proposition is that skills to manage connections to a large vendor cloud service translate to manage connections to an in-house cloud service. I posit instead that, even when the protocols to do the latter are well-documented (as they already are for a significant number of foundational internal cloud services), the required management skills are not smoothly translatable from one case to the other.
Having a team that knows how to sustain Google cloud services well enough to keep everyone on-line and happy is not a viable argument to ignore the need to hire folks who know unix translation protocols well enough to keep everyone on-line and happy after the switch (and possibly let go of the Google team or retrain them appropriately).
And it is not that very little is known publicly about how to do it. It is that we have easily let the past knowledge base about how to do such things slip away to follow the siren call of shipping out such services to third parties.
Yes, the skills gap is real. IT Operations as a carreer has not been interesting for young pelople over the last 15 years. European businesses and governments are not only dependent on the US cloud providers, they (we) are also deeply dependent on managed service providers, mostly based in India. Even if we decided that paying European wages to our operations-teams was worth it, we couldnât find enough people with the right skill-sets.
Digital sovereignty is much more involved than just finding an alternative to Microsoft O365.
Yes, they can be compelled. They are also not allowed to disclose the fact that information has been shared to the affected customer. This is naturally quite an issue when dealing with governments and their intelligence agencies.
Yes, sadly the load-bearing Excel is much less valuable without Peter, who retired last month. Excel is a tool from the âpersonal computingâ age. Peter knows exactly how it works and nobody cared how he created his reports until it was too late.
Peter is now a consultant, invocing the equivialent of his previous monthly salary for two days work a month.
Strokes chin. Tilts head to one sideâŚâLooks like heâs done this with some completely unnecessary & showboating VBA. Anyway, Iâm sure youâll be able to work it for next weekâs report.â Oh those fun days with no Claude and no ChatGPT.
Many companies donât host their own tin anymore or (for example with M365 or Google Workspaces) their own domains, moving back to being solely responsible for these, even if in a virtual environment is a big step.
This happened with MS a few years ago and the US court sided with MS that the US Gov couldnât compel them to do this, there was then a Law change a few years ago under Trump 1.0 which now says that if the US Government orders them to, then they have to, even though itâs a separate legal entity.
My premise is exactly what you just said, i.e. I agree. Itâs not easy to translate from being higher up the stack managed an AWS environment, to coming down a layer even to the hypervisor and having to build your own services from scratch.
A very valid point, I hadnât even considered the cost differential
Or Peter doesnât care anymore because heâs retired. Be more Peter!
Itâs not only about the infrastructure. As far as Iâm aware of, there is not an existing technology stack that would be able to replace MS365 or Google Workspace providing not only the same document, spreadsheets and presentation capabilities but also the collaboration features. And with enterprise grade security, compliance and audit layer on top of that.
This is one of the reasons I enjoy articles from iA. They ask questions about technology in general and offer an argument. Many product developers add in âand hereâs how we will solve your problemâ. Which is really all those articles are all about, selling you something of theirs. iA hasnât done that, so I can read the article without any prejudice. There is no âgotchaâ.
There are many current topics without fully fledged, or even proposed, solutions (AI being one). This is an interesting time to be in where the future is a lot more open to a lot more people.
There has been a fascinating discussion on Hacker News this weekend that originated with the Ghostty terminal emulator, with its accompanying libraries (that other devs can use to make their own term apps):
One thread there that especially caught my eye brought up that in a time where AI/LLM is reshaping the entire world of technology, the subset (and almost prehistoric by computing standards) world of terminal programs are seeing a renaissance because many developers are using them to interact directly with LLMs and related activities. Little to no GUI, with either CLI or TUI presentations.
You never know what ancient approach will be resurrected in service of the ultramodern. The very idea of âofficeâ âprogramsâ may soon go the way of CD-ROM encyclopedias or other obsolete applications, while power users choose what retro interfaces they feel like using to chat with their coder.
I donât think an entire workforce really has to be trained to adopt plain text tools, as they already (functionally) use it all the time. Itâs called âemail.â The fact that the most popular email clients send HTML emails doesnât mean that the average user is using any amount of formatting. The most non-plaintext part of an email (at least the type sent by an office worker) is the corporate email footer that includes the companyâs logo and all the ridiculous boilerplate.
People use Word because theyâre HABITUATED to use Word. In their world, to borrow a line from Agile Tortoise, Word is âwhere text starts.â I have situations where Iâll ask somebody to email me a picture, and theyâll copy/paste the picture into a Word document. Which is counterproductive in so many ways, but thatâs what theyâve learned.
I would suggest that if you brought in a consultant to assess such things, the percentage of people who would suffer from losing Office on their computers would be rather small. Mapping the âWordâ icon to a fuller-featured Markdown/HTML editor would go a long way.
None of this diminishes the fact that Microsoft Office is a tremendous value for the money, for those who have a use for it. I was a volunteer director in a nonprofit for several years, and they used Word, Excel, etc. for all sorts of official documents. I hopped over to Microsoft and bought a personal license, happily. It helped me function for three years. And then I discontinued it after I left, because Iâm perfectly happy with the Apple apps for my business use.
Not really. Turn off HTML formatting. Turn off carriage returns. Stream the entire email directly in with no pretty UI features to offset who sent it, its subject, and so on. Refuse to accept anything but text, meaning no attachments and certainly no figures.
Basically, read a single string keyword-list that is semi-colon separated. Or a stream of markdown-formatted segments separated by semi-colons or \r or \t (to indicate the carriage return when the stream is to be formatted). Or an HTML document but with \r instead of the visual carriage returns.
That is plain text. No formatting. Zip. Nill. Nothing.
The fact that your email program already parses the plain text string it receives to give you UI segments indicating subject, sender, date, and so on cannot be ignored in making the analogy. And it therefore just does not work.
My experience is otherwise. Office, specifically MS Word, is a firmly embedded technology in industry, academia, and government for creating correspondence documents. You can just as well argue that we can bring in a consultant and thereby bet that only a small number of folks would suffer by being forced to switch from cars to bicycles for their daily lives.
No itâs not. The carriage return/line feed are perfectly-valid formatting characters, and the âfrom,â âto,â âsubject,â etc. message headers are perfectly-readable in any plain-text editor.
If youâre arguing that the underlying data stream doesnât soft-wrap message content, sure - but thatâs a trivial affordance offered by editors dating back to pretty much the beginning of computing. If something is perfectly-readable in an editor like Vim, itâs plain text by any reasonable definition.
And youâre taking my argument to a level that I wasnât. My argument isnât that email is 100% plain text. My argument is that the vast majority of emails arenât intentionally formatted by the user. They open a window, type what they want, and click âsend.â Thatâs plain text. And people do it all the time.
Are there institutional conventions? Sure. But whoâs driving the conventions? Why does a memo posted to a bulletin board need to be formatted in a fancy way on a company letterhead, but the same memo circulated via email can just be a paragraph of largely-unformatted text?
I really donât think the average office worker is driving the conventions.
I will grant in retrospect to exclude \r and \t from my comments.
Email applications each carry their own formatting tools, whether implicit or explicit.
The strictest analogy for a plain text editor is a pure vanilla notepad window with no tools, just four buttons: NEW | SAVE | CANCEL | QUIT. Anything else dealing with text as content that also allows you to change how that text is presented in the view window is a text-formatting tool.
We could split hairs on typeface (i.e. serif vs sans serif) and perhaps even monospaced vs kerning. But letâs not send any chemical formula or equations with powers, because those subscripts and subscripts are formatted characters that are not permitted.
I agree.
But, by my experience, a majority of office workers across industry, academia, and government will suffer rather terribly when a consultantâs recommendation that they must use plain text editors instead of MS Word is implemented as an edict.
Do not trivialize the workforce lethargy, reluctance, and outright rejection that will have to be overcome. It is this danger that feeds the sentiments of those who would make such consultant-fed edicts that âimplementing this change will not cost you anythingâ.
And then insist that those workers who are now burdened with only plain text editors should hold the same formatting quality demanded in a thesis or dissertation, EPA impact report, US Senate resolution, EU ISO XXX standard document, userâs manual for your new XYZ gadget, or other documents that have well-defined formatting demands for perfectly valid reasons.
And I agree about that. Sweeping edicts are usually ridiculous.
But removing the organizational requirements that cause some of the ridiculousness (and the stupidity that sometimes a message gets judged more by whether itâs formatted correctly than by actual content) would likely yield the result that many employees donât need the programs that provide the fancy formatting in the first place.
Going back to your nail gun analogy. What weâre doing now is giving everybody on the construction crew a fancy nail gun, whether it makes sense for their job or not, because we have a corporate policy that âa nail gun is the only valid way to insert a nail.â But somebody who needs to put in one nail a day doesnât need a fancy nail gun - they need a hammer. And given the setup time, battery maintenance requirements, etc., with the nail gun, over time encouraging them to just use a hammer likely saves both time and money.
That doesnât mean nobody gets a nail gun, and everybody goes back to using hammers. It means that we think rationally about peoplesâ jobs and the requirements thereof, from both their perspective and managementâs perspective, and make intelligent decisions that minimize waste of both time and money.
This discussion has come up before, or something similar.
People say they want plain text, but they donât normally want the end result as plain text. This means that most apps need to do some sort of conversion. Even markdown requires this conversion also.
I wonder if we underestimate the need of rich text? Everything from templates, company headed paper, headers and footers, reports, etc. Plaintext requires quite some conversion to produce this and often does a poor job.
There are many every day tasks where a plain text editor is out of its depth. I would never think of replacing Word with a plain text editor. I would lose way too many needed features.
We need some richness to our texts, absolutely. Depending on use case, we should choose the right tool for the job. This forum is a good example - we have Markdown support and that gives us ample room to make any post more expressive than using only plain text, while using only plain text characters. We also have the toolbar for those prefering that UI convention.
So yes - Iâd love to see people use more basic formatting. Look through your Teams/Slack/other IM service and I bet youâll find plenty of users who canât even be bothered to capitalize or use punctuation. These are not the same people who write while following ISO documentation standards.
Most of the regular office drones I have worked with over the years would have done just fine with a Wiki / Markdown-level feature-set. I rarely need anything more fancy myself.
Never underestimate the time and money it takes to make even minor changes.