[OHM] Administrative changes to the OHM Github organization

Jeff Meyer jeff at gwhat.org
Sun Nov 3 02:22:41 UTC 2019


Hi all -

Here is some background & questions with some details below:

I’ve been paying developers to work on OHM features for the last couple of
years - timeslider, working search, refreshing site to current OSM, etc.,
with some new features coming soon, including: new inspector, new styles.
The goal of this has been to deliver cool time-based mapping features to
the community. They were also in line with documented OHM wish/need items.

We have not been able to deploy any of this software deployed, which I
believe is driving the friction identified by Rob & Albin below.

I agree with some of the goals outlined by Rob & Albin:
- Having code reviewed by community members before deployment
- Having a repo branch that represents deployed production code
- Need for a code of conduct
- We should align our github repos with best practices

While I disagree with some of Rob & Albin's other actions/decisions, I’m
also not sure the community fully understands their concerns. For example,
I don’t believe there was discussion of these concerns in any public, group
forum over the past year. Regardless of that, I want to see if we find a
model that works so that everyone feels respected and valued. Right now,
that’s clearly not the case. I’m also very sorry that it reached this
breaking point.

Rob & Albin -

I sincerely hope that you will reconsider the recent pronouncements,
restore the community access to github, and open a more interactive
discussion about how to resolve your concerns. I’d suggest at least 2 group
meetings and a deadline to have a new model within a month, but would
gladly engage in alternative community approaches.

Key question: I know you have the community’s best interests at heart, but
do these decisions have the support of the community? How do you know? What
if they don’t?

Thanks,
Jeff

P.S. I recently came across a relevant quote:

“Open source projects hinge entirely on contributors. Without regular
patches, the project dies. Or, as someone put it, rather ironically, in the
email that drove me out of the project:
‘A protocol spec only dies when people refuse to work together on it.’ “
- https://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/

DETAILS

A quick bit of background on my involvement with OHM:

   -

   I’ve been intrigued with the concept of an any geo, any time based map
   since 2004
   <https://www.slideshare.net/gwhathistory/global-world-history-atlas-introduction-2004>


   -

   Around 2012, I came across the OSM community and the OSM stack and
   talked with a bunch of people (Steve Coast, Ian Dees, Mikel Maron) about
   using it for historical mapping. Turns out, it had been discussed by a
   bunch of other people prior to that (Frankie Roberto, Schuyler Erle, Tim
   Waters, Sanjay & others)
   -

   In late 2012 and early 2013, I helped set up the original OHM website
   along with Rob, Tim Waters, Sanjay, & others & hosted the first Hangouts
   -

   From 2015-2017, I had to check out of the community for a few years due
   to work, getting married, etc. I regret that absence deeply.
   -

   In early 2018, came back to my passion, OHM, and found that little had
   changed in terms of features to the core website. The OHM Tasking Manager
   <http://tasks.openhistoricalmap.org/> was up (Thanks, Bert) & that was
   and is awesome. The site itself was still up in spite of a scary outage and
   hosting transfer (Thanks to Rob!). But, it was lacking new features and the
   site were out of sync with mainline OSM. Unsatisfied with the pace of OHM
   feature dev over the past 5 years and not seeing any motion for that to
   change, out of my own pocket, I hired a nonprofit dev firm
   <https://www.greeninfo.org/> with ties to Stamen <https://stamen.com/>
   and OSM board members. I asked them to start working on desired features
   already identified within the community. Later, we added members of
