How Volunteer-driven Organisations Should Select Technology Solutions

Disclaimer: this is a record of comments posted on a thread elsewhere; comments have not been fact-checked.

Initial comment:

Why would you introduce complexity by custom building the site? Is there something stock Wordpress won't accomplish? Who takes over in the future? How?

Extended argument:

(Having read more comments outside this thread, I'll extend this argument slightly.)

First I will discuss the recommended Baseline for action. Then I will backtrack to list two extremes of Approach, some feasible Contingencies, and general Economic observations. Finally there is also a Tangential recommendation for the content/technology direction for the group.

BASELINE

So broadly, in any organisation, you can go between two extremes, in engineering/technology development, and this applies in selecting a website backend also.

Approach (A) provides a low-risk, low-cost, commonly understood approach to building and maintaining technology infrastructure for this organisation. Most costs of machinery over their lifetime come from maintenance, not initial acquisition. Given the voluntary nature of the business, resources cannot be assumed to be permanently available, nor can they be assumed to be in great abundance.

Should there be a demand for user experiences that cannot be met by approach (A), a discussion should follow beginning with the usability requirements for the system (UI/UX, business functionality), proceeding to discuss how the requirements can be achieved through various implementations, and finally only then choosing the implementation layer with consideration for all of the above.

APPROACHES

(A) Use lowest common denominator standard solutions like MediaWiki (what Wikipedia runs on, therefore what many people already know how to use), and WordPress (13 year history, broad ecosystem, literally an entire app-store of drag and drop plugin, which can be further customised).

(B) Reinvent the wheel. This is trivial if target functionality is trivial, like a static website. This is non-trivial if target functionality is non-trivial, like a CMS with access-controls, data validation, and modularised features. (Not going to even consider discussing a multiple-feature-non-modularised scenario, as that's a worst-practice. ;))

Right... so these are the approaches, what are the contingencies?

CONTINGENCIES

(1) The tech founder stays for eternity and maintains the chosen approach.

(2.1) A sequence of tech people runs the chosen approach, with appropriate handover, clear documentation, etc. between each epoch of staffing.

(2.2) A sequence of techies does not continue previous approaches perpetually, but instead starts from scratch with every new tech leader. Under approach (A), most of the workload of documentation has been done before you begin; the opposite is true with approach (B).

Given two broad approaches, and three broad contingencies above, we have a universe for discussion, and can start to ponder economics. Observations below are in no particular order.

ECONOMICS

(i) Event 2.2 is cheap only if your content base is small. Otherwise it is expensive. If your content base is large, opportunity costs can pile up as migrations are expensive. Discarding content instead of migrating it... well, that may or may not suck depending on how valuable the content is. How much content do we have? [Insert Tangent X]

(ii) Event 2.1 is predictable only if documentation is pristine. I don't mean kinda, sorta neat... I mean MECE-pristine. Otherwise costs will vary.

(iii) Costs discussed here are not financial costs, necessarily, but opportunity costs.

(iv) Decisions made now are betting the agility of the future team on current guesstimates about the availability of tech staffing to the organisation. Will there always be an excess of supply? Will it always be cheap? Will there always be few demands for their time? Between migrating systems, and building new features into an existing system, what's a better use of time?

TANGENT X

As far as I've seen (which is not much, as I'm usually not deeply involved in the organisation), there is a lot of content generated every year. However this all goes into a folder like Gdrive which is not published. I previously suggested moving some content to a crowd-editable platform, i.e. wiki. e.g. MediaWiki, as this would greatly flatten the workload of listing subject-specific how-tos and what-ifs for noob applicants.

(END)