How to open source set of plugins.

Question

(my apologies for the non-specific wording of the question title, and for liberal use of öpen source" when I actually mean "project setup at SourceForge")

We have recently open sourced a 3D modeler we'd been selling for a couple of years, with the main goal of keeping the application alive. We setup shop at SourceForge.net, and are now working towards a process resulting in a steady flow of binary releases. So far, everything is swell.

However, besides the main application, we had also developed a couple of plugins (mainly for different import/export formats). Currently, these are still closed source, but we would like to open those up as well (3rd party plugin developers can take care of their own or donate and open the source). The question really is, should our plugins be hosted as a project on their own or not?

The options I see are:

1. Add the plugin sources into a subfolder of the SVN sources
2. Create a separate project for the set of plugins
3. Create a seperate project for each individual plugin

Which setup is the most practical and/or common, and how should I deal with the binaries?

When the application was still closed and commercial, it was kinda important that the plugin binaries could be updated seperately fom the main application, but now that everything is open and updated frequently, that's not so much of a big deal anymore. Also I'm not sure I want to bother contributing developers with a whole bunch of plugin sources they care nothing about as part of the main project.

Answer 1

1. Add the plugin sources into a subfolder of the SVN sources

   I think that is a good idea if you don't have too many plugins. You could create a folder structure as shown at the end of my answer in order to manage plugins independently. But in this case you won't have fine control over SVN access.

   The advantage is that you only have to maintain one project website (if you create one at all).

2. Create a separate project for the set of plugins

   That's what Notepad++ does, for example. Their plugins are hosted on a separate SourceForge project. Having one download page full of plugins and another download page full of binary releases of your software improves readability. But don't forget to mention on the project web page that there's a separate plugin project.

   It also has the advantage that you can manage the project web sites independently. For instance, you could put other users in charge of caring about the plugin site (if you find somebody who wants to maintain them).

3. Create a seperate project for each individual plugin

   Not a good idea, maintenance will be harder this way, as you'll have multiple projects, repositories and project websites.

   But it has an advantage though: You can be more fine-grained in granting people access to developing the plugins. For example, users A and B are allowed to work on plugin X, but not on plugin Y. With separate SF projects, this is easy to achieve. Same applies to the project web sites, of course.

---

So, as a conclusion, I would say that the more you care about SVN access rights and the more plugins you have, the more it makes sense to create one or more separate projects for your plugins.

---

Example SVN structure from #1:

/modeler
    /trunk
    /branches
    /tags
/modeler-plugins
    /plugin-x
        /trunk
        /branches
        /tags
    /plugin-y
        /trunk
        /branches
        /tags