In the end, the reason people use languages/standards like UVM is productivity.
The highest form of that is reuse.
So: whatever you do, it needs to enable IP creation and reuse more than all other existing standards.
And of course, it has to enable re-using existing IP created in those standards.
So: here are some ideas:
1) The .NET library is huge, it has an open-source equivalent called Mono. There's of course a huge number of programmers who know .NET/Mono, who are available, competent and far cheaper than HW designers. So add a Mono interface onto SV and VHDL. Then more verification can be done by those SW engineers.
2) Create a big package of standard tools for the checkout/edit/regress/merge/checkin cycle, using open-source tools: sveditor, Jenkins, vunit, svunit, and include any open-source tools/standards for tracking defects, functional-coverage results, etc. This doesn't sound sexy, but if your goal is to help people, providing a set of tools that are setup to work together, and have a nice configuration-front-end, you'll be a big help. Have hooks for both Git and SVN. Have built-in support for branches, so it's easy to do them.
3) Create a set of IP-XACT vendor extensions that support UVM, so that UVM info can be captured. Example: in IP-XACT it's all set to capture RTL info, and has support for capturing script flows, etc. What's missing is the ability to say: "BusDef AXI, version 1.5, is implemented for using UVM with package axi_1p5_pkg, and SV interface
axi_1p5_if.sv, etc. And then describes how to wire up the UVM-SV Interface to the bus. For predictors, the equivalent would be to describe each of the ports (ae/ap) on the predictor, the type of transaction each uses. This would be part of the IP-XACT info stored for the RTL IP. Then one could generate a UVM testbench for the RTL, using whatever UVM testbench approach one wanted. Or, let's say that one had two incompatible predictors (two different vendors), one could have the scripts generate a subscriber to translate between the two transaction-types.
4) take one of the existing graph-capture tools and enhance it so it captures the required info for designing a UVM testbench: agents/predictors/scoreboards. I'd suggest using IP-XACT to store the info about those UVM objects (see above) so one could allow users to create valid testbenches. Alternatively, use an existing schematic-capture tool: old-school "buses" in schematic-capture tools are equivalent to UVM ap/ae. So not a lot of work there.
5) If Icarus Verilog (just to pick on a tool ) were enhanced to have DPI, then one could do all kinds of object-oriented verification using SystemC/C#/Java/Ruby or whatever you want. This greatly expands the pool of available, talented implementors. And of course it would all be *open source*. The only thing needed would be CPU-cycles, and the prices for those are always going down. Yes, Icarus is dramatically slower than vendor tools - but a hundred Icarus licenses in parallel, running a regression suite, is going to finish faster than a few vendor simulator seats running the same suite. And be far cheaper.
6) Take a look at the new Eclipse open-source work for capturing embedded-software requirements. So far, everything I've seen says that one could take the generated code and co-simulate with the RTL. Now, if that RTL were described in SystemC, no simulator-tool would be required. And those same tools, if one added a symbol that indicated a register, could be used to actually graphically capture RTL implementation.
I'd not "take on" UVM - I'd leverage off of it. Fix the problems that UVM doesn't address - and never will.
Just some thoughts...
Regards,
Erik