Making Weathermap “really” open source

Although Weathermap has always been available under the GPL, you could reasonably argue that it’s not really open source. The reason it’s GPLed is simply that it was originally written in perl, based off of GRNET’s perl Weathermap, way back at the end of 2004. When I got tired of explaining how CPAN works (to install the perl GD module and dependencies) and switched to PHP, I kept the same license.

Despite being GPLed for 10 years, there have been very few code contributions. I can see why – it’s a fairly big tangled mess of PHP, considering the relatively simple job it does. It was my first PHP application from scratch too, and has lived long enough to be partly PHP 4 and partly PHP 5 style. Even if you do make the effort to read it all, you’ll find it has a few “god objects” which make modification harder than it needs to be. So effectively, it’s a personal project that you could re-use if you really wanted to.

Also the number of users – network engineers, mostly – who can and want to code is pretty small. I don’t want to discourage the few that remain!

Having worked a little on other “real”  open source projects, I really want to change this. For example, when I had an issue with beets, I was able to submit patches, get useful feedback from the project lead, and eventually get my change into the next release. It felt good, was collaborative, and solved my problem permanently too. That’s the kind of experience I want for Weathermap.

The first steps towards this have already happened – moving from subversion to github gets us the infrastructure to do Pull Requests, which is very powerful. There are the beginnings of unit tests, and more on the way as new code is added, to hopefully get to the stage that any PRs can be tested automatically using TravisCI. The code quality is (slowly) improving, and the ‘master’ branch on github has the results of some refactoring already. It may be that only some of that work makes it into a release, but the goal is to get to more and smaller classes, much reduced global variable usage and documented classes!

I have been using CodeClimate to highlight areas to work on, mostly for removing complexity and duplication so far. For example, processing of data source targets in the refactored version is a lot cleaner. Also, as UI code is moved into classes, it makes that easier to test too, which is a big gap currently – the image generation side of things has hundreds of tests. Similarly, there are Vagrant configuration files to automatically produce test environments on 10 or so difference Linux distros.

At the moment, things are still moving around, but once the next couple of releases are complete, I’ll be working on bringing the ‘new’ version and the 0.97-maintenance branches back together, and hopefully have a working version with as much of the new code as possible. Parts (especially the Node class) are still too big and clunky, but there is some useful work already done.

With that in place, I hope we can have a really open source network visualisation tool!

6 thoughts on “Making Weathermap “really” open source

    1. Howard Post author

      What do you like to do? As soon as it’s possible for more than one person to reasonably work on code, I’ll get a task list together. For documentation, things are more open. For testing and platform support, what platforms would it be?

      Reply
      1. Dan Farrell

        I’ve used this for years and loved it… and I’ve always wanted to contribute. To answer your question, I like tying together sites and databases, so if Weathermap ever had a need/desire to have a mysql backend, that would be neat to construct.

        Reply
      2. Bryan

        Sorry for the delay, I am still very interested. I didn’t get an email for a reply, and this is the first time I have checked it since I posted the last comment.

        I can spin up any number of platforms. I typically use VM (virtualbox) and can spin up anything from Linux, Mac and Windows with basic configurations. I do have a working Mac OS X using Sierra, which I use regularly.

        As far as coding, I use PHP and Python regularly. I have also extensive background in MySQL. I agree with Dan, some MySQL backend options would be very nice. I’m currently dumping BW data from MySQL into a CSV, and something a bit more native would be awesome.

        If you get a tasklist together, let me know, and I can help you knock them out. Please email me directly once you get one together.

        Reply
      3. Howard Post author

        Cool – I’ll try to get together:
        1) a list of tasks, and some documentation on “policy” (sounds bad, but just goals for future changes really)
        2) some kind of communications channel for development – maybe a different google group, slack, or gitter

        For the database backend thing specifically – there’s actually a sample DS plugin already in the download, although I haven’t tested it any time recently. I’ll make sure it’s correct before 0.98a comes out. It’s pretty simple to write data plugins.

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.