FWIW, I would prefer oak to have better modularization. It also overlaps with Michael Marth's other recent thread "On adding new APIs" - the exported APIs in Oak are all ad hoc because of it's monolithic design (i.e. all in oak-core) and no clear API packages designed upfront. Someone had to figure out what packages need to exported after the fact, and a lot of things are exported that should really not be, and because of that, you have to update a lot more oak code when something changes in these, because it inadvertently depends on these exported classes, although it doesn't use them.
Building a patch for Oak to try something out as an outside is very difficult, as things aren't well modularized. I was recently involved with oak-auth-external, and you can only really work on it if you always rebuild and redeploy the whole of oak. It's pretty painful… builds are also slow, as because of the snapshot dependencies you have to build everything which takes a lot of time with all the tests. With released dependencies between the modules, one could work on a higher level module without worrying about the lower layer, as it stays in the same released version. I would argue you might get more contributions if things were easier on this front. Releasing modularized stuff can be easier: if there is only a change in one module, you only have to release one, instead of all of them. Faster turnaround. A Just my 2 cents, Alex
