Welcome Ecuador (Country 29)

It is with mixed emotions that I get to announce that we now have a customer in Ecuador, our 29th country.

My emotions are mixed as my excitement at having a new customer in a new country is offset by the tragedy that country suffered recently. Everyone at OpenNMS is sending out our best thoughts and we hope things settle down (quite literally) soon.

They join the following countries:

Australia, Canada, Chile, China, Costa Rica, Denmark, Egypt, Finland, France, Germany, Honduras, India, Ireland, Israel, Italy, Japan, Malta, Mexico, The Netherlands, Portugal, Singapore, Spain, Sweden, Switzerland, Trinidad, the UAE, the UK and the US.

OpenNMS is Sweet Sixteen

It was sixteen years ago today that the first code for OpenNMS was published on Sourceforge. While the project was started in the summer of 1999, no one seems to remember the exact date, so we use March 30th to mark the birthday of the OpenNMS project.

OpenNMS Project Details

While I’ve been closely associated with OpenNMS for a very long time, I didn’t start it. It was started by Steve Giles, Luke Rindfuss and Brian Weaver. They were soon joined by Shane O’Donnell, and while none of them are associated with the project today, they are the reason it exists.

Their company was called Oculan, and I joined them in 2001. They built management appliances marketed as “purple boxes” based on OpenNMS and I was brought on to build a business around just the OpenNMS piece of the solution.

As far as I know, this is the only surviving picture of most of the original team, taken at the OpenNMS 1.0 Release party:

OpenNMS 1.0 Release Team

In 2002 Oculan decided to close source all future work on their product, thus ending their involvement with OpenNMS. I saw the potential, so I talked with Steve Giles and soon left the company to become the OpenNMS project maintainer. When it comes to writing code I am very poorly suited to the job, but my one true talent is getting great people to work with me, and judging by the quality of people involved in OpenNMS, it is almost a superpower.

I worked out of my house and helped maintain the community mainly through the #opennms IRC channel on freenode, and surprisingly the project managed not only to survive, but to grow. When I found out that Steve Giles was leaving Oculan, I applied to be their new CEO, which I’ve been told was the source of a lot of humor among the executives. The man they hired had a track record of snuffing out all potential from a number of startups, but he had the proper credentials that VCs seem to like so he got the job. I have to admit to a bit of schadenfreude when Oculan closed its doors in 2004.

But on a good note, if you look at the two guys in the above picture right next to the cake, Seth Leger and Ben Reed, they still work for OpenNMS today. We’re still here. In fact we have the greatest team I’ve every worked with in my life, and the OpenNMS project has grown tremendously in the last 18 months. This July we’ll have our eleventh (!) annual developers conference, Dev-Jam, which will bring together people dedicated to OpenNMS, both old and new, for a week of hacking and camaraderie.

Our goal is nothing short of making OpenNMS the de facto management platform of choice for everyone, and while we still have a long way to go, we keep getting closer. My heartfelt thanks go out to everyone who made OpenNMS possible, and I look forward to writing many more of these notes in the future.

OpenNMS at Scale

So, yes, the gang from OpenNMS will be at the SCaLE conference this weekend (I will not be there, unfortunately, due to a self-imposed conference hiatus this year). It should be a great time, and we are happy to be a Gold Sponsor.

But this post is not about that. This is about how Horizon 17 and data collection can scale. You can come by the booth at SCaLE and learn more about it, but here is the overview.

When OpenNMS first started, we leveraged the great application RRDTool for storing performance data. When we discovered a java port called JRobin, OpenNMS was modified to support that storage strategy as well.

Using a Round Robin database has a number of advantages. First, it’s compact. Once the file containing the RRD database is created, it never grows. Second, we used RRDTool to also graph the data.

However, there were problems. Many users had a need to store the raw collected data. RRDTool uses consolidation functions to store a time-series average. But the biggest issue was that writing lots of files required really fast hard drives. The more data you wanted to store, the greater your investment in disk arrays. Ultimately, you would hit a wall, which would require you to either reduce your data collection or partition out the data across multiple systems.

No more. With Horizon 17 OpenNMS fully supports a time-series database called Newts. Newts is built on Cassandra, and even a small Cassandra cluster can handle tens of thousands of inserts a second. Need more performance? Just add more nodes. Works across geographically distributed systems as well, so you get built-in high availability (something that was very difficult with RRDTool).

