Do you prefer editor plugins with source code over plugins without?

I'd like to know if you prefer buying editor extentions that come with source code over ones that don't include source code, but come in a DLL.

One user wrote he would only buy one of my plugins when it includes source code, because developers seem to abandon their projects eventually and might not update their stuff when a new Unity version comes out that breaks the plugin. Having the source code allows to fix/update the plugin without relying on the developer.

Is this common practice, only buy editor extensions that actually ship with source code?

 

There are plenty of people who will never buy plugins unless they come with source code. What do you gain by only including a DLL?

--Eric

 

For me only with source code. If I pay money for a plugin I want to know what is doing and maybe optimize it for my purposes, furthermore I want to make sure doesn't collect privacy data or does any kind of unethical action not mentioned by their developer.

If don't come with source code I'll look into free alternatives with source code or I'll decide If it's worth it to code it myself rather than spend money.

 

No source code, no deal. Preferably no obfuscation either. If a plugin stops working because it relies on outdated features or if it slows down because of newer faster features, I want to be able to get in there and fix it myself.

 

Same here, without source code I have no interest.

Not because the dev might stop updating, though that seems like a valid concern for some. I tend to think of stuff I buy as "as is", ignoring what might be added in the future, because that did not work out well for me in past experiences.

My concern is that I might have to adapt the code to fit my specific project which is simply not possible without a source. Additionally, I am quite a beginner, so just looking at how something works might help me implement it more efficiently And of course, I feel like I am much more in control when everything is in code, instead of having to do guesswork on a "blackbox".

 

I prefer source code because when latest version of plugin is obsolete i can fix it myself or upgrade it (without waiting for request) if i have any idea for upgrade workflow. In addition its chance to learn new things about programming

 

I prefer source code - though a DLL makes sense from a release point of view (ie: it can be updated without worrying about any code changes that the user may have made).
The ability to update and modify a plugin to suit your customers own needs is a huge advantage over competing plugins - especially as authors can abandon the project or lose interest.

If you're looking to protect your source code by compiling to a DLL, don't bother - .NET dlls can be easily decompiled - and even obfuscated code can be turned back into readable code with a little time/effort.. I know that there are some other protection methods out there, but is it really worth it?

 

I went the DLL way because it's easier to deploy and does not clutter the project with lots of source files. It's not about protection, it's just a plugin, no rocket science.

There are a few reasons why I actually like a DLL more than having the source code in the project:

• The more source files are in the project, the longer it takes to compile.
• If there is somewhere a compile error in the project, it can cause a completely unrelated plugin to stop working, if the unrelated plugin isn't a DLL.
• I like to store resources, such as icons, inside the DLL as well. That will prevent them from showing up in the Unity texture picker.

However, it seems I'm very lonely with this opinion. Maybe it makes sense to provide the DLL as well as a zip archive containing the source code? That would at least keep all the advantages from having a DLL, while people can change and compile their own DLL. But I guess this is not very Unity'ish?

The votes are very enlightening, 70% buy only plugins that come with source. That's good information, thanks to all the voters!

 

Do you know of any Android or iOS plugin that ships with full source codes?

 

The source code should be in a unitypackage. That's what several publishers including myself do when they are using dlls, but still want to provide the source code.

Most professionals I am talking to prefer dlls for the reasons you described, but they also want the source code just in case. Especially the compilation times are an argument for dlls. Although many say they only want the source code, they probably never worked with a huge code base in Unity. No one can tell me that they like it to wait several seconds for the compilation just because they made one small change. It is nice to have the source code in the case that you need a quick fix, but that's it. From my point of view, it should never be needed to have a look at the source code of 3rd party assets.
I would even prefer it if NGUI would be shipped with dlls by default. And I hope that the new Unity GUI will be in a dll. Sure, I also would check the source, especially to understand how it works and how it is supposed to be extended.
I see it also from another point of view. A dll is also a statement to the customer saying: I pass you this black box. It works, you don't need to know the internals. If you want, you can have a look at it, but you don't have to. I made a solid api and maybe a solid editor extension for it, so you don't need to care about it. Just use it!
I also try to make my coding assets in a way that they can be used or even extended simply with the dlls.

Maybe you got my point: I prefer dlls too

 

