[OSGeo-Discuss] good article on open source considerations

[Jonathan Moules]

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 Garnett wrote:
> Now that open source is a established part of the IT landscape we can start
> to see well thought out articles; which are much harder to answer then the
> FUD we encountered earlier in the adoption curve.
>
> https://blog.wolfram.com/2019/04/02/why-wolfram-tech-isnt-open-source-a-dozen-reasons/
>
> It is worth thinking through these topics as we still have a lot of
> advocacy work to do in our mapping/location industry.
>
> In the specific case of wolfram I love the work and RnD they have done.
> Would much rather see symbolic computing (and so on..) have a wider reach
> into more fields then be bottled up by one company. Long term I think that
> will occur. Short term I like that the open science is taking folks away
> from replying on their tools from a “good science is reproducible science”
> standpoint.
>
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20190405/b4181a79/attachment.html>