Just before Christmas I got to visit a customer on the Eastern Shore of Maryland. You wouldn’t think that location would be a hotbed of technical excellence, but it is rare that I get to work with such a quick team.

They brought me up for a “Getting to Know You” project. This is a two day engagement where we get to kick the tires on OpenNMS to see if it is a good fit. They had been using Zenoss Core (the free version) and they hit a wall. The features they wanted were all in the “enterprise” paid version and the free version just wouldn’t meet their needs. OpenNMS did, and being truly open source it fit their philosophy (and budget) much better.

This was a fun trip for me because they had already done most of the work. They had OpenNMS installed and monitoring their network, and they just needed me to help out on some interesting use cases.

One of their issues was the need to store a lot of performance data, and since I was eager to play with the Newts integration we decided to test it out.

In order to enable Newts, first you need a Cassandra cluster. It turns out that ScyllaDB works as well (more on that a bit later). If you are looking at the Newts website you can ignore the instructions on installing it as it it built directly into OpenNMS.

Another thing built in to OpenNMS is a new graphing library called Backshift. Since OpenNMS relied on RRDTool for graphing, a new data visualization tool was needed. Backshift leverages the RRDTool graphing syntax so your pre-defined graphs will work automatically. Note that some options, such as CANVAS colors, have not been implemented yet.

To switch to newts, in the opennms.properties file you’ll find a section:

###### Time Series Strategy ####
# Use this property to set the strategy used to persist and retrieve time series metrics:
# Supported values are:
#   rrd (default)
#   newts

org.opennms.timeseries.strategy=newts

Note: “rrd” strategy can refer to either JRobin or RRDTool, with JRobin as the default. This is set in rrd-configuration.properties.

The next section determines what will render the graphs.

###### Graphing #####
# Use this property to set the graph rendering engine type.  If set to 'auto', attempt
# to choose the appropriate backend depending on org.opennms.timeseries.strategy above.
# Supported values are:
#   auto (default)
#   png
#   placeholder
#   backshift
org.opennms.web.graphs.engine=auto

If you are using Newts, the “auto” setting will utilize Backshift but here is where you could set Backshift as the renderer even if you want to use an RRD strategy. You should try it out. It’s cool.

Finally, we come to the settings for Newts:

###### Newts #####
# Use these properties to configure persistence using Newts
# Note that Newts must be enabled using the 'org.opennms.timeseries.strategy' property
# for these to take effect.
#
org.opennms.newts.config.hostname=10.110.4.30,10.110.4.32
#org.opennms.newts.config.keyspace=newts

There are a lot of settings and most of those are described in the documentation, but in this case I wanted to demonstrate that you can point OpenNMS to multiple Cassandra instances. You can also set different keyspace names which allows multiple instances of OpenNMS to talk to the same Cassandra cluster and not share data.

From the “fine” documentation, they also recommend that you store the data based on the foreign source by setting this variable:

org.opennms.rrd.storeByForeignSource=true

I would recommend this if you are using provisiond and requisitions. If you are currently doing auto-discovery, then it may be better to reference it by nodeid, which is the default.

I want to point out two other values that will need to be increased from the defaults: org.opennms.newts.config.ring_buffer_size and org.opennms.newts.config.cache.max_entries. For this system they were both set to 1048576. The ring buffer is especially important since should it fill up, samples will be discarded.

So, how did it go? Well, after fixing a bug with the ring buffer, everything went well. That bug is one reason that features like this aren’t immediately included in Meridian. Luckily we were working with a client who was willing to let us investigate and correct the issue. By the time it hits Meridian 2016, it will be completely ready for production.

If you enable the OpenNMS-JVM service on your OpenNMS node, the system will automatically collected Newts performance data (assuming Newts is enabled). OpenNMS will also collect performance data from the Cassandra cluster including both general Cassandra metrics as well as Newts specific ones.

This system is connected to a two node Cassandra cluster and managing 3.8K inserts/sec.

Newts Samples Inserted

If I’m doing the math correctly, since we collect values once every 300 seconds (5 minutes) by default, that’s 1.15 million data points, and the system isn’t even working hard.

OpenNMS will also collect on ring buffer information, and I took a screen shot to demonstrate Backshift, which displays the data point as you mouse over it.

Newts Ring Buffer

Horizon 17 ships with a load testing program. For this cluster:

