I fully agree concerning an engineering background.
However, any good practitioner (with, like Heaviside, credentials
equivalent to both academic intellectual education and practical field
experience, irrespective of formal diplomata -- today, the diploma seems
the most important and a Heaviside probably would be impossible) should
have the requisite software engineering techniques and skills. My
concerns are two-fold -- lack of such techniques and skills, and lack of
sufficient work-fraction to do the work (e.g., for which the work is not
gainful employment). For some things, such as say, Calibre or
TexStudio, it is less of a concern that these applications
professionally are constructed or maintained (these actually are);
however, systems software are of such a concern, including both
reliability as well as "hardening" against compromise.
On 12/31/20 8:02 AM, Lamar Owen wrote:
On 12/31/20 12:05 AM, Yasha Karant wrote:
... It is difficult, but not impossible, to have a distro that does
not have computer science and engineering professionals ... doing the
implementation that is suitable for "hardened" production use,
including converting a distribution source into a functioning
alternately badged but otherwise identical "executable" distribution.
In my opinion and for software that I will approve for use at $dayjob,
developers doing "professional" release engineering and management for
any software really should have solid software engineering backgrounds,
not just computer science backgrounds. Since I do this sort of
evaluation on a professional basis, I am using the ACM's definitions of
those fields as defined in "Computing Curricula 2005: The Overview
Report" as well as the individual, updated, curricula as found on the
ACM's page at
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.acm.org_education_curricula-2Drecommendations&d=DwIFAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=J_y_RQ_m1wBDNa6puHIKs0qD-PVYaEuxw9yvER0cVXo&s=9h8AR-p_2yNK1ZunKeU1c78tSEzoHsVXrIyUejk4EVc&e=
. I do this sort of research for any high-value software, whether
commercial or not, especially if there is a budget line item associated
with it or if it is core infrastructure such as the primary server OS to
run.
One reason I was so very comfortable with CentOS is that I've done my
homework on the developers' professional backgrounds, which passed
muster for my purposes; I was equally comfortable with Scientific Linux
even before it was called that, but the larger base behind CentOS made
the decision for me between those two, which I annually reviewed. It
helps a great deal that I've been acquainted with many of these folks
(both CentOS and SL) for over 20 years, and have seen their track
records. And track records trump degrees and titles for my purposes.
Track records makes it all the more difficult for me to choose a CentOS
Linux replacement today; even just counting the RHEL rebuilds, there is
quite a bit of choice, between Oracle, Springdale, CloudLinux Project
Lenix, Rocky, and even CentOS Stream. The evaluation rubric is much
larger now than it was when PUIAS, WhiteBox, and CentOS started.
In my over fifteen years experience here, primarily with CS interns, I
have found that much of the time a computer science background alone is
not enough; proper release engineering and management requires
sub-disciplines that aren't necessarily found in the typical CS
curriculum (learning such out-of-major disciplines is one goal of a good
internship, in my opinion; the discipline of effectively and
consistently using things like source code revision control, for
instance). Now, information systems or information technology
backgrounds (again, using the ACM's definitions) can be highly useful
toa project, mostly for process management and business alignment (on
the IS side) or infrastructure management (on the IT side), but the core
discipline needed for release management is SE.
My observation about the paywall was simply that public archived
discussions are needed to trace back both proper attribution (even if
not for-fee property) as well as to verify the current state of any
particular implementation.
In my opinion, requiring a login of any kind to access archives means
the discussion isn't public by definition, even if anyone can join; many
mailing lists even have a 'members-only' archive policy. I too have a
bit of a problem with certain communications channels that seem to be
very popular these days, but at the same time, in open source projects
at least, the people who do the work should be able to choose the tools
they use to do that work. But, one of the side effects of this
Instagram/SnapChat/Discord/Tiktok world is that the value of archives
seems to not be fully appreciated (I won't elaborate here on how well I
know this in terms of astronomy in general and radio astronomy in
particular).
--
They say hindsight is 20/20;
I'm looking forward to 2020 becoming hindsight.
