[Geo4All] Vision for an OSGeo education program

[Tom Roche]

[endnotes follow .sig]

Kurt Menke[1]
> Even if [GeoAcademy[2]] isn't exactly what some want it is a great starting place and can be modified and added to as needed. There is even a workbook for it. It's far easier to modify something that exists than to start from scratch.

I agree ... provided one remembers that, in the end (and often in the beginning :-) it's *users* (in this domain, teachers and students) that decide what works and doesn't, not designers. Definitely adapt what we can where we can, but work "bottom-up"[3], and try not to force users into something for our convenience. Note again that

1. My personal experience in this topical domain (developing GIS software for primary- and secondary education) is quite limited:

1.1. my experience with education software (except as a user) was coding on the evaluation side (i.e., online assignment/test delivery/grading) of a courseware platform.

1.2. I have no experience with GIS development, except for coding NCL, Python, and R for evaluating the output of environmental models.

That being said, objectively,

2. The history of software development is littered with the graves of projects started and led by very bright people who had brilliant insights toward solving problems, and who invested millions of person-hours and billions of dollars in "solutions"[4] that either

2.1. proved to be unimplementable due to design-internal contradictions that were not obvious until implement ("emergent complexity")

2.2. failed to automate what the *users* actually needed to automate

2.3. failed to integrate with other user-required processes

2.4. provided (what the *users* felt to be) an unacceptable user experience (UX)

3. Being a good GIS developer no more makes one a good courseware developer than having been a good student makes one a good teacher.

4. The probability of success of a development effort tends to be proportional to its investment in testing. Development efforts that overinvest in design and implementation relative to testing tend to fail.

Kurt Menke[1]
> The trickier parts to me are things like:
> * how to work with different age/national groups

not to mention classrooms with different hardware and ISP QoS (more below), and different language/culture communities

> * how to package it - it may need to be [pared] down
> * who does what?
> * how to present it on the web

One reliable way to UX-fail is to depend on an unreliable or unperformant platform. Web should work well in much of the US, for instance, but there are still significant parts where internet access (even for schools) is slow or unreliable, which will probably be even more of a concern in much of the rest of the world. This is not to reject *HTTP*-based solutions, but (should one decide to "go down that road") to urge developing something that can run from localhost or an easily-deployed intranet, and not depend on external access.

> * is there an online workspace or learning platform or just a package of educational material?

> Boston[6] does seem like an achievable test bed for something

*Classrooms*--students and teachers--are the only testbed that matters for courseware! not developer meetings. Remember: real-world testing is to software what experiments are to science.

This is why I strongly suggest integrating "bottom-up" rather than adapting "top-down"[3]. ESRI has succeeded top-down because they have monopoly profits (esp in the US), which has enabled them to deploy regiments of consultants into spaces like education (where direct profit → 0, but potential long-term profit from lock-in is large) to create shims between their monolithic product and myriads of users. I suspect (and ICBW) we won't be able to do this: instead, we will need to grow courseware solutions up from the users (à la Linux[5]) that delivers good UX early on, and spreads by word-of-mouth.

Net for Boston[6]: target should (IMHO, ICBW) not be to sit'n'sprint on a BDUF[4] for a worldwide GIS courseware. Instead, start working now with a few target groups[3], discovering

* what each individual target group needs
* how to adapt what we already have toward each local need
* what needs to be developed to fill gaps (aka Δ, "the delta") between what we already have and the local need

Where the target group Δ is small, Boston can discuss development experiences, and plan how to integrate the local experiences into something for larger-scale rollout. Where Δ is large, Boston can discuss how to gapfill.

FWIW, Tom Roche <Tom_Roche at pobox.com>

[1]: https://lists.osgeo.org/pipermail/geoforall/2016-November/003280.html
[2]: http://spatialquerylab.com/foss4g-academy-curriculum/
[3]: https://lists.osgeo.org/pipermail/geoforall/2016-November/003273.html
[4]: https://en.wikipedia.org/wiki/Big_Design_Up_Front
[5]: The history of Linux from its earliest days has not been about Torvalds saying, "Here's my MINIX for the PC, hope it works for you." Instead, it was Torvalds saying, "let's do a PC OS, here's what I've got, how's it work for you?" and taking patches (eventually adopting full version control) and {bug reports, feature requests} seriously, discarding what fails and adopting what works. In the case of courseware development, patches will typically be scarce, but expect lots BR/FRs.
[6] http://2017.foss4g.org/