[root@nms stress]# java -jar target/newts-stress-jar-with-dependencies.jar INSERT -B 16 -n 32 -r 100 -m 1 -H cluster
-- Meters ----------------------------------------------------------------------
org.opennms.newts.stress.InsertDispatcher.samples
             count = 10512100
         mean rate = 51989.68 events/second
     1-minute rate = 51906.38 events/second
     5-minute rate = 38806.02 events/second
    15-minute rate = 31232.98 events/second

so there is plenty of room to grow. Need something faster? Just add more nodes. Or, you can switch to ScyllaDB which is a port of Cassandra written in C. When run against a four node ScyllaDB cluster the results were:

[root@nms stress]# java -jar target/newts-stress-jar-with-dependencies.jar INSERT -B 16 -n 32 -r 100 -m 1 -H cluster
-- Meters ----------------------------------------------------------------------
org.opennms.newts.stress.InsertDispatcher.samples
             count = 10512100
         mean rate = 89073.32 events/second
     1-minute rate = 88048.48 events/second
     5-minute rate = 85217.92 events/second
    15-minute rate = 84110.52 events/second

Unfortunately I do not have statistics for a four node Cassandra cluster to compare it directly with ScyllaDB.

Of course the Newts data directly fits in with the OpenNMS Grafana integration.

Grafana Inserts per Second

Which brings me to one down side of this storage strategy. It’s fast, which means it isn’t compact. On this system the disk space is growing at about 4GB/day, which would be 1.5TB/year.

Grafana Disk Space

If you consider that the data is replicated across Cassandra nodes, you would need that amount of space on each one. Since the availability of multi-Terabyte drives is pretty common, this shouldn’t be a problem, but be sure to ask yourself if all the data you are collecting is really necessary. Just because you can collect the data doesn’t mean you should.

OpenNMS is finally to the point where the storing of performance data is no longer an issue. You are more likely to hit limits with the collector, which in part is going to be driven by the speed of the network. I’ve been in large data centers with hundreds of thousands of interfaces all with sub-millisecond latency. On that network, OpenNMS could collect on hundreds of millions of data points. On a network with lots of remote equipment, however, timeouts and delays will impact how much data OpenNMS could collect.

But with a little creativity, even that goes away. Think about it – with a common, decentralized data storage system like Cassandra, you could have multiple OpenNMS instances all talking to the same data store. If you have them share a common database, you can use collectd filters to spread data collection out over any number of machines. While this would take planning, it is doable today.

What about tomorrow? Well, Horizon 18 will introduce the OpenNMS Minion code. Minions will allow OpenNMS to scale horizontally and can be managed directly from OpenNMS – no configuration tricks needed. This will truly position OpenNMS for the Internet of Things.

UPDATE: Alejandro pointed out the following:

There is a property in OpenNMS for Newts that doesn’t appear in opennms.properties called heartbeat org.opennms.newts.query.heartbeat, which expects a duration in milliseconds. By default is 450000 (i.e. 1.5 x 5min) and it is used when no heartbeat is specified. Should generally be 1.5x your biggest collection interval.

If you were using 10 minute polls, set it to 15 min (1.5 x 10min), and then you will see graphs. To do this, add the following to opennms.properties and restart OpenNMS:

org.opennms.newts.query.heartbeat=900000

♫ Don’t Call It a Comeback ♫

Welcome to 2016. My year started out with an invitation to join the AARP. (sigh)

As my three readers know, when it comes to this business of open source we are pretty much making things up as we go along. We are lead by our business plan of “spend less money than you earn” and our mission statement of “help customers, have fun, make money” but the rest is pretty fluid.

In 2013 we mixed things up and tried a more “traditional” start up path by seeking out investment and spending more money than we had. It didn’t work out so well.

Thus 2014 was more of a rebuilding year as we tried to move the focus back to our roots. It paid off, as 2015 was a very good year. We had record gross revenues, and although we didn’t make much money on the bottom line, it was positive once again. At the moment we are still investing in the company and the project so pretty much every extra dollar goes into growth.

And we had a lot of growth. The decision to split OpenNMS into Meridian and Horizon paid off in three major Horizon releases. Horizon 17 was an especially large and important release as it brought in the Newts integration. At the moment we are working with it on a customer site using a ScyllaDB cluster capable of supporting 75K inserts per second. The technologies introduced in 2015 will make it in to Meridian 2016, due in the spring, and it should solidify OpenNMS as a platform that can really scale.

