Leave that code alone!

February 6, 2007 · 6 Comments

Brian Rinaldi has a great post on why it's usually a bad idea to modify open source frameworks. He gives some very solid reasons why you should treat a framework as a black box instead of changing how it works. There's an interesting stream of comments too. I think the one thing that resonates most with me is not part of the original post but in one of Brian's own comments in the ensuring thread:

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.

Open source is really about culture and mindset and these two sentences sum up, for me, the core misunderstanding that many people have about the process.

View count: 585

Tags: coldfusion · oss

6 responses so far ↓

1 Adedeji Olowe // Feb 6, 2007 at 9:36 PM

I guess I agree with that. The biggest problem you could have, especially if your code changes stay with you, is upgrade. An newer release of the open source code could make a mess of all the fancy changes you have made. And that could happen months or years down the line.
2 Adam Cameron // Feb 7, 2007 at 1:22 AM

Hi Sean
Isn't the idea of open source stuff that if one's inclined to make changes, then the process is to contribute them back to the central project?

So there's not so much wrong with the notion of making changes, but HOW one makes those changes? This could be what you're suggesting with your "culture and mindset" comment.

--
Adam
3 Sean Corfield // Feb 7, 2007 at 7:27 AM

Adam, yes, that's exactly my point. Open source isn't put out there so you can simply modify your own copy but for you to see how it works and if you see improvements, contribute them back to the project.

As Brian says in his post, sometimes what you think is an improvement may go against the principles behind the code - because you don't have all the background information as to why a design decision was made. In those cases, discussion with the authors and/or community will provide a lesson in software design that may either lead to you deciding your "improvement" is not, in fact, an improvement or sometimes to the authors deciding your "improvement" is worth adding despite not fitting the principles.

Open source is meant to be a collaborative approach to some degree, although it is not a balanced two-way street: the authors are still the authors and you are still the user.
4 John Paul Ashenfelter // Feb 7, 2007 at 8:52 AM

The issue comes when you make changes that aren't accepted back into the main project -- where you're left with a small set of options including campaigning for your changes, forking, or giving up. All make sense in certain contexts.

One great example for me in the Fusebox world is John QvT's insistance that IFs didn't need nested and that a CASE/SWITCH statement was a bad idea too. With no interest in accepting patches for those, the option was fork the code for my projects or to pick a different framework. This demostrates several aspects of the good/bad of open source -- mainly that since the code was open, I could make my changes whether they were smart or not, whether they made sense to the bigger project or not.

Any open source project has a human element -- again as Fusebox has demonstrated *numerous* times -- and those are definite factors in how the project grows/moves forward. One could consider Fusebox4 a "fork" of Fusebox3 and Fusebox5 is *definitely* a fork of Fusebox4, but since in both cases there's been no serious development of the previous track, it's looked more like upgrades :)

Many successful open source projects have benevolent dicators (eg MySQL, Linux) while more democratic ones can end up more like Postgres or Chandler :)
5 Sean Corfield // Feb 7, 2007 at 9:18 AM

My direction on Fusebox 5 was to remove any nesting constraints on the grammar (that was just an implementation issue as far as I was concerned) but not to add more verbs to the core. That provided unlimited nested <if>s.

The custom lexicon opened the door to optional verbs and the skeleton application contains examples, including <cf:switch> / <cf:case> / <cf:defaultcase> :)

Does that make me a benevolent dictator?
6 Nat Papovich // Feb 27, 2007 at 4:56 PM

No Sean, that makes you an evil, horrid, tyrannical dictator :)

An Architect's View

CFML, Clojure, Software Design, Frameworks and more...