Hi Jody,
Thanks for sharing, interesting article.
For a "Discussion" mailing list, there's usually not much discussion on
it, so here's my contribution:
> 1. A coherent vision requires centralized design
Seems like a tautology. Not to mention there are countless Open Source
projects that have a coherent vision, even larger ones (a lot of Linux
distros for example).
> 2. High-level languages need more design than low-level languages
> The core team for open-source language design is usually very small
... Higher-level concepts are then delegated to the competing developers
of libraries, who design independently of each other or the core
language team.
Maybe, but it can work well for Open Source languages too. Python is a
prime example - countless libraries in all manner of fields created by
innumerable developers, most of which follow the "zen of Python" and are
"Pythonic".
> 4. Hard cases and boring stuff need to get done too
True. This is one of the big weak areas of Open Source. Linux distro
management is a prime example of a thankless job that seems to have
quite a bit of burn-out. Bug fixing and doc writing tend to especially
suffer from Open Source, though they can be rubbish from paid services too.
> 5. Crowd-sourced decisions can be bad for you
As compared to the HIPPO decision making process (the "HIghest Paid
Person's Opinion")? Is there any actual research showing which is better
(I'm sure there is somewhere...)? Otherwise this is just an unsupported
supposition.
> 6. Our developers work for you, not just themselves
> Figuring out how other people want to use tools and creating
workflows that are broadly useful is one of those long-tail development
problems that open source typically leaves to the user to solve.
and
> 10. Paid software offers an open quid pro quo
QGIS seems to do this very well (as does GeoServer). By contrast, I've
reported bugs/issues to ESRI on a number of occasions and got back all
of the following over the years (paraphrased):
* "That's not what the standard says" (despite everyone else doing it
the other way).
* "Yes it's a crash bug, no we're not fixing it"
* "We can't take your bug report because you're not a paying customer".
Paid-for developers don't work for us either, they work for their bosses
who will almost certainly have different goals to us.
> 7. Unified computation requires unified design
> 8. Unified representation requires unified design
These seem like a re-hash of 1 and similarly tautological.
Ironically, a lot of those "unified" packages are usually glueing
together lots of Open Source parts. FME has 43 PAGES of legal terms for
all the component licenses -
https://cdn.safe.com/resources/fme/FMEDesktop_Legal_Notices_2018.0.pdf -
most of which are for Open Source licensed tools (Apache, BSD, MIT, GPL,
etc). I can't find the ESRI equivalent, but I'd be surprised if it
wasn't similar.
> 9. Open source doesn’t bring major tech innovation to market
Oh? Is Git not a "major tech innovation" that came to market? Blockchain
more recently (to the extent it's a buzzword that everyone is trying to
clamber onto despite it only being suited to a limited domain scope)? To
name two that immediately pop into mind.
> 11. It takes steady income to sustain long-term R&D
An interesting point. There's a huge amount of Open Source software that
was created as part of some academic project funded by public grants.
But when the project ends and grant dries up, the project is left by the
wayside. Sometimes though. the worthwhile ones get picked up by the
community (i.e. GRASS).
> 12. Bad design is expensive
> Much has been written about how total cost of ownership of major
commercial software is often lower than free open-source software, when
you take into account productivity, support costs, training costs, etc.
Seems to be Begging The Question.
It's true there's a huge amount of literature on the subject, but the
actual TCO depends on the project. Also, do Wolfram's TCO equations
include the countless hours people have to spend on license management.
That said, I agree with the core premise that something that's badly
designed can waste a lot of a user's time. The poor docs and lack of
real QA in a lot of Open Source projects are particularly a problem that
feeds into this.
Overall I think most of the arguments are somewhat specious, though
there are some good points hidden away in there. Open Source and
Proprietary both have their places, but there's a lot more overlap than
the article suggests.
Sure ArcGIS is much slicker than QGIS and has all the great
integration/uniformity etc that the article talks about, but for
support, I'll pick QGIS every time. If you *really* want something
fixed, you can still pay someone to do it (or do it yourself if you have
the chops); you're not reliant on a corporate monolith's "aligned
priorities".
Just my 2p.
Cheers,
Jonathan
On 2019-04-02 19:15, Jody
