On Modifying Open Source Projects
Posted on Feb 06, 2007
Michael Dinowitz started a bit of a debate with a couple of posts lately regarding what he did to Mach ii to improve performance (you can also hear some discussion on this week's ColdFusion Weekly Podcast). What I am interested here is not the specifics surrounding duck-typing a framework's core files, but rather the "etiquette", for lack of a better word, of modifying open-source project code. One of the benefits always touted regarding open-source is that you can modify the project to your heart's content, but just because you can, should you? In most cases, the answer is an emphatic no.Reason 1: Modifying Core Files Breaks Upgrades
Ok, this is the most blatantly obvious reason you would not want to modify the core code of most open-source projects (particularly frameworks) and that is that you make upgrading a nightmare. You might say that you are content with that as you don't see the need to upgrade for new features. However, should an important release come out that fixes a security vulnerability or a memory leak for example, you are now forced to evaluate and transfer those changes by hand, line by line in many cases. Most open-source projects are on a continual release schedule (or at least those that have releases at all), and for this reason alone I think you would not want to tamper with the core files.
Reason 2: You Limit Your Access to Support
Most open-source projects don't have formalized support, but rather informal support through blogs, mailing lists and message boards from both the project developer(s) and the general user community. By tampering with the core files, you have created a scenario whereby you are severely limiting your ability to benefit from these sorts of discussions since your copy does not necessarily behave the same as the one being discussed. You also are very likely to end up reporting erroneous bugs, thereby wasting your own time and that of the developer(s) or anyone else who chooses to try to help. Sure, you can hack your Xbox 360, but don't try sending it back to Microsoft should it break - even if the reason for the break has nothing to do with your hack.
Reason 3: It Is Not Always Clear Why Things Were Done a Particular Way
This applies particularly to frameworks but also generally to most open-source projects. The reason behind some of the code and architecture decisions that went into the project may not be apparent to those not involved in making the decisions. Most of these issues have been tested in a wide variety of scanarios and environments by a combination of the developer(s) and the user community. In the end this may cause you to make modifications without being fully aware of the implications and put your application further at risk of failure.
This Is Not a Moral Judgement
Before I get angry responses, I am not saying that there is anything morally or ethically wrong with editing the core files of any open source project (even a framework), just that any such decision should be very carefully considered (for the record, I am certain Michael is well aware of the issues discussed here and this post should not be construed as a judgement on his decision). In my opinion, there are very few cases where a change to the core of any project is warranted.
The major exception is, of course, if you find a bug or an obvious improvement, be sure to report it along with the code changes you recommend (in many cases you may want to consult with the developers via the mailing list *before* you actually implement the change).
Any thoughts or differing opinions?
(oh and just a couple of notes of follow up: small utility type projects can generally be limited enough in scope and complexity to mitigate some of the concerns I express. Also, it should go without saying that I am not covering areas whereby portions of a project are designated as customizable sections.)
Comments
I agree with your comment that there is nothing morally wrong with modifying the core and even posting the modifications and why you did it but using the word "etiquette" might suggest this is a "social faux pas" which it really shouldn't be (anyone who doesn't want their code messed with publicly shouldn't be releasing OSS IMO).
At worst you look foolish but learn why things were done differently when the core committers comment on your blog and at best you improve the framework as the core committers slap their heads and wonder why they didn't think of that (rare, but not *completely* impossible).
As to the practicalities of modifying the core of a framework and then using that in production I think you nailed all of the high points. I can't imagine doing it myself unless I just wanted to snarf a snippet or two for a custom framework and I'm with Matt on the podcast when discussing Steve's talk. Why rebuild a framework from scratch when there are great ones out there (there are good answers to this, but only for pretty special use cases).
Posted By Peter Bell / Posted on 02/06/2007 at 9:09 AM
at the very least, i'd like to go in and look around. see how things work. mostly as a learning experience.
but if i -did- see something that i thought could be improved upon, i did want the ability to make the modification without being shunned :)
but a couple of points to make...
1) if i saw something that i truly felt could be made better, i'd probably submit it to the owners of the project for consideration for submission.
2) if it was something that i personally felt very strongly needed to be in the code, and step 1 didn't work out so well for me... well, i'd probably go ahead and make the modification being full well aware that i'm limiting what i can expect in the way of support from the community, as well as being full well aware of the fact that come time to upgrade, i might face some issues that others won't.
i'd -never- modify the core files and expect that any of the owners of the original code owe me -anything- in the way of support once those modifications had been made (not that i think i'm owed anything anyway... but making a modification, no matter how small, effectively severs -all- ties).
i think that if people are willing to accept that caveat, then they're free to do as they wish with the code.
Posted By charlie griefer / Posted on 02/06/2007 at 9:23 AM
Now you had to go throw this in there to ruin my only comment while reading this. :(
Posted By todd sharp / Posted on 02/06/2007 at 9:26 AM
Reason 4: Use Your Time Doing Something More Useful
Maintaining a private version of an OSS project takes time. Time that you could use doing something more productive like developing a new project to solve a new problem.
Until you work on an OSS project, it is easy to say -- why can't you change this? The reality is that backwards compatibility is the biggest concern. I worry about each and every change to Mach-II and how it affects applications that I don't control.
As for etiquette, I think it is good etiquette to contribute back to the project. However, remember that all contributions may or may not be accepted into the core of the project. Probably this is why it is best to talk with core commiters and people involved first before making changes and potentially wasting your time. Architect first, code second ;-)
Posted By Peter J. Farrell / Posted on 02/06/2007 at 9:38 AM
If someone (not me mind you) doesn't experiment - how do you know there isn't a better way to do something :)
Peter B. says: "Why rebuild a framework from scratch when there are great ones out there"
They why aren't we all using Fusebox :P
The only really thing I'd frown upon would be altering a project with doubtful intents - the person who was modifying BlogCFC and redistributing it as his own comes to mind.
If you are altering it for your own use - then go for it - I'd hope anyone with enough smarts to do that would already be aware of your reasons not too :)
Posted By Jim / Posted on 02/06/2007 at 11:28 AM
Good points. Nothing wrong with experimentation at all - that's why I wrote a framework to solve the "solved" problem that ColdSpring handles great already.
Note that I qualified my "don't write a framework" with the fact that there are valid use cases. The ones that come to mind:
(i) To REALLY learn what you're doing - you will learn more from taking a framework apart and rebuilding it than just from using it.
(ii) To solve a problem the current frameworks don't. Start by considering if you could extend a framework, but if you want an object driven controller or a continuation server, go for it.
(iii) You feel like it - It'll take longer than you expect, but go for your life!
As for altering, agree 100% that passing off as your own work isn't cool.
As for altering for your own use, feel free, but I think it was still valid for Brian to raise the above points as you don't need to pass an IQ test or exam to be "allowed" to alter a framework, and while many of smart people do it, others also try and get into trouble, so I think it was a timely reminder of the trade offs you're going to encounter if you do decide to unanimously fork the core!
Posted By Peter Bell / Posted on 02/06/2007 at 11:48 AM
I am also not seeing how this in any way represents a push towards a single solution (i.e. your Fusebox comment). Model-Glue, Mach ii, etc. were not modified versions of Fusebox...you have a logical disconnect in your argument there.
I also don't think this is as obvious as you do (nor do I think it necessarily takes a smart person to go modify the code, which, in fact, is part of the point perhaps). I think there is a presumption by some people that open-source is open *so that* you can modify the code. I think in many cases it is as much or more about transparency and soliciting input from the broader user community than it is about empowering users to modify the code. Again, going back to the just because you can doesn't mean you should.
Lastly, this does not mean that under all circumstances you should not modify open-source code. There are times when, if carefully considered, modifying the code makes perfect sense. For instance, I needed a quick voting application recently, and after considering the options (being 1 - build it myself from scratch or 2- modify Ray Camden's Soundings so that it meets the client's requirement) I chose to head down the path of modifying the project. Still I considered the drawbacks listed above before doing so.
Posted By Brian Rinaldi / Posted on 02/06/2007 at 11:55 AM
I'm well aware of the issues of mucking about with the source... I've spent the last few nights 'fixing' things which I knowingly broke on my WordPress blog after a recent upgrade (see Reason #1)!
This would make an excellent Slashdot post! :)
Posted By Jim / Posted on 02/06/2007 at 1:52 PM
Posted By Brian Rinaldi / Posted on 02/06/2007 at 5:30 PM