Development
   Seed <https://www.developmentseed.org/>, another firm with very close
   ties to the OSM community and also the original OHM sysadmin, Sanjay. I
   viewed all of these people as legitimate 1st-class members of the OHM
   community and with OHM’s goals and best interests at heart. All of the work
   performed has been designated open source and as close to license free as
   possible. No one involved in this effort has any commercial interest in the
   work being done. We all just want to get features added to OHM and to see
   it thrive. I have not wanted to identify myself as the source of the
   funding of these efforts on this list, as I have thought it wasn’t
   important, don’t want any credit, and don’t want this to be viewed as 1
   person’s project. It’s not. It’s a community effort.
   -

   They have built the time slider you’ve seen on our prototype site, made
   search work, and are working on a new inspector and map style. We are
   currently trying to get this software deployed, which is driving some of
   the friction identified in Albin & Rob’s mail.
   -

   I’ve also worked to make the OHM community more active and have been
   hosting frequent meetings, postings to the aliases, attendance at
   conferences, and outreach to other groups, which I’ve tried to share with
   the community.
   -

   My ultimate goals have been to:
   -

      Get the OHM feature-rich enough to be a more appealing platform a
      wider user base
      -

      Make OHM a more appealing part of grant proposals
      -

      Essentially to make OHM a little closer to its stated vision of a
      rich environment for historical mapping


I would suggest we use HOT OSM as a good comparable and example of how to
encourage participation across a community and to create a rich environment
for application development. https://github.com/hotosm

I’d also suggest we look at some basic best practices for github
organization management,
https://github.com/todogroup/guides/blob/master/participating-in-open-source.md


On Fri, Nov 1, 2019 at 1:40 PM Albin Larsson <albin.post at gmail.com> wrote:

> Hi Jeff and thank you for sharing your concerns and questions.
>
> > Can you share some of the details about the "concerns about the
> sustainability of the project" or of how the gatekeeper approach will work?
>
> I do not intend to turn this into a gatekeeper approach long term. To
> begin I think we need to make sure the code on Github represent the code on
> the server. Baby steps. Regarding pull request those will be managed by
> whoever maintains a repository. The only repository which today represents
> code running on the server is the task manager one. Bert who maintains it
> have already full access to it and can merge pull requests.
>
> Before this change anyone of the many owners could delete any code, invite
> anyone, commit whatever code, and edit git history. We can't have it that
> way and we can certainly not deploy code we do not trust.
>
> > If I made a pull request to completely rebase the whole project, as the
> code base is 7 years old, how would that be reviewed?
>
> No matter the organisation that would require both meetings and
> coordination. I assume in the end when it comes to Github the repository
> would be replaced with a new one.
>
> >what are the metrics of success for this model?
>
> The first aim is to to actually clean up Github and make sure it
> represents the code on the server. To allow incremental change in the first
> place.
>
> >Contrary to Albin's assertion, I for one, am very confident about the
> future of the project, but I do have concerns about our current lack of
> governance and individual control over any parts of our operations.
>
> I read such concerns as sustainability concerns. I'm deeply sorry if I
> have misrepresented someones concerns.
>
> >This project was started as a community effort, with community
> consultation, and community input to how things should be done. I am hoping
> that will continue.
>
> It's my belief that this change and the clean up will allow community
> contributions to be merged and deployed to begin with. Without that
> possibility community meetings and input doesn't do much. While general
> concerns regarding governance are related to this I consider such concerns
> out of scope for this particular effort. Solutions to those concerns would
> also require wider community consultation.
>
> Best regards
> //
> Albin Larsson
>
> On Fri, Nov 1, 2019, 15:53 Jeff Meyer <jeff at gwhat.org> wrote:
>
>> Albin, Rob -
>>
>> Thanks for bringing these issues to light & thank you both for your
>> leadership & hard work.
>>
>> I don't speak for the community, but there may be many questions out
>> there about these points, I certainly have many questions, I don't agree
>> with many of the points above, and I'd love to see if we can organize some
>> community solutions.
>>
>> Can you share some of the details about the "concerns about the
>> sustainability of the project" or of how the gatekeeper approach will work?
>> E.g. how will pull requests be approved? If I made a pull request to
>> completely rebase the whole project, as the code base is 7 years old, how
>> would that be reviewed?  Also, what are the metrics of success for this
>> model?
>>
>> Contrary to Albin's assertion, I for one, am very confident about the
>> future of the project, but I do have concerns about our current lack of
>> governance and individual control over any parts of our operations.
>>
>> I'll send more thoughts in the next couple of days, but I find these
>> steps to be quite strong reactions to some vaguely-referenced & not openly
>> discussed concerns.
>>
>> This project was started as a community effort, with community
>> consultation, and community input to how things should be done. I am hoping
>> that will continue.
>>
>> Regards,
>> Jeff
>>
>>
>>
>> On Wed, Oct 30, 2019 at 11:48 AM Rob H Warren <warren at muninn-project.org>
>> wrote:
>>
>>> I want to thank Albin for taking care of the github organization, which
>>> is a thankless job. Projects on github were no longer manageable and not
>>> being able to track what was deployable and who-owned-what was hindering
>>> operations. OHM is going through the same issues that OSM and other open
>>> source projects have to deal with and this was necessary. Going forward,
>>> pull requests are going to be required to specific repos for any
>>> operational deploy.
>>>
>>> There are many critics of this gatekeeper approach[1]; balanced out by
>>> the chaos that results when too many cooks spoil the broth. Vectored tiles
>>> and the timeslider *will* be integrated into the main site and a clustered
>>> tile service is on its way. Please realize that the devil is in the
>>> details, there is technical debt and there are moving parts that are not
>>> obvious.
>>>
>>> OHM is based on the OSM stack with all of its glitter and warts. Yes, it
>>> has acknowledged problems. It was also designed by people with the
>>> foresight to support third party applications and authentication. If you
>>> think some great application is missing, go ahead and build it; no one will
>>> stop you. But before you do, take the time to read through the relevant
>>> standards and ask around: all of these standards have more than one gotcha!
>>> It's your time that's wasted if it doesn't work and half-baked solutions
>>> will not get deployed.
>>>
>>> It may be time for a code of conduct[2,3], through I'm not sure how to
>>> formalize "We're not your employees" and "Be a decent human being". I've
>>> hesitated to discuss this publicly so far, but my watershed moment was
>>> earlier this year when OHM "followed me to work". Someone (who could be a
>>> stand-in for "Pig-Pen" in the Peanuts comic) managed to get into a
>>> corporate event to share their strong enthusiasm about OHM. It's still
>>> unclear how a badge was issued but it did not reflect positively on anyone.
>>>
>>> Besides the routine administrivia, I've received demands/requests for
>>> root access, password files and raw database dumps. DNS requests for
>>> services that were meant to die. Sometimes the request is politely written,
>>> sometimes not. The behaviour is best described by the quote: "The reason
>>> it's so vicious is because it doesn't matter".  Also, we may have never
>>> written this down because it should be earthquake obvious but: OHM has a
>>> responsibility to its users and will not release its user data. Period. I
>>> can't make it any clearer.
>>>
>>> Lastly, OHM is a community project with a decentralized structure that
>>> caters to a wide audience. This includes the survivalist in his log cabin
>>> on a 27th floor NYC condo,  the teenager in his parent's basement with an
>>> unhealthy interest in the Sumer trade routes and other documenting
>>> ...forgotten payphone locations? We don't judge, you are all welcome. Do
>>> what you are passionate about, go your own way and do good work.
>>>
>>> All my best,
>>> R
>>> [1] https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/
>>> [2]
>>> https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/
>>> [3] https://lwn.net/Articles/759654/
>>> _______________________________________________
>>> Historic mailing list
>>> Historic at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/historic
>>>
>>
>>
>> --
>> Jeff Meyer
>> 206-676-2347
>> osm: Open Historical Map (OHM)
>> <http://wiki.openstreetmap.org/wiki/Open_Historical_Map> / my OSM user
>> page <http://www.openstreetmap.org/user/jeffmeyer>
>> t: @OpenHistMap
>>
>>
>>
>>
>> _______________________________________________
>> Historic mailing list
>> Historic at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/historic
>>
>

-- 
Jeff Meyer
206-676-2347
osm: Open Historical Map (OHM)
<http://wiki.openstreetmap.org/wiki/Open_Historical_Map> / my OSM user page
<http://www.openstreetmap.org/user/jeffmeyer>
t: @OpenHistMap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/historic/attachments/20191102/ec368387/attachment-0001.html>


More information about the Historic mailing list