In 2015 we also received orders from two of the Fortune 5 companies. I’ll leave it as an exercise to the reader to guess which two and you have a 1 in 16 shot at getting it right (grin). The fact that companies that can choose, literally, any technology they want yet they choose OpenNMS speaks volumes.

One of these days we’re going to have to figure out a way to talk about our customers by name, since they are all so cool. We are working on it, but it is surprisingly difficult to get permission to publicly post that information. Above all we respect our clients’ privacy.

I have high expectations for 2016 and the power of the Open Source Way. Thanks to everyone who has supported us over the last decade and more, and we just hope you find our efforts provide some value.

Happy New Year.

I, Robot

Today is the 11th anniversary of The OpenNMS Group. We started on September 1st, 2004 with little more than a drive to build something special, a business plan of “spend less than you earn” and a mission statement of “Help Customers, Have Fun, Make Money”.

Since I’m still working and people are using software other than OpenNMS to manage their networks, I can’t say “mission accomplished” but we’re still here, we have a great team and the best users anyone could want, so by that measure we are successful.

When it comes to the team, one thing I worry about is how to connect our remote people with the folks in North Carolina. We do a lot of Hangouts, etc, but they lack the aspect of initiative – the remote guys have to be passive and just sit there. Then I got the wild idea to investigate getting a telepresence robot. Wouldn’t it be cool if remote people could pop in and drive around the office, attend meetings, etc?

After a lot of research, I decided on a robot from Double Robotics.

Robot Tarus

The buying decision wasn’t a slam dunk. It is a very iPad/iOS centric solution which bothered me, and I had some issues concerning the overall security of the platform. So, I sent in a note and ended up having a call with Justin Beatty.

It was a great call.

Double is pretty serious about security, and assuming there are no firewall issues, the connection is encrypted peer-to-peer. While there are no plans to remove the requirement that you buy an iPad in order to use the robot, they are working on an Android native client. You can drive it on almost any platform that supports the Chrome browser (such as Linux) and you can even use it on Android via Chrome. There is a native iOS app as well.

What really sold me on the company is that they are a Y Combinator project, and rather than focus on raising more capital, they are focused on making a profit. They are small (like us) and dedicated to creating great things (like us).

Justin really understood our needs as well, as he offered us a refurbished unit at a discount (grin).

Anyway, I placed an order for a Double and (gulp) ordered an iPad.

It was delivered while I was away in England, but I was able to get it set up on Monday when I returned to the office. They have a number of easy to follow videos, and it probably took about 20 minutes to understand how everything went together.

You take the main body of the robot out of the box and place it on the floor. I had purchased an external speaker kit (otherwise, it uses the iPad speaker) which makes it look like a little Dalek, and you install that on the main post. Then you plug in the iPad holder and screw it to the post with a bolt. That’s about it for robot assembly.

The next step is to take the USB charging cable that came with your tablet and mount it inside the iPad holder. You then insert the iPad upside down and connect the cable so that the robot can power and recharge the iPad. The Double supports any iPad from version 2 onward, and they have a spacer to use for the iPad Air (which is thinner). Finally, you connect a directional microphone into the audio slot on the bottom of the iPad (or top, depending on how you look at it) and the unit is assembled.

Then I had to set up the iPad, which was a bit of a pain since I’m no longer an Apple person and needed a new Apple account (and then I had to update iOS), but once it was configured I could then pair the iPad to the robot via bluetooth. Next, I had to download the Double app from the App Store and create a Double account. Once that process was complete, I could login to the application on the tablet and our robot was ready to go.

To “drive” the robot, you log in to a website via Chrome. There are controls in the webapp for changing the height of the unit, controlling audio and video, and you move the thing around with the arrow keys.

It’s a lot of fun.

When moving you want to have the robot in its lowest height setting. Not only will it go faster, it will be more stable. This isn’t an off road, four wheeling type of robot – it likes smooth services. There is a little bump at the threshold to my office and once the robot has gone over that you want to wait a second or two because it will wobble back and forth a little bit. Otherwise, it does pretty well, and because the rubber wheels are the part of the robot that stick out the most in the front and the back; if you run into a wall it won’t damage the iPad.

I did have to mess with a couple of things. First of all, it needed a firmware upgrade before the external audio speaker would work. Second, sometimes it would keep turning in one direction (in my case, to the right), but restarting the browser seem to fix that.

