Depending on what you’re doing, this is a vast topic with a lot going on, so it’s hard to give a good answer without a lot of detail about what you’re wanting to do. That said, I would like to give a more generic response to the question of what you need to think about when customizing OpenNMS code for your own needs.
In general, step 1 is to fork the OpenNMS git repository, and start making the changes you want to see. Hand-editing already built artifacts after the fact is not a good long-term strategy for maintaining a set of changes against OpenNMS. Despite being a massive codebase, things tend to move fast and we are still doing a lot of architectural changes to refactor our (very old) codebase to be more nimble and modern, so you will find things change out from under you a lot if you’re not starting from the source.
For many historical reasons, the OpenNMS codebase has a lot of strange corners, so don’t be afraid to pop in to the OpenNMS Development chat channel and ask specifics. It can be daunting getting to know our code but there are plenty of folks that can help you out.
If you make changes that fix bugs or add new features, please consider sending us a pull requests with your changes (including relevant unit/integration/smoke tests!) and not just leaving them in your fork. It makes it easier for everyone involved for a number of reasons, not just selfishly from the OpenNMS project’s POV:
- If you have good unit/integration/smoke tests we will catch issues when architectural changes are made to OpenNMS that would affect your new feature. We will do the work of maintaining it for you (although obviously, we would love your coordination/help on things that you would obviously be the Subject Matter Expert for). We run continuous integration on every build and find problems early when there is good code coverage.
- You don’t have to worry about dealing with licensing issues and making sure you make available your customized changes, since the AGPL obligates you to do so even if people are just using your modified OpenNMS as a “user”. Since it will be in the official upstream OpenNMS, it’s covered.
- It means less changes in your fork, which makes it easier to track upstream overall, and you will want to track upstream, since we fix bugs and security issues all the time. Not to mention new features…
Also a thing to note, if you are looking to productize OpenNMS, the name “OpenNMS” and the OpenNMS logo are trademarked and copyrighted, respectively. If you are planning on distributing or posting modified versions of OpenNMS as your own product you will need to change all the branding, just like CentOS does with Red Hat Enterprise Linux.
If you have any doubts or questions at all about how your use of the OpenNMS code base is impacted by the AGPLv3 license or by OpenNMS copyright or trademarks, you should consult a lawyer.
*takes off “community answer” hat and puts on The OpenNMS Group hat*
Finally, you are not in any way obligated to do so, but The OpenNMS Group offers an agreement called Powered By OpenNMS that offers non-GPL licensing as well as support for folks who wish to embed or customize OpenNMS for their own environment. Depending on your needs, you may want to give us a call and see if we can help you accomplish what you’re trying to do rather than going it alone. OpenNMS is big, old, and powerful and we have years of institutional knowledge about how to get the most out of the code and the config.
But in the end OpenNMS is open source and we believe strongly in that. There is absolutely nothing wrong with doing it yourself as long as you adhere to the licensing.