Comparing Green Maps With Competing Technologies

There are many web site builders.  That is how the Green Party is run.  Here we have this web site.  Here we have that web site.  Here we have an email server.  There we have a spreadsheet.  Over here we have another spreadsheet.  Everyone gets the tools they need for the job at hand, but at the end of the day, we have a gazillion islands of automation, which do not talk to each other.   The data never gets updated, so many different versions of the data, all out of date and inconsistent.  It is a classic problem in large decentralized organizations. 

A different approach is needed.  Green Maps is not just an application.  Already it is multiple applications.   At its core, it is a data model of the Green Party.  It understands national, state and local parties, candidates, party officers, voters, geographic regions, and the relationships between them.  So it is easy to build any application needed.  Already it supports a national map, state maps, instant web sites for candidates, Green Parties, recommended voting lists, uncensored news, email newsletters, and two discord bots.  Very soon it will support multi-lingual web sites, and fund raising newsletters.  Whatever application is needed, can be very quickly built on top of Green Maps.  Meaning it is continuing to evolve very fast. 

So there are many web site builders, but there is only one domain model of the US Green Party.  Often people ask why use the Instant Web sites feature instead of a separate web site builder?   You could use a separate web site builder, but then you have two copies of the data to enter and maintain,  one for the maps, and one for your new web server, and in general the Green Party has difficulty even maintaining one copy of the data.

They talk about all of the volunteers who could do something.  Where are they?   

There is also the issue of functionality.  The Green Maps application supports so much functionality, and the new functionality is being rolled out at a faster and faster rate.  

The Green Maps security model is perfect for a large distributed organization.  In particular if you are a state-wide candidate, you do not only need a website for your campaign, but you need to make sure that each and every local party in your state has their own website also.  Green Maps already does that.  

Green Maps not only has more (useful) functionality than any of its competitors, it is also evolving faster.  Green Maps was written in just  12K lines of Python code on the server.  Plus libraries and client-side templates.  How did I do so much  single-handedly in so few lines of code?  Well it is a much more modern technical stack.  It is based on an object-graph database  the ZODB (1998). The competing technologies are mostly based on relational databases (1970) and the file system (1965).   Green Maps is based on Python.   After Javascript, Python is now the leading software language.  PHP is #10 on the list.  There is a reason for that. If you take a look at the Drupal or Word Press code bases, they will probably have at least an order of magnitude more source code, meaning that you need 10 times as many developers (and 10 times as long)  to make significant changes to them.  Personally I have no idea how to do this kind of stuff on a relational database.   The conceptual models are completely different.  I literally think differently than most other developers. 

The Democrats spend hundreds of millions of dollars on software, if we want to compete with them on a shoe string budget, we better be using the  most productive technologies available.  "There is a cost to not taking risks."

Of course Green Maps does not do everything.  i recommend Ghost.org for the things which Green Maps does not do.  CiviCRM also does some things which Green Maps does not do, but sadly CiviCRM is way way too cmplex.  It has 500 tables, and requires a developer to configure,  whereas Ghost.org is quite useable by an end user.