You do need to be careful driving it, however. One of my guys accidentally drove it into a table, so it hit the table along the “neck” of the robot and not on the wheels. This caused the unit to shoot backward, recover and then try to move forward. It fell flat on its face.

Which, I am thankful, did no damage. The iPad is mounted in a fairly thick case, and while I wouldn’t want to test it you are probably safe with the occasional face plant.

I bought an external wireless charger which allows you to drive the robot into a little “dock” for charging instead of plugging it in. To help park it, there is a mirror mounted in the iPad holder that directs the rear camera downward so you can see where you are going (i.e. look at the robot’s “feet”). Pretty low tech but they get points for both thinking about it and engineering such a simple solution.

Everyone who has driven it seems to like it, although I’m thinking about putting a bell on the thing. This morning I was jammin’ to some tunes in my office when I heard a noise and found Jeff, piloting the robot, directly behind me. It was a little creepy (grin).

I bought it with a nice (i.e. expensive) Pelican case since the plan is to take it on road trips. I bought the iPad that supports 4G SIM cards so I should be able to use it in areas without WiFi. It’s first outing will be to the OpenNMS Users Conference, which is less than a month away. If you haven’t registered yet, you should do so now, and you’ll get to see the robot in action.

Robot Bryan

Bad Voltage will also be there, with Bryan Lunduke piloting the robot from his home in Portland. I had him try it out today and he commented “So rad. So very, very rad”.

At the moment I’m very pleased with the Double from Double Robotics. It’s a little spendy but loads of fun, and I can’t wait to use it for team meetings, etc, when people can’t make it in person. You can also share the output from the unit with other people with the beta website, although you could always just do a Google Hangout and share the screen.

Double Logo

I even like the Double Robotics logo, which is a silhouette of the robot against a square background to form a “D”. I am eager to see what they do in the future.

Case Study: Why You Want OpenNMS Support

I wanted to share a story about a support case I worked on recently that might serve to justify the usefulness of commercial OpenNMS Support to folks thinking about it. As always, OpenNMS is published under an open source license and so commercial support is never a requirement, but as this story involves commercial software I thought it might be useful to share it.

We have a client that handles a lot of sensitive information, to the point that they have an extremely hardened network environment that makes it difficult to manage. They place a separate copy of OpenNMS into this “sphere” just to manage the machines inside it, and they have configured the webUI to be accessed over HTTPS as the only access from the outside.

Recently, a security audit turned up this message:


Red Hat Linux 6.6 weak-crypto-key
3 Weak Cryptographic Key Fail "The following TLS cipher suites use
Diffie-Hellman keys smaller than 1024 bits: *
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (768-bit DH key) *
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (768-bit DH key)" "Use a Stronger Key If
the weak key is used in an X.509 certificate (for example for an HTTPS
server), generate a longer key and recreate the certificate. Please also
refer to NIST's recommendations on cryptographic algorithms and key
lengths (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
) ." Vulnerable

and they opened a support ticket asking for advice on how to fix it.

I had some issues with the error message right off the bat. The key used was 2048 bits, so my guess is that the algorithm is weak and not the key. The error message seems to suggest, however, that a longer key would fix the problem.

Anyway, this should be simple to fix. The jetty.xml file in the OpenNMS configuration directory lets you exclude certain ciphers, so I just had the customer add these two to the list and restart OpenNMS.

And then we waited for the nightly scan to run.

This fixed the issue with the TLS_DHE_RSA_WITH_AES_128_CBC_SHA cipher but not the first one. Nothing we did seemed to help, so I installed sslscan on my test machine to try and duplicate the issue. I got a different list of ciphers, and since openssl uses different name for the ciphers than Java, and it was a bit of a pain to try and map them. I couldn’t get sslscan to show the same vulnerabilities as the tool they were using.

We finally found out that the tool was Nexpose by Rapid 7. I wasn’t familiar with the tool, but I found that I could download a trial version. So I set up a VM and installed the “Community Edition”.

Note: this has nothing to do with open core, which often refers to their “free” version as the “community” version. Nexpose is 100% commercial. They use “community” to mean “community supported”, but it is kind of confusing, like when Bertolli’s markets “light” olive oil which means “light tasting” and not low in calories.

