Open source and company specific features

[Steve Milburn]

Hi all.

I developed an application that deals with tracking K-12 student progress on standardized benchmark exams with respect to defined performance standards. I'm considering open sourcing the application to allow other to use and contribute to the source code (there has been some interest expressed already). 

There are a few parts of the application that are so specific to our needs that I can't imagine any other school district would use. I'm curious how to best manage these areas of the application. The 2 options I see are to include everything and other developers/users would simply ignore the stuff that they will not use, or to open only the main functionality of the application and maintain a private repo of the stuff that will most likely only be used by us. I'm leaning towards option #1.

Anybody have any input on this? I'm new to managing an open source project so I'm wondering what others who may have had the same issues/concerns have done.

Thanks!

Steve

[Denard Springle]

Hey Steve,

First off... thank you for considering contributing your hard work for the rest of us to use and improve upon. It is greatly appreciated.

There is a third option - two branches. Master branch would contain all the common code, and a secondary branch could contain all the code you feel is specific to your needs. This gives developers the opportunity to get/contribute to the master branch while ignoring (if they don't need it) the secondary branch. For those that want/need anything in the secondary branch, they can go grab that branch.

In either case, #1 is easiest to maintain. #2 is likely to leave dependencies in the repo that do not exist (because it is part of the code you keep private) and would require more testing to ensure you don't do that. My option (two branches) would also have to be tested for dependencies, but would be a more trivial task to address since the code is still available in a secondary public branch.

And in final note, be certain you a) have the permission of your client/customer to open source any code written for them; b) make sure you don't check in anything customer specific (e.g. sanitize the code to eliminate keys/passwords/other hard-coded data specific to the customer); c) choose an appropriate license, and d) if electing the two-branch option, make sure you include details of the secondary branch, and it's purpose, in the README.

For TCFA use, make sure you've signed and returned the TCFA Contributor License Agreement (https://s3.amazonaws.com/tcfa/Team_CF_Advance_CLA.pdf) to us (you can still send those to me directly @ denard....@gmail.com) and let us know when have the repo set up and we'll fork it for TCFA (I'm assuming you're going to use GitHub).

Hope that helps!

- Denny

[Ryan Mueller]

Other idea to consider is making your app plugin friendly. Then you can have the general app and your customized client code in different repos all together.