State of the (implemented) art right now is the N2K-->0183 converter.
And as you stated one will need a piece of hardware
and software to connect to the N2K bus.
Of course the native use of N2K would be a "nice to have".
This makes only sense though when data beyond those defined in 0183 would be used in OpenCPN.
A lot of those are non-navigational data (engine, battery
, switches ...) so N2K would be more appealing within the scope
of OpenCPN if for instance a more general version of the dashboard would be in place. An implementation perhaps that can deal with arbitrary data - data not previously know to the program, pipelining those between the different parts
of the program (or plug-ins).
The other point that is needed in the context of N2K is dealing with the existence of several instances of a device - we have something in that direction with the priorities for data sources in the new COM implementation, but in the case of N2K this has to be more general.
So we just need somebody who has the skills, time and motivation to tackle this
. CANusb.com is giving already a great kick-start on the part of the N2K protocol I believe.