I had to fill out a web form and wait about a day for the key to show up. I had installed the exact version of OpenNMS that the client was using on my VM, so my hope was that I could recreate the errors.

First, I had to increase the memory to the VM. Nexpose is written in Java and is a memory hog, but so is OpenNMS, and it was some work to get them to play nice together on the same machine. But once I got it running, it wasn’t too hard to recreate the problem.

The Nexpose user interface isn’t totally intuitive, but I was able to add the IP address of the local machine and get a scan to kick off without having to read any documentation. The output came as a CVS file, but you could also examine the output from within the UI.

The scan reported the same two errors, and just like before I was able to remove the “TLS_DHE_RSA_WITH_AES_128_CBC_SHA” one just by excluding it in jetty.xml, but the second one would not go away. I found a list of ciphers supported by Java, but nothing exactly matched “TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA” and I tried almost all of the combinations for similar TLS ciphers.

Then it dawned on me to try “SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA” and the error went away. I guess in retrospect it was obvious but I was pretty much focused on TLS based ciphers and it didn’t dawn on me that this would be the error with Nexpose.

It was extremely frustrating, but as my customer was being beat up about it I was glad that we could get the system to pass the audit. While this was totally an issue with the scanning software and not OpenNMS, it would have been hard to figure out without the help we were happy to give.

It may not surprise anyone that a large number of OpenNMS support issues tend to be related to products from other vendors. Usually most of them can be classified as a poor implementation of the SNMP standard, but occasionally we get something like this.

Our clients tend to be incredibly smart and good at their jobs, but having access to the folks that actually make OpenNMS can sometimes save enough time and headache to more than offset the cost of support.

Welcome Costa Rica! (Country 28)

While I have never been able to personally visit Costa Rica (it is on my list) I am happy to announce that we now have a commercial customer from their, making it the 28th unique country for OpenNMS.

They join the following countries:

Australia, Canada, Chile, China, Denmark, Egypt, Finland, France, Germany, Honduras, India, Ireland, Israel, Italy, Japan, Malta, Mexico, The Netherlands, Portugal, Singapore, Spain, Sweden, Switzerland, Trinidad, the UAE, the UK and the US.

2015 OSCON MC Frontalot and Doubleclicks Party

I just wanted to post a short note about tonight’s concert.

WHAT: MC Frontalot and The Doubleclicks
WHERE: Dante’s, Portland, OR, USA
WHY: To give back to our Free and Open Source Software Friends, and to promote OpenNMS
WHEN: Doors open at 8pm, Doubleclicks sometime after 9pm, Frontalot around 10pm

If you are still reading, OpenNMS has been able to get Frontalot to perform at a number of Linux conferences, but this is the first time we’ve been able to bring out the whole band (2015 is shaping up to be a good year). So in addition to the man himself, we have Blak Lotus on bass, The Sturgenius on drums and Vic-20 on the key-tar. This promises to explode with awesomeness.

Since this is Portland, we wanted to get a local group to open and The Doubleclicks were kind enough to join us. They are the sister duo of Angela and Aubrey Webber, who will entertain with their particular brand of nerd folk. I was introduced to their work just recently, and I think it will be the perfect way to start the evening.

We also want to thank O’Reilly for continuing to produce OSCON. In many cases, it is the only time in a year where I get to see friends of mine in person, and they bring together all different type of people from the free and open source community.

Finally, last but not least is Dante’s itself. The venue was kind enough to let us schedule this free event there, and while I’ve never been, I’ve only heard great things. The only downside is that I’ve been told it is somewhat small. Since we are not selling tickets, I have no idea how many people are showing up, but from the feedback I’ve been getting from OSCON attendees, we’ll probably pack the place.

To guarantee you get to see the show, doors open a 8pm, but since some of you might still be enjoying OSCON events at that time, please note that the show won’t start until sometime after 9pm, so we hope you can make it.

Oh, if you do come and like it, please give a nod to @opennms as we are working hard to correct the fact that it is the greatest open source project you have never heard of.

See you there.

Free Frontalot Concert at OSCON Sponsored by OpenNMS

Hey. Lots to catch up on in this post, but the TL;DR is that the OpenNMS Group is hosting a free concert to coincide with this year’s OSCON conference in Portland.

(Please read to the bottom to see how this ties in with the EFF and Ulf)

It will be held Thursday night, July 23rd, at Dante’s, which Google Maps describes as a “Hip, dungeonlike rock venue”.

