OpenLayers Module Parting Note

Hey OpenLayers Module users & developers,

So, you probably have heard that Development Seed isn't doing Drupal for products or projects anymore - it's been quite a few months since I've actually started up Drupal.

It's been great working on OpenLayers, but at this point I'm basically signing off - I'm no longer doing support, development, etc. for the module. Not using it myself makes any sort of actual development pretty tricky and I'm working on other projects that are doing similar things. It's been great working with Patrick, Alan, and everyone else.

That said, there's a lot of potential for the project - it's nearing 3k users, and has a lot of good code. For advanced use cases, I think it's the way to go for Drupal development. That said, a buggy codebase and continuing problems with compatibility and performance aren't showing any signs of changing. I think there are some structural changes that could happen here, and some directions that you could take which would be interesting.

Configuration Formats

OpenLayers manages each layer type and behavior in three separate places - javascript 'connectors', php code, and the database. If things are exported, this can be four. This makes maintenance a headache, upgrade paths harder, and the code far larger and buggier than it needs to be.

One way to skip a step here is to use Wax Records, which are basically JSON representations of imperative code. It's a little weird at first, but the benefit is that the thing you have in your database is the map, with no odd layer of translation between the two. It's one way to go - the other way is to write a declarative configuration system for a mapping API, something that I'd like to do soon.

Users and Developers

The OpenLayers module has a lot of bugs, and a lot of users. Unfortunately, the Drupal community tends to have a small number of developers versus a large number of users, so the expansion of the userbase hasn't made the developers lives easier or their work less. There are great counterpoints to this - some good patches, some users who are very active. But the main problem is that the module is massive and has some relatively difficult concepts (layer types, behaviors, the tri-part composition of a normal map, etc.), so few users have enough time in their web development projects to actually understand how things work, and therefore understand how to fix their own problems.

Drupal

Drupal 7 is a performance problem, and the Views / Fields system is very poorly suited for anything other than vanilla page-HTML output. Making mapping modules is more difficult rather than less in the new system.

More than that, even our implementation in Drupal 6 was stretching what the Views module was made for - which is, yet again, vanilla HTML output. And it didn't work well, and wasn't obviously. The sad part is that the reasons why we use Views - the query builder, permissions, etc., can't be had on their own because the module is sadly monolithic and massive - in its relentless pursuit of codeless coding.

OpenLayers may want to drop Views as its only source of data. It can be an option, but Views are not a good metaphor for everything.

OpenLayers

The OpenLayers project seemed like the only option at the time, but it isn't, and it isn't the best option either. OpenLayers is a massive codebase that has gone far too long between rewrites (as in, it has never had one). It makes configuration an unnecessary nightmare, one that the module goes to lengths to patch together.

Ideally it would be the Modest Maps or Leaflet module, not the OpenLayers module. Otherwise the module will only be as great as OpenLayers itself - which means not great.