> When 'Software engineering' eventually becomes a true profession then these requirements will almost certainly be prerequisites for all practitioners.
This wouldn't work. Most software isn't life-and-death. That's a big difference from bridge engineering, nuclear engineering, and aeronautical engineering.
If you're hiring someone to do Python scripting, there's little point insisting they have a grounding in formal methods and critical-systems software development. You could hire a formal methods PhD for the job, but what's the point? The barrier-to-entry is low for software work. Overall this is probably a good thing. Perhaps more software should be regulated the way avionics software is, but this approach certainly can't be applied to all software work.
If your country insisted you become a chartered software engineer before you could even build a blog, your country would simply be removing itself from the global software-development marketplace.
> compare the biggest bloatware O/S program ever written, MS Windows, with that of tiny, fast and highly efficient Kolibrios OS
I broadly agree, but in defence of Windows, Kolibri is doing only a fraction of what Windows does. Does Kolibri even implement ASLR? One can build a bare-bones web-server in a few lines, but that doesn't put Apache out of a job.
> My own suggestion to up the standard of open software is a sort of halfway house where cooperatives of programmers would be paid reasonably acceptable remuneration for their contribution to these major open projects. In turn, there would be a small nominal free (say $5 to $20) levied on large scale open software programs such as GIMP
This doesn't work. It means a company can't adopt the software at scale without implementing licence-tracking, which is just the kind of hassle Free and Open Source software avoids. If I can't fork the software without payment or uncertainty, it's not Free even in the loosest possible sense.
The way things are currently is far from ideal, but we still have excellent Free and Open Source software like the Linux kernel and PostgreSQL.
> open software aficionados are usually doing it for the love of it—and that's a true strategic advantage.
Agree that this can be an advantage. Some FOSS projects are known for their focus on technical excellence. That said, the same can be said of some commercial software companies, like iD Software.
> One thing is for certain, we urgently need to raise the standard of software generally and it seems highly unlikely that we can do so with the way the industry is currently structured.
Software firms today are doing a good job of making money. If the market rewards regressions in UI design, and using 50x the memory you really need (thanks Electron), what good would it do to regulate things?
Apparently most people don't care about bloat, and they prefer a pretty UI over a good one. That doesn't strike me as the sort of thing you can tackle with regulation.
This wouldn't work. Most software isn't life-and-death. That's a big difference from bridge engineering, nuclear engineering, and aeronautical engineering.
If you're hiring someone to do Python scripting, there's little point insisting they have a grounding in formal methods and critical-systems software development. You could hire a formal methods PhD for the job, but what's the point? The barrier-to-entry is low for software work. Overall this is probably a good thing. Perhaps more software should be regulated the way avionics software is, but this approach certainly can't be applied to all software work.
If your country insisted you become a chartered software engineer before you could even build a blog, your country would simply be removing itself from the global software-development marketplace.
> compare the biggest bloatware O/S program ever written, MS Windows, with that of tiny, fast and highly efficient Kolibrios OS
I broadly agree, but in defence of Windows, Kolibri is doing only a fraction of what Windows does. Does Kolibri even implement ASLR? One can build a bare-bones web-server in a few lines, but that doesn't put Apache out of a job.
> My own suggestion to up the standard of open software is a sort of halfway house where cooperatives of programmers would be paid reasonably acceptable remuneration for their contribution to these major open projects. In turn, there would be a small nominal free (say $5 to $20) levied on large scale open software programs such as GIMP
This doesn't work. It means a company can't adopt the software at scale without implementing licence-tracking, which is just the kind of hassle Free and Open Source software avoids. If I can't fork the software without payment or uncertainty, it's not Free even in the loosest possible sense.
The way things are currently is far from ideal, but we still have excellent Free and Open Source software like the Linux kernel and PostgreSQL.
> open software aficionados are usually doing it for the love of it—and that's a true strategic advantage.
Agree that this can be an advantage. Some FOSS projects are known for their focus on technical excellence. That said, the same can be said of some commercial software companies, like iD Software.
> One thing is for certain, we urgently need to raise the standard of software generally and it seems highly unlikely that we can do so with the way the industry is currently structured.
Software firms today are doing a good job of making money. If the market rewards regressions in UI design, and using 50x the memory you really need (thanks Electron), what good would it do to regulate things?
Apparently most people don't care about bloat, and they prefer a pretty UI over a good one. That doesn't strike me as the sort of thing you can tackle with regulation.