Map of Dante's and OSCON

Lookie there – we’re “hip”.

The Concert (note how I capitalize it because it is just that epic) will feature MC Frontalot along with his band. This will be the first time I’ve ever gotten to see a Front show with the band (thus “epic”) and I’m really looking forward to it.

And just to throw a little whipped cream and a cherry on top of this huge nerdy/geeky sundae, the opening act will be the Doubleclicks. Yes, you read that right, Angela and Aubrey will be there bringing their unique brand of nerd-folk to the same stage as the man who invented nerdcore rap.

And did I mention it is free? Doors open at 8pm, show starts a little after 9pm.

Plus, for you free and open source software fans, there might be a little extra surprise. Be there to find out what it could be.

Now, the long version on how this all came about.

Chris Dibona once said that his job was to give money to his friends. While our budget here at OpenNMS doesn’t come close to his, I did take his words to heart and we strive at all times to support the FOSS community.

I consider part of that community to be the Electronic Frontier Foundation (EFF). If it wasn’t for the EFF defending a free and open Internet, open source would have a much harder time existing. Usually we give a fairly large donation at the end of each year to support them.

Last year I didn’t. To be honest, 2014 kind of sucked for me for a variety of reasons, and we really weren’t doing well enough to support a donation.

A few months ago I got introduced to Chad Essley. He is the animator behind the MC Frontalot video for the song “Shudders”. While I had yet to meet him, he shared my love of the EFF’s work and decided to auction off some of the artwork from that video and to donate the proceeds. The “grand prize”, if you will, was to have a special remix of “Shudders” made to include some new artwork. Since 2015 is going much better than last year, we decided to bid on that prize and we won, so now I can present the new and improved “Shudders”, which includes everyone’s favorite kiwi, Ulf.

Note that about 1:25 minutes in you can see a pretty accurate rendition of the OpenNMS headquarters.

Anyway, I really enjoyed working with Chad, and I found out he lives in Portland, Oregon. Portland is also the usual venue for the O’Reilly Open Source Conference (OSCON). While OSCON has definitely become much more focused on the latest Valley fads over FOSS, it is still the one place I can be sure to see all of my FOSSy friends each year, so I never miss a chance to go. Now I can add Chad to the list of people I get to see.

Then it dawned on me – why don’t we do a little guerrilla marketing and host a show? Thus after all the swag laden Docker parties are over, people can come by and enjoy some geek-centric music in a cool place.

So I approached Frontalot about doing a concert and, again, since we’re doing better this year, I felt we could spring for the whole band. He agreed, and then used his powers of persuasion to get the Doubleclicks on board. Dante’s is also helping us out, so be sure to come out and buy lots of beer in appreciation.

If you are new to the Doubleclicks, as I was, this is one of my favorite songs of theirs:

The show is open to everyone, so you don’t need an OSCON pass to attend. But I’ll be wandering around the OSCON Expo floor handing out some goodies that are just for conference attendees. I’ll post more when it gets closer to the date, and I’ll tell you how to find me.

I am extremely excited that we are able to do this. It promises to be a great time.

Early/Often on the Horizon

Lots of stuff, and I mean lots of cool stuff is going on and to paraphrase Hamlet I have not enough thoughts to put them in, imagination to give them shape, or time to act them in. I spent this week in the UK but I should be home for awhile and I hope to catch up.

But I wanted to put down a at least one thought. When we made the very difficult decision to split OpenNMS into two products, Horizon and Meridian, we had some doubts that it was the right thing to do. Well, at least for me, those doubts have been removed.

It used to take us 18 or more months to get a major release out. Due to the support business we were both hesitant to remove code we no longer needed or to try the newest things. Since we moved to the Horizon model we’ve released 3 major versions in six months and not only have we added a number of great features, we are finally getting around to removing stuff we no longer need and finishing projects that have languished in the past.

In the meantime we’re delivering Meridian to customers who value stability over features with the knowledge that the version they are running is supported for three years. Seriously, we have some customers upgrading from OpenNMS 1.8 (six major releases back) who obviously want longer release cycles, and even if you don’t need support you can get Meridian software for a rather modest fee coupled with OpenNMS Connect for those times when you really just need to ask a question.

Anything OpenNMS does well is a reflection on our great team and community, but I take personally any shortcomings. At least now I can see the path to minimize them if not remove them completely.

It’s a good feeling.