drbowen wrote on Wednesday, April 05, 2006:
" To be honest I have never used Open source code before, I have always written my own and not really sure what I am allowed and not allowed to change or post. "
You are free to release your additions back into the source code. We ask that you submit your code for review by one of the current active developers (Rod Roark, Andres Paglayan, Tekkno Genius, etc.). The main purpose to check to make sure that your are being consistent with our current coding standards.
We also want all contributions to be made under the same type of licensing. It would be nice if you start your code section with your name and contact information, followed by a specific statement that you are releasing your contribution under the terms of the Gnu General Public License.
(GPL for short).
If you make some contributions, and the current developers are convinced that you are not unintentionally introducing bugs, then they can and will extend direct commit privileges to you.
The reason I made the statement about “Don’t do all this work on something you don’t intend to use in production.” is that I know human nature. They great majority of OpenEMR users are small offices that do not have professional IT support. Getting everything installed and working correctly is somewhat time consuming. Most physicians are not going to have the patience for this.
If you ARE a professional IT support admin, then the more cautious install on Windows XP Pro, makes sense. The reality is that installation of OpenEMR in the webroot doesn’t affect the function configuration of the server at all. It can be added or removed with impunity.
Installing Apache, MySQL, PHP and PERL do affect the server configuration but already have long track records of security. Installing these do affect security to some degree but patching your server for security on a regular basis helps minimize this type of risk.
So my recommendation about going about this on your live server has been reasoned out. I think it can be done with minimal security risk to the server. Plus there is nothing quite so frustrating as getting everything working great on a slow test machine and then turning around and not being able to get things working on the main server. (been there, done that)
Sam Bwoen, MD