We talk of digital simplicity without necessarily giving it a proper shape. Nor is there one definitive shape: the notion is subject to individual behavioral and thought patterns.
Me, I’m magnetized towards free and open-source for not only the design transparency, but the prospect of being in control over the underlying data and infrastructure hosting the solution. I’d love to make the claim towards this being the universally better solution for those seeking simplicity.
But at the end of the day, once we begin to establish the business case, draw out its requirements and imagine what simplicity might mean to us, we quickly unravel a web of paradoxes and dilemmas.
Simplicity at one level of abstraction can mean complexity at another. Simplicity today can mean complexity in three months time. Simple to another might appear plain complex to me. And each of those complexity gradients could map to something operational, psychological or financial.
I’m of the conviction that whatever component can remain mostly offline, or at least communicate with the cloud asynchronously, and without major compromise to the workflow, has the prerogative to do so, immediately reducing a series of privacy and security considerations inherent to the Cloud, while gaining the assurance that your business operation does not depend on that of your commercial provider.
Open-source solutions are frequent facilitators of that autonomy. Their code, even if neglected or abandoned by the active maintainer, remains accessible, pliable and modifiable by whoever cares.
The single-user workflows naturally cater to this offline-heavy paradigm - calendaring, (local) content management, email, web development - involving mainly yourself and necessitating merely ad-hoc synchronization with the web.
There’s no need for SaaS when you’re the sole user. And be that not the case, it’s still possible to architect your multi-user workflow for a mainly offline, cloud-asynchronous interaction, though it might require a touch of imagination. Just recently I’ve been conceiving how multi-user project management could get away without a cloud platform in favour of just an offline and synchronized todo.txt, given a user-aware protocol and clever task structure.
Again, crucial operations such as backup and synchronization are not the sole proprietorship of Cloud platforms. They can be managed externally to the otherwise offline application via ubiquitous, Unix-based tools such as rsync, scp, (plain) cp, Git; or their third-party equivalents for those uncomfortable with the command-line. That is, provided your data is primarily plain text, or effectively reduces to plain text.
Obviously I’m not speaking of binary graphics, visual models or proprietary databases. But calendaring, project and content management, web development, light wiki/documentation - a heavy portion of these workflows and their plain-text predominance caters to the offline and cloud-asynchronous methodology.
What about the more complex workflows in the worlds of CMS/CRM, payment processing, team chat/communication, the heavily adaptive project management, or an E-Commerce store?
Many of the above applications call for a cloud-based solution for a stakeholder pool expanding anything beyond a confined space (or a closed network). Hence corporations facing privacy concerns might deploy not an internet-wide Cloud solution, but a firewalled, intra-LAN cloud.
But network requirements aside, all of the above cases offer a range of both commercial/closed/data-opaque solutions, as well as open-source/open-data solutions of both free and paid price tiers depending on your organizational needs.
I recently examined the price-tiered models of numerous PM/CMS solutions on opensource.com. Many provide a cloud hosted option at the developer’s data center. Alternatively, the free-tiered Open-Source plans provide and usually demand that you self-host your solution. Unsurprising, as why would the solution provider, already not profiting from you using the software, absorb the operational costs? Then again, they might do so in hopes of later, postponed monetization.
To reduce all the above to a principle, and before this risks turning into a white paper: free and open source generally requires the greater initial time investment. Paid and open-source requires less, as you’re effectively gaining a certain level of service. Closed requires the least initial time investment since the whole infrastructure is externally managed.
The time investment I refer to is the platform maintenance, configuration, upgrades and the such; not so much the business side, this always being the common denominator across the categories.
For a FOSS solution that may involve setting up a VPS server (if one isn’t already at your disposal), installing/configuring the prerequisites (ie web server, database engine, dynamic web framework, modules), installing the actual app, hand-tuning a series of configurations, setting up automations, familiarizing yourself with documentation.
Alternatively, many of the heavier Open Source solutions enable a Docker container to automate an otherwise complex installation (again, this follows my recent opensource.com audit). Thus depending on how much of the infrastructure you already have in place and your experience handling it, it may or may not amount to all that much.
But how often, considering the need for that payment processing solution, E-Commerce store, communication platform, mailing list provider, even if the project quickly became shelved - have I found myself rather docile on the one side, lazy on the other, unwilling to dirty my hands, all the while caught by the industry-standard, commercial, quick deployment prospect, ready to accept the 30-day free trial followed by a modest $10-20/month subscription (accounting for the 20% yearly discount)?
It’s not like that monthly fee risks breaking our budget?
Though it might, as such decisions foster similar decisions, one after the next, which turn into habits, which become principles. Part of the FOSS ecosystem not long back, that same end-user/developer/manager/___ now rolls out commercial, cloud-based, monthly-subscription oriented solutions for every whim justifiable by no shortage of business analysis.
It really is that simple. Subscribe, configure, integrate, and you’re rolling in a matter of hours. With maybe an AI assistant. No disparate components. No external scripts. No platform customization for peculiar pipelines.
That’s more or less the recurring ping-pong match between two angels hovering over me, angels of no particularly good or bad makeup or any easily identifiable insignia lending to satirical portrayal.
The two opposing paradigms remind me of the contrast between a manual transmission and (all the way across the gradient) a Tesla. There will always be users highly preferring one of those two camps. Each derives a vastly different connotation in the notion of simplicity.
Insofar as I understand myself, I’d sooner rummage through heaps of metal and silicon, however hopeless or haphazard, than interact with an opaque, semi-intelligent automata. To me, the latter represents a costly abstraction, of a cost not entirely conceptualized and postponed like a recklessly amortized, high-interest mortgage whose compounding nature screams red alert. To accept those terms enough is to eventually rely on the all-in-one, the semi-automated, the semi-assisted.
But for whom it’s strictly business, deadlines, streamlines, assembly lines and all manners of fine lines, such considerations don’t surface.
Those are the opposing extremes, though fortune has bridged them - bridged the opposite sorts of simplicities via a gradient. Just like the gradient connecting the predictive and adaptive project management methodologies (the Hybrid). Neither case is mutually exclusive: both enable you to adapt to a varying combination.
Of the two, the first scenario (the entirely metaphorical metal and silicon, as I’m not actually as crafty with physical components), in whose clutches I’ve found myself overwhelmed throughout life, at least offers the solace of not having shied away from mechanical complexity, gotten my hands dirty and accumulated some resilience towards what, I become increasingly less clear, but never mind that.
Ultimately, I’ve flirted with both thought factions. I’ve tried to relate to the problem in terms of deploy what you need as quickly as you need. And even if liable to follow that stratagem in my collaborative engagements or in my anxiety to deploy and incur whatever long-term upheaval - in heart, though a hybrid, I still lean heavily towards the do-it-yourself and maintain-it-yourself manner of handling or mishandling.