Good to read this because I’ve already promissed to release my game’s source project for modders on Steam when I publish next year.
Of course there will be terms of use and I won’t ship UE4’s source code within it; I expect them to pay the $19/month if they want to mod the game.
Another vote for what Ufna said.
Another option is to provide for separate source code license pricing, where one price gives you just the binary (or UE4 related source code plus binary libraries) and another gives you full source code.
well, the pricing should always be decided by the one selling the product, eh?
I totally support the idea of clear identification with labels.
From my personal experience, small to mid-size companys will always prefer to buy stuff where they get the source code. Why? Because if you have to “fix” something or change something a bit to the way you would like the Software to behave, you don’t want to be dependent on the developer (in a time consuming way). It is much easier, faster and thus cost-efficient if one of the in-house developers can invest a few days to alter the code to work like desired instead of contacting the developer and probably waiting months for the feature request to be implemented.
Just to give those people who are of the conviction that keeping their stuff a secret will actually increase their sales.
But we should never force someone to provide full source code, for some companies, mostly those ruled by lawyers, that will not be possible at all 
Personally I’m not a big fan of allowing closed source plugins if there will be a source provided option at all - if there are, we end up with the same drawbacks of other systems, where functionality goes largely unmaintained, and plugins die and drop off the map quite often. And while I’m sure there would be a decent amount of both types, it kind of makes the distinction a bit useless.
That said I understand peoples’ position, though I’d be fine with even something like no closed source plugins, but closed source plugins may be featured in the marketplace from time to time or some such.
Closing the source for a static library brings its own issues - namely a debugging headache if anything should fail inside the library, and in turn, a support headache for the author to figure out what happened. It also largely presents the same drawbacks as entirely closed source plugins (minus engine-integration maintenance, which is good), namely that the can go unmaintained and thus die off quite quickly.
The other thing is that providing source makes it a lot easier to have a community maintained support pipeline, which any developer of middleware knows is the biggest source of time spent not developing your actual product. With a closed source product, you are pretty much on the hook to provide close in support no matter what.
I still think those that want to keep their source closed would do just fine selling outside the marketplace. If your source is the result of years of R&D, sure, keep it closed. But by that same token, your advanced code should be enough of a draw that the should sell itself. If it’s really that good.
Further, I’d prefer not to use closed source plugins just because I may need to integrate that system with others the author(s) never knew about, and there is zero of that happening with multiple closed source plugins. So it’s a real turn off in terms of wanting to buy a if there’s no source, because I know
-
support will be a hassle no matter what, even if the author is attentive,
-
I can’t debug it myself,
-
I can’t integrate it with other systems if need be,
-
I don’t know if the author will even be around in a year, or if the will survive, and I won’t be able to update it.
Just my two cents.
Edit: Also, source provided/available is a lot different than open source, and I think that’s what we’re all talking about here (source provided, not open source as in FOSS licenses and such).
I think that plugins should have their source be part of the purchase if possible. In my opinion the pros outweigh the cons.
At the moment lifetime access is exactly one of Epic’s marketplace requirements, so putting it on the marketplace invalidates this argument. As for reselling or redistribution, I do not think it is a big problem, plus piracy cannot be stopped even by the most restrictive of DRM systems. It has been proven time and time again.
If you offer a product for money it should have a certain quality. I know that a lot of things that are being sold do not, but since the Epic marketplace already has rather high requirements for assets I see no reason why it should soften them for code. If you hate the idea of other people seeing the code because it is ugly, then you should clean it up.
I also agree with n00854180t’s arguments and that distributing code with the is not / should not be equal to open source. It should only be redistributable in form of the binary/game in which it is used. However there remains the question about using thirdparty libraries in the . Sometimes it might just not be possible to distribute all required source, so maybe the label system is a good idea.
greetings,
FTC
I think the plugins should have the source public, but of course with proper management so people dont rip off, some license or similar.
My opinion is that if source is availible, the client can add things to it or fix a bug without having to bother the developer. I allways give the code for everything i develop for people, and of course i take my time to clean it up and comment it a bit, so they can take a look and understand how the systems work, that way the risk of them calling me to update or fix a very very small bug in the code are slim.
As a primary buyer/user, my preference would be open source and, should an author choose to make their full source part of the Marketplace package, it would be a +1 from me in terms of buying it. Much like Unity and say, Ultimate FPS or ProBuilder. But if making full source a requirement prevented certain authors from working with Unreal Engine 4 due to “license restrictions”, and it almost certainly would, then I’d be in favor of allowing closed source as well.
I really enjoy working with Blender, but it is my understanding that their GPL license really torpedoes a lot of non-Blender compatibility. (Sorry, I’m really in over my head here - may not be 100% on target) It seems to me there’s a fair amount of people, especially in regards to the Blender Game Engine, who see the license and say “No thanks, we can’t do that.”
I don’t want UE4 to miss out because of license issues. All that said, I do think the argument that “UE4 is open source, so the marketplace content should be as well” has merit too. I’d probably support the idea of a clearly labelled ‘closed source’ / ‘open source’ on the description, and would probably buy from both. Forcing the user to go directly to the author’s website cuts Epic out of the revenue loop, removes some of the protections that Epic and their license offers, and potentially forces me to jump through hoops to keep everything managed rather than being able to do so through the marketplace.
Not to say I’d never buy directly - I did with Unity plugins a few times - but my preference would be to use the marketplace for the majority of purchases.
Plug-ins are an awesome feature - though their complete mechanisms are in flux - their openness and flexibility dramatically set Unreal apart from its competitors. Epic should capitalize on that and allow lots of variety – provided it mitigates any headaches for them or the users.
Our plan is to make the source for our plug-in run-time available for some or all levels of the plug-in - maybe even the free Standard version. [Not an easy decision since is the culmination of 20 years of effort.]
Traditionally in the video game middle-ware world there are different levels (and different prices) of tech where the lower prices do not include source and the higher prices do include source. Epic and its new subscription model is fantastic – though not everyone may opt to follow their lead.
The big guns like Havok, Audiokinetic (Wwise), etc. obviously have their own agreements, online stores, etc. and prices upward $500K and beyond for a single product that includes source availability.
However ease and eyeballs are important and if the Epic Online Marketplace can attract the full gamut of hobbyists, indies, and large middle-ware vendors then why not include them?
Plug-in Source Availability
This sounds like a good idea to me:
A fair definition of UE4 integration would be any code that depends on / includes UE4 code. This may often be the glue code though it could be more – especially if there are sophisticated Editor tie-ins.
If it were an option to make Epic a trusted partner to privately hold otherwise proprietary source that can be recompiled for new static lib / DLLs for new releases and different platforms – that could allow Epic to automate versioning and give alerts if things don’t go smoothly for a plug-in when there are engine changes or platform additions. Not everyone would necessarily go for it though it could streamline things for those who do.
[On my last big game project we actually used (wink, wink) to automate build smoke tests to ensure that all checked-in changes - code, content, anything - would build properly on all our target platforms then run a series of scripts to ensure that various scenarios could be completed without crashing / hanging before they would be accepted.]
Here are some related concepts affecting including source with plug-ins – how they are labelled, grouped and licensed.
Labelling & Tags
Good optional and required labelling/tags – and related filtering / searching is essential. Also if Epic does some gamification of tags there could even be tags that are only awarded or earned from Epic, users or other metrics.
Example tags:
- Plug-in tags: Editor, Runtime, Full Source, Separate Download Required, Demo, Feature-Limited Trial, Time-Limited Trial, Newer Version(s), Older Version(s), Dependencies (on other Plug-ins or content – if allowed)
- Help tags: Video Tutorial, Step-by-step Guide
- Content tags: Fantasy, Sci-Fi, Present Day, Non-Photorealistic, Cartoon
- Pricing tags [not that all would be supported]: Free, Sale, Subscription, Per User, Per Project, Upgrade Pricing
The tags should be very clearly defined and ideally many should be added / generated automatically as part of the Marketplace submission process.
Allow variety and ensure people know what they are getting.
Grouping - Single Entry with Multiple Options or Separate Entries per Option
Good question would be – what is easier / better – separate plug-in entries (with different capabilities or options like source/no source) with different prices or single plug-ins entries with several different add-ons / options for different prices. In general, separate entries for each version would be easier for Epic to initially set up though could create a lot of future clutter.
It would be great to at least link related plug-ins like a trial/demo/limited version ($0) and a pro version ($$). However it might be nice to rate and comment on them differently. Perhaps different options for a product could be separate entries though if they have a link to related entries then the Marketplace Launcher could visually group them and connect them in other ways?
As the Marketplace gets more populated, company pages could be nice to group products too.
Being able to get old versions of Marketplace products is probably essential. Once a production is up and running it sometimes doesn’t make sense to get the latest shiny thing every few weeks. That being said plug-in vendors and Epic will want to make upgrading as effortless as possible.
Plug-in Licensing & Pricing
The licensing and pricing available to plug-ins could have a big impact on the inclusion of source and the attraction to small and large studios.
The current licensing conditions with content - https://www.unrealengine.com/marketplace/marketplace-business-terms-faq - are pretty clear.
Given that plug-ins aren’t open for submission yet – let’s assume that their licensing / business terms are also up for discussion.
Some possibilities for rights of usage for a plug-in (who can use it and on what) can range from the following (probably even more possibilities):
- whole team/company or single user/seat
- any product, product-line (product and its sequels), or single product
- perpetual license or time-limited
- single payment or subscription
- royalties: none, percentage (capped), percentage (uncapped), etc.
- [other schemes]
There are lots of variations. Obviously Epic may only be able to or want to support some of these.
One important aspect that is critical is the ability to scale to the buyer – for example a larger price point for a larger studio with more expected support. Single seat and royalties can scale in this fashion. There could also be packs / bundles for large studios that they could buy separately from standard plug-ins.
Sure, all variations not supported by the Epic Online Marketplace could be done via a vendor’s own site - though if it could be done to the mutual advantage of Epic and the vendor then ideally it should be in the Epic Marketplace.
Single payments for lifetime use by a whole team on any project is obviously the simplest licensing and pricing to provide. However even Epic has a per user / subscription / with royalties model. It seems reasonable that plug-in vendors may want the same sort of options.
Ideally no vendor large or small should feel the need to hold back adding their plug-in to the Epic Marketplace.
If Epic one day makes the majority of their money via their Marketplace that would obviously mean things are working and be a win for everyone.
Nice post Noolarch!
As an author I would love to have an automated build system so that plug-ins so that I only have to test the binaries for each release.
As a buyer I would prefer to buy binaries compiled by Epic, which could offer a layer of security / confidence.
Personally, as both a dev and a purchaser, I don’t mind the approach you’re talking about @Noolarch, but I also would give favor to plugins with full source, and which will have a license similar to that of the content license (one time purchase, unlimited titles). I’m not sure how I feel about seat licensing. I think it tends to be annoying much of the time, but would probably be fine for plugins with source, since presumably there won’t be a ton of hands touching source anyway.
I understand things like a whole script engine being closed off - that’s alright by me, but for smaller plugins…eh - I’d also expect a higher level of support for any closed-off portions of the source, since when something goes wrong I won’t be able to fix it myself (not to mention issues with versions being maintained, long term usages etc. where full source is essential).
I’d prefer not to deal with tiered packages and stuff, beyond a simple split between indie/hobbyist devs with a certain revenue cap per year (like $100k/yr) and AAA and bigger indies which make more than that. I definitely think it’s fair to charge those larger companies more for an unrestricted license, of course.
Overall though I think it should be kept simple… not a lot of tiers or splits between pricing models etc, and a clean simple to use license.
Obviously though some of that will be up to the developer and I imagine more complex and tiered schemes will be supported, but the above is my personal preference and where I’ll be putting money towards.
Sure - that is why I suggest appropriate tagging of things too - ensure people know what they are getting.
I prefer simple mechanisms too. However I’d like to ensure there are mechanisms that encourage awesome AAA tech can be made available to indies. I’d argue that is why Unreal 4 is available - per seat subscription with (small) royalty - makes it something that indies can swallow and the big studios and big successes can still reward Epic. [Yes there is separate console licensing too.]
I just want to ensure that the Unreal Marketplace can work for both indie and AAA as buyers and as vendors.
Sure, I agree with that.
It’s a touchy subject because of the nature of the engine and working with it (and it’s source) but source distribution of /module code should be an option, not a requirement. Intellectual property and privacy concerns are key in this matter. Epic choosing to distribute source to it’s customers is their own decision (and omg thank you so much for that decision!!!) but our own business models should not have to reflect theirs. To be honest, I don’t personally even like the idea of external language bindings being required to be open-source because it pretty much negates the possibility of someone making a viable business venture from providing a proprietary binding to UE4, however I can understand this limitation because there would be nothing stopping someone from wrapping the entire engine and marketing it as their own with UE4 binaries linked against it.
A is a piece of software and should be treated like any other product developed with the engine (games, assets, etc) and source distribution should be up to the provider, otherwise, how else are we expected to protect our intellectual property if we desire to do so?
For those worried about developers not keeping their plugins up to date or waiting for them to provide an update: That’s the nature of the game. Choose your vendors wisely. If source distro is forced, there will be a lot of vendors opting out of selling on the market place and that doesn’t only hurt them, it hurts the community because the marketplace is the official spot to find things and some of the best will be closed source. That’s just the way it is.
Wow how did I miss this for so long! Good thread.
My 2 coppers:
Flexibility is key. While I personally release all my plugins as free and open source, there is a significant portion of authors who would only contribute to the marketplace if their secret sauce is protected. Encourage but do not require.
Requiring glue code to be open source but having a well-defined way to wrapping up private code in a static lib would be the ideal compromise. Some plugins may also require external downloads (due to licensing) so any way of helping to accommodate that (via say a common downloader) would be advantageous. Also as mentioned earlier in this thread, having good tags will allow for customers to know exactly what they’re getting.
At the end of the day its all about minimizing customer burden in any way possible.
Strongly against forced open-sourcing code plugins - revealing proprietary code, algorithms, and techniques should not be a requirement to participate in the store. It’s like asking every game to be open-source… you’re dealing with companies that have taken risks and invested time and money into a product. They don’t want to give their hard work away just because some people think open-sourcing is the only real option (and who are often hobbyists without much concern for products and their risk/reward - to them, open sourcing has no downside).
I like the ‘Open Source’ / ‘Closed Source’ tags - it works for both parties in as many cases as possible.
EDIT: Not that I’m saying that hobbyists’ opinions don’t matter! It’s just that there’s more to it than personal beliefs 
Sorry if the above sounded mean.
HD, keep in mind that C++ DLL compatibility rules mean that any code that links to UE4 must be recompilable from source, else it will be incompatible with code changes made by any developer who alters base classes like AActor, etc. If a developer were dependent on a whose UE4 binding couldn’t be recompiled, that would fundamentally break the entire UE4 source code development path for them.
So, the issue at stake isn’t whether or not a given ships with source, but whether that breaks the entire UE4 source development path for developers who use it.
Thus the expectation of requiring source for the portions of a plug-in that link to UE4 while any engine-independent code may remain closed source.
That point here that made to me makes this a pretty open and shut case because you can still protect your IP interests. The only “open source” part here is whatever surface area the and engine have. Epic would have to be better at deprecating public facing APIs (instead of removing it outright which has happened) to ensure that the source still worked between releases. I wrote the RadiantUI framework and I thought my support for handling arbitrary polygonal meshes for UI interaction was pretty neat. During the time when I was selling it if I’d really wanted to I could have isolated that part of the source in a separate library.
I encourage Epic to adopt this since it really does alleviate a significant issue and over time it will become a major thorn that could stunt the viability of marketplace plugins. As an Epic customer if my project breaks during every upgrade or I have to wait for weeks for a half dozen authors to catch up it can get frustrating and lead me to avoid using them in my project. I don’t think Unity’s marketplace would be as vibrant if they had this kind of issue. It’s very nice to be able to move through Unity versions fairly smoothly in-terms of third party compatibility.
Ahh I can’t believe I missed that part - reading over the thread a bit more makes it pretty obvious. Sounds great.
Yepp, you’re right - that does make sense.
Sorry for the confusion (on my part). Looking forward to developing some code plugins
Well, think again. It happens all, aaalllll, the time. But Unity’s marketplace is so large that people quit jobs when selling plugins that are well received there. Thus fixes are pushed very fast;
However I ensure you none of a dozen plugins I’ve done for Unity 4.5.x are working 100% on 4.6 and also barely work on Unity 5 if at all. I can’t keep investing time on them anymore so I’ve made them free for 4.5.x users. If they want a fix they do itself because source is all there.
And, well, I can only speak for myself; I won’t ever buy anyone’s for UE4 if it is closed source.
I already regreat I paid for RadiantUI
As someone who has released a and actually wants to do more (and I’ve purchased assets to this effect on other development marketplaces) I’d only really ever touch a without full source-code if I was desperate for that feature. Even then, I’d be wary unless the developer was clearly active in development.
My take is that it only has value if its future-proofed with sourcecode and the added value is that you can update functionality or extend it if you have source too.