In revision 1554, the src\3rdParty directory was deleted. It was added when we experimentally integrated the Dr. C# addin, but had to remove it later on because it wasn't maintained. What stayed around till that revision was the directory where it lived.

Last week, I had a discussion about repopulating that directory with a third party addin. Various good reasons why to add that specific addin to the distribution exist, but in the course of the discussion (which really forced me to rethink that third party source directory "feature") I found out that having tightly integrated third party addins in our codebase / distribution is no good idea:

• The need to sync the codebase in our src\3rdParty directory with the repository of the actual addin project (which might be developed on a different schedule). This also means that the burden of integration testing is upon us.
• Support issues. If you have an addin that almost perfectly blends into the #develop user experience so it looks like a stock feature, users will report bugs to us automatically. Or post feature requests to us. Users don't see where an addin is loaded from, they don't care.
• Linked to support issues is code quality. We don't intend to review someone else's code if it meets certain standards, less to speak if it hypothetically contains exploitable or even malicious code. A liability issue that we do not want to get into.
• Maintainance. Programmers don't necessarily maintain their addin forever, it might get abandoned. We are then faced with two options - take ownership or remove the feature. Both options are not feasible - for one, we might not know the inner workings at all which makes it extremely time consuming, or secondly, having to explain to users why a feature they (potentially) loved was kicked out.

For these reasons, we decided to remove that directory and continue to stick with our policy: our repository contains only our code (exceptions: non-addin libraries and build tools), and our distribution of #develop only contains addins that are maintained by us. This way we avoid those sticky issues.