What's better? Sharing Code at the source or binary level.

Question

I've worked on a variety of projects and there seems to be some debate as to what is better. I prefer to only share code on internal projects at the binary level (assemblies in .NET, for example). But I've worked with plenty of people that would rather share code at the source code level. I say that adds too much risk of a breaking change. What do you prefer to do and why?

Update:

To clarify, I was thinking more of when working on internal projects. The code is not released to the outside world, but it may be used on more than one internal project.

Answer 1

I'd say that even if it adds the risk of a breaking change, it also adds the "risk" of an improvement by some other programmer :)

So if it's not for commercial use (i.e. you don't mean to sell that specific piece of software) i definitely prefer sharing sources.

Answer 2

It depends on the what and the why. If it's core code, say a set of sealed business objects, I'm only going to hand out a binary distribution. If it's less critical code and the ability for customization is key, it's going to have to be a project reference to actual source. You can get by with binary if you allow for a high degree of virtual functions, but I question whether or not it's worth the effort.

Answer 3

At work now we deal with sharing code at source code level, because every system got the source of the lib and change it. So now we have at least 4 version of the same code and we try to make it into one again. I think sharing binary is much better and if something needs to be changed they can let you know, its your library.

Answer 4

I prefer a combination. The goal is sharing at the binary level and archiving (revision control) the binaries being used/redistributed. Source-level access is important in diagnosing approach and accounting for issues during debugging.

Answer 5

Correctly-implemented source control will protect you from most breaking changes. As for whether the other developer should be changing your code, that's a matter for policy, not technology.

Answer 6

I think you're going to find that this question will have answers from both sides of the fence. Personally, I'm really into the open source community but I can see points from both sides. Binaries; you can easily make money off of. Source (in my opinion) seems to be less bug prone (not to say that it doesn't have them though). Weigh the pros and cons of both and see what more closely matches the project end goals. As for 'breaking changes', like others have already pointed out, good revision control is the key here. I don't think any developer would argue that.

Hope that helps. -M.I.

Answer 7

If this is for an internal project, I tend towards sharing both the source code and the binaries. Binaries are good because that saves others the time of having to compile your sources. But there's no reason why one of your colleagues shouldn't be able to use your sources for debugging or review your code.

Answer 8

Send binaries when viewing the source isn't import and when recompilation with another project will take considerable time. Send source when you want a code review or when source is important, integration with other tools. Sending source doesn't mean the other person should change things, but it will help them to understand when problems occur, but that is why you have documentation right?