I include the source in a unitypackage (as Dantus mentioned). DLLs are generally nicer to work with as an end-user plugin, but there's no reason you can't have both.

--Eric

 

Completely agree with that - I'd much prefer a DLL to include in my project over hundreds of source files.

One of the problems (for me at least) is the documentation. I'm not saying that people need to write more/better documentation (I'd expect most people don't have enough time as it is), but there are those situations where you're not quite sure why something isn't working as you expect it to - and having the source code available makes it easier to figure out what's going on and what you're doing wrong.

Another question though: As I understand it, Unity excludes code/scripts from the Editor folder when building for release.. Does anyone know how it handles DLLs? If the UI/Editor extensions are bundled into the same DLL as the API, wouldn't that cause some unnecessary bloat to the file size? And can Unity tell the difference between an editor-only DLL vs game API?

 

@Peter77

You are right but there no reason why cannot be two version at the same time as said as somebody with dll or source. I hope that NGUI have two chooseable version: with dll and source if possible - it most flexible and best option i think

 

Source is pretty important for Unity-side stuff. Not necessarily a deal maker or breaker, but a significant risk mitigator.

For instance, the last editor extension I bought made heavy use of lists, but they didn't scroll, so within about an hour of use we couldn't see what we were doing because it wouldn't all fit on the screen. We could have asked the developer to fix it, and I assume they would have, but that would most likely have taken at least a day or two. Having the source meant it took us 30 minutes.

I've also modified bits of NGUI a few times, not because it was broken/flawed but because I wanted something similar to a thing that was already there, or wanted an extra event to fire or something along those lines, and it meant not re-inventing the wheel.

I don't want to need the source, and I'll try to avoid messing with it if I've got it, but having it is nice in case I need it.

 

I also include source, but as a separate zip file. It makes compile times much quicker and upgrades a lot more seamless. It's also much easier to provide support for a DLL - A user will need to replace that DLL with the source code before they make their own modifications. Also, I don't run into issues where users have old source files that were removed from the package during an upgrade.

I think it is very important to provide source in some form for users who want it, though. In my case, I provide lower priced/free alternatives without source code, but all of my Pro packages include source.

 

Couldn't agree more. But in such cases there is also the support from publishers. I personally have a pdf documentation file, api documentation within a zip file, YouTube videos and several examples, be it scenes or scripts that demonstrate some several cases. Even if I spend quite some time to create all of that and I try to cover as much as possible, I can never cover everything and that's why the support is essential.

It is necessary to split the dlls just like scripts and to place the runtime dll in some place and the editor dll in an editor script. As such, it is straight forward for Unity to decide in the build process which dlls need to be included or excluded.

 

NGUI is unfortunately one of the few packages where I also had to modify the source code. Although it is a fantastic product, at the moment it doesn't feel as if it was made to be extensible. That's why I hope this is going to be improved for the new Unity GUI.
For me the ideal situation would be that there is the runtime and editor dlls for it. And if I create a custom widget, I can do that out of the box. Meaning, I have the dlls, inherit from whatever class to create my widget and then get the possibility to somehow extend the widget wizard with my custom widget. All that without the need to work with the source code, only my widget specific scripts would be accessible in the project. That would be brilliant, but I fear this is out of the scope.

 

All plugins have bugs. Which isn't a problem, unless you can't fix them. I've fixed bugs in Eric's plugins, in EZGui, and others. Unless you (the OP) think you're better than Eric, then you best ship with source code.

Gigi.

 

Noooooooo, you lie, none of my plugins has ever had any bugs! You may, possibly, have encountered undocumented alternative operation paradigms, but NO BUGS!

--Eric

 

Thanks for the info! If I ever change my mind and release my plugins with source code (I think I have to), I do want to follow what most developers/publishers already do, just to keep it simple and consistent for users. So providing source code in an unitypackage was precious information to me.

I have a few questions regarding the source package:

1. Does your source packages just contain the source files, plus all required resources, or do you also include, lets say the Visual Studio Solution that was used to build the DLL?
2. Do you use any additional "magic" when the source gets imported, to make sure it won't conflict with the existing DLL in the project (class name clashes, etc)? Or does your documentation just say to remove the DLL prior import of the source package?

 

I've never had a problem extending it. Having said that, I'm very happy to do it "The Unity Way" and make new components rather than bloat existing ones. A common complaint about NGUI seems to be that there are too many objects/components, but I don't see that as a downside. So my extensions are typically a) making new components, b) adding options to existing components or c) adding extra events to existing components. Of those, a) does not require source access, b) and c) require access to the component source itself rather than the ability to derive from it.

Still, I agree that the best thing for users is to have both so that we can use whatever fits best. If we don't need source access then why bloat our projects with it?

 

My source code package only contains the source files and the resources. I have a custom solution for the compilation, which is clearly not very good. That's why I can't tell you what would make sense here.

I don't use any magic stuff for that. It is not mentioned explicitly. The source package is in a folder named Source and the package also contains the word source. So far, it happened once that someone was confused and didn't know that the dlls need to be deleted.

 

I also think that it is not bad, that NGUI has many game objects and components. Sometimes I have the impression that extensibility was not taken into account during the development. I may be wrong with that though.

 

I would prefer it without because then it takes longer to compile (or whatever).

 

Stupid question:
if the customer want to make a dll himself from the plugin source code, can he do it ?

How much more time does it takes to compile between source code and dll ? Because I have many plugin with source code (no dll) and it took me a few seconds to compile everything.

It's really a tradeof usuability vs few millisecond in compilation.

I prefer loosing 0.1s in compilation time for each plugin, if I can trace, debug, change, fix, understand faster with the source code.

 

If I can't have both, I'd prefer source code. For relatively small projects it's not a problem if there isn't a DLL, but if both the extension and my project is getting big I really notice the compilation time. It feels like an eternity, even if it's only 3-5 seconds

 

The compilation time heavily depends on the plugins. In projects I worked on, it was not unusual that the compilation took 5 seconds, as pointed out by orb as well. Everything over one second feels very slow. If you have dlls, only the actual source code in the project is compiled which helps a lot.
Of course everyone could create dlls from the source code of 3rd party plugins, but for me it is a nice service, because I don't need to care about dependencies, resources and other things that may go wrong during the compilation.

 

Doesn't this depend somewhat on the target platform? In editor compilation is certainly improved and there certainly is a time saver in not having the code compiled into a DLL first, but when deploying to iOS for instance, don't the DLLs get further compiled into byte code to be compatible with full AOT or is that part done by Xamarin and not by the Unity editor?

 

Unity doesn't use Xamarin. Any and all compiling is done by the Unity editor.

Of course. If you can't make a DLL from the source code, nobody could ever make DLLs.

--Eric

 

Sorry I meant XCode... when deploying to the app store. Not 100% sure how that process works with Unity games.

 

With source, every time I'm quite surprised no-one has yet mentioned auto complete/ documentation! "Avoid documentation like the plague" sure does work it's wonders; don't you just love it

DLL's don't include method documentation; you have to actively export an XML documentation file for auto complete to work completely with a DLL. Auto complete is invaluable to new people with your package, especially if it's script heavy, so if you're absolutely going to release as a DLL, don't forget that XML file!

So in my opinion the options are:

- If you must, DLL + XML documentation file (+source unitypackage).

..or..

- The source as-is. If it really does take a while to compile, the user can choose to create that DLL themselves anyway.

 

Most likely, because it's not really important for an editor extension, since no API is exposed usually. If the source code contains comments, it should be fine imo.

 

I know this is a bit of an older thread but as the item on sale today doesn't seem to contain source, I wanted to see what others thought. Personally I no longer buy anything that doesn't have source. As my projects are commercial in nature there already enough challenges with Unity builds and all the various platforms that need supporting I want to limit closed solutions I have little or no control over. While authors may be well intended and even keep the asset well updated, there is little guarantee that they will want the exact final solution that I would want for my project. In fact it is highly unlikely that I would want every future feature or even the features that are already in the asset.

In nearly every case where I've had source code, I've found ways to improve performance, add features I require, and pull out or optimize parts I don't need. On top of it, having the source code can often give you valuable insights on integration and why an end result is the way it is. It's never beneficial not to be able to look into that black box and see perhaps why you are getting a side effect or an unintended result.

