I’ve thought about this quite a bit.
I think from a practical standpoint, releasing source for any portion which directly talks to UE4 interfaces is really the only option. Distribution of precompiled static/dynamic libs or tool executables which do not use the UE4 interfaces should also be allowed. This is form a viewpoint of someone who used UE3 for 10 years and dealt with plenty of middleware integrations.
The engine code base changes too much for it to really be viable to release precompiled binaries that can interact with UE4 interfaces directly. I’ve thought about elaborate cloud build systems which could build plugins against the matrix of engine versions and platforms, but given how easy it is to modify the engine in a way that would break any precompiled binary it’s just not practical. Even if you can keep up with vanilla Epic releases there will be plenty of game teams which modify one small thing (say, to fix a critical bug), in a way that breaks binary compatibility.
For a smaller developer, trying to build and test binaries against all the supported platforms would likely be cost-prohibitive anyway. I don’t think you will see a ton of people going to this trouble even for static libs containing core algorithms unless its something with a lot of investment behind it (like a big middleware package). Even then source is usually available just at a different pricing level.
That said, I have many concerns before I’d actually release a :
Piracy - This is a real problem, if you’ve ever done a Google search for Unity plugins you’ll find they are warez’d all the time. It’s much easier to tell if someone downloaded UE4, made an entire game, and did not live up to the terms of the EULA than it is to do the same for a . Plus most small devs probably won’t have the resources to really go after anyone who abuses it.
Cloning - Without very good filtering of what gets on the marketplace, I think you’ll see this. You see it on the mobile app stores all the time. With a low enough barrier to entry, someone will try and make a quick buck.
Maintenance - There’s a fairly large matrix of engine releases and platforms to support for any . Small devs may not even be set up to build some of the platforms, let alone test them. Part of this I think can be solved with a “supported platforms” list in the marketplace that’s pretty front and center, but I’ve also though Epic could build some infrastructure here to help developers out. A CIS system that can pull from github repros would not be out of the question - not saying it’d be on Epic to fix anything, just an easy way as a developer to have your constantly built against various engine versions/platforms/etc. I think this would take some of the cost off the shoulders of developers and also result in higher quality plugins on the market.
Pricing - One concern I have is the pricing of the engine will set up user expectation that plugins should be “free”. This could set up a race to the bottom scenario where it becomes impossible to charge what it actually costs to develop a . I think the Unity asset store suffers from this to some degree. A similar flood of poorly supported and poorly implemented plugins in the UE4 marketplace would make it less attractive to a lot of devs. So I’m taking a “wait and see” approach to see how well cultivated the “walled garden” of the UE4 marketplace is.
On the pricing front I have brainstormed various schemes where instead of charging fees, Epic does some sort of revenue share from the backend based on usage. It’s kind of out there and I’m not really sure how you would price it. It would address some of the concerns possibly, but maybe introduce a whole other set of problems.
Anyway, to sum up, if there is a source requirement for plugins, as long as it is limited to the parts which touch UE4 interfaces and allows for static libs for those who want to do the investment, I think that would be fine.