Duplicating code is never good.

So, what does that mean? Well, in the most general sense, it means that ignitionServices is not a good thing to have. I have to basically rewrite everything that other services out there already do. Not a good thing. What if I could just take the other services, compile them for ignitionServer, and go from there? Sounds like an idea? Read on...

I'm planning on making custom builds and interfaces and such for Anope services. I'll package it as ignitionServices NG (which means it'll be sort of like a fork of Anope, although we'll sync with Anope regularly), and throw some UI tools in there (if at all possible, I'll use GTK+, so the Linux community can benefit from the tools, although, this is probably not that likely).

What does this mean to you?

• When ignitionServices NG comes out, it will not be compatible with ignitionServices
• There will be hundreds and thousands of extra features that the Anope team has worked very hard on. Instead of barely working services, you'll have a fully-fledged IRC services package.
• ignitionServices NG will make sense to the "I don't like config files" people -- we're fully intending on throwing a user interface on it. Similar to how we're putting a UI on ignitionServer.
• ignitionServices NG should compile on Linux and Windows, so when ignitionServer NG comes out, ignitionServices NG will fit right in
• Anope security updates will have to be applied to our "fork" seperately. We're not keeping a fork per se, because the code will be identical. We're changing the branding, changing default compile-time settings, and we may need to add some hacks so it works with ignitionServer. We're also packing UIs and installers in the same repository (like we do now). We'll subscribe to the Anope announcement list and get security updates out there as fast as possible. We'll also submit any hacks we need to add to the main Anope developers.
• Did I mention the services will no longer suck? ☺