Purchasing an asset with source code also some what protects me from having no value at all if I can't use the tool in my project. Often I've had situations where I'll be trying to accomplish a particular task and I'll remember that an asset I had purchased has a particular routine or design pattern that has value. If that asset was just a DLL and I can't use it in my finished game I pretty much have nothing. So that is where I'm at with plygame. I'd like to purchase that asset today on sale but with all the functionality locked up in a DLL I can't imagine where the value would be for me. I never would rely on such a specific feature set to be the foundation for my game... yet without source code you pretty much turn over the future of your game engine if you ever wished to actually use it in a commercial project.

I'm pretty much now where I won't purchase anything without source simply to discourage the practice of DLL only solutions. This asset store is very visible in the Unity community and it is unlikely someone could just steal another developers assets and then republish them as there own. So I don't really see denying the source code to the game developers as a winning formula. If one author is putting out good products, writing great tutorials and supporting the product... they will do fine. By releasing code it does certainly help game developers like myself learn the Unity tool better and make better games. I STRONGLY support full source and vote for it with my wallet.

 

All the people saying "I like to learn from the source code, as a bonus" -- are you happy to pay extra for the source code? How much extra? 10%? 100%? ...more?

You're reaping extra value that wasn't part of the original offering. The developer is giving you some training, on top of the asset. For some packages, they're also giving away some of their advantage to competitors (although IMHO this is uncommon; only a small percent of packages where reading unobfuscated source is a major benefit over simple disassembling)

In general, if every package goes "source included", average prices will rise. I'm not saying that's a bad thing, but people seem to be conveniently ignoring this when answering the question. I'd like to see a poll which asks not just "would you buy with/without source" but also "how much are you prepared to pay for that?"

 

Why would you have to pay extra for something that doesn't cost the author any extra time or inconvenience?

 

I don't mind providing source, but on your same point, do you (would you) sell your games with full source code and the original art files?

 

That depends. You don't sell a game expecting players to integrate it in another game and sell the result to others.

 

True, yet both are still products. Some folks have become a little bit spoiled with the amount of assets that actually do provide source. This is a deviation from the norm in the rest of the software / component world. Source code is often available and often at a steep price.

That being said, I think it's nice when Unity assets provide it because authors sometimes just disappear or platform changes necessitate code fixes faster than the authors can push to the asset store... and if it wasn't for open source, my asset wouldn't exist.

 

You may not expect them to, but they do it anyway. There are some great assets that don't provide source code, such as ShaderForge.... and plenty of people have purchased that asset.

 

When I first released Texture Channel Manager a few days ago, it didn't have source code. But I stumbled upon this thread (before it got bumped) so I've added a zip with the source to the 1.1 update that I pushed. The thing is, I didn't hide the source for nefarious reasons. TCM uses Asset Post Processing and Unity says that should be in a DLL for production use. There's only one other file that does anything of importance and the post processor relies on it, so it made sense to just release the DLL. I never even gave it a second thought. So when you see an asset without source, there might be a reason beyond the developer just not wanting to share.

 

As a plug-in developer, all of this feedback is very useful, and will influence my decisions for my next major release.

 

I did not know a program could function without any source code

 

Are you being facetious? If you had read the rest of this thread, the issue being discussed is fairly clear.

 

You're telling me this is not air I'm breathing?

 

There are no easy answers for this. Many people want source code primarily because they don't want to be dependent on a third party if a major bug is found in the asset during development.

Would I pay more? That all depends on the asset. Do you have any competition? Do they offer source code with their product at the price you charge for no source code? Does your asset have any advantages that make up for that limitation?

Shader Forge was one of the very few exceptions and a large part of that is because the author is well-known for constantly improving his product.

 

My asset requires that it be shipped as source because it is based on compiler directives. However, being open source has also been a great thing. Some of my customers have actually found a couple bugs, fixed them, and then emailed me saying "There's this problem... but here's the fix for it" and I either implemented the fix directly or reworked it a bit and implemented it.

 

Looking at the sales statistics of the last 12 months of Texture Overview (deal excluded) it diverges quite a bit with the poll results of this thread.

Texture Overview sales statistics say:

59% are purchases without source code
41% are purchases with source code​

Other products in the asset store probably have different numbers.

 

For me, as long as plugin works, it doesn't matter if it has sources attached or not. It only matters when I want to either extend plugin myself or fix some bug that I just discovered without waiting for the official fix.