Open Source does not mean Customization Heaven..
Unless you are doing it wrong.
And sadly I`m seeing more and more people doing it wrong.
To a lot of people Open Source means that they have a piece of software that does almost what they want and which they can modify to their best wishes and use internally.
So they fork locally,, they don't redistribute their code , but they aren't contributing their changes back upstream, chances are these changes wouldn't be accepted upstream anyhow as they are really customizing the code for their specific cases. At first sight this doesn't look so bad , at second sight ..
When weeks or months later the upstream project releases an urgent security fix, the local fork has deviated soo much that it can't upgrade anymore and stays with an insecure version.
Often it's worse.. a feature that could have been accepted upstream has been implemented slightly different in the local fork, the result being that newer features depending on the first one also can't be integrated anymore
Some projects are prepared for local contributions, they have a modular framework that allows you to build on top of the project while not having to touch the core of a project, Drupal and openQRM are great examples of those, but not all projects are that smart. Needless to say that when you have such a modular framework you really shouldn't be modifying the core part of the platform, unless you are fixing a real bug.
But the general rule of thumb is that when you fix bugs, make sure they are inserted upstream , or implement new features.
Now sometimes there is no easy way to get your code accepted upstream, in which case you should announce clearly that you want to contribute but you are blocked and publish the patches somewhere else ...
Don't let the community work for you, but work with the community !
Comments
#1 Sheeri K. Cabral : The take-away idea isn't
The take-away idea isn't "fork" or "don't fork" or "send changes back upstream" or "don't send changes back upstream".
The take-away idea is "if you're going to customize software, make sure you are able to keep your customizations through an upgrade."
Some software already has this capability in place (ie, "local" changes. The RT ticketing system at http://bestpractical.com/rt comes to mind).
But really -- it's shortsighted of folks to customize something that they can't upgrade. But that doesn't mean "don't fork" or "always send changes back upstream".
#2 Kris Buytaert : Good Open Source Citizens
A good Open Source citizen sends patches upstream.
A good Open Source project accepts patches from potential contributors
#3 Pasqualle : Fork
I would tell that a Drupal fork is a dead end, as you can't develop faster than the Drupal community, and you will miss all the new features. So at some point you will have to dump all your custom changes and start over with a fresh Drupal version..
actual example: why would someone switch to D6 if he has a great and nicely forked D5? Because of Views 2!
and I am sure I can give you an unchallenged reason with every new Drupal version.
#4 Philip Paeps : I don't completely agree. :-)
Given a sensible revision control system and sufficient discipline, a "local fork" of a piece of open source software can work quite well.
Some companies really don't want to release their work back to the community. For whatever reason. The most common reason, entirely by the way, is that companies' local changes tend to be completely irrelevant to other consumers. As long as they're using open source and staying well clear of free software, this is perfectly alright. Of course, staying in sync with upstream becomes entirely their problem too.
In my experience, software which gets locally forked tends to be "mature software" whose upstream doesn't change very much, and/or the local fork quickly becomes so vastly different that there really is no point in trying to keep up with the upstream version.
Since the examples you cite are all 'webby' things which need to be rewritten weekly to adapt to whatever hype is hot now, and which are insecure and buggy and leak memory by definition, I guess you're living in a completely different world than I. :-)
In your world, I would probably agree that forks are bad.
In my world, forks are par for the course. You learn to live with them and if you've got competent hackers, it works out well most of the time.
#5 lynns corner : philip, there's not a lot of
philip, there's not a lot of difference between open source and free software. In both cases, you're allowed to modify locally and not contribute changes upstream. However, if you give your modified version to someone outside your company, you need to offer them the source code with your changes.
#6 Kris Buytaert : It's in the tags
If you had looked in the tags you'd notice I wasn't really pointing to webby thingies..
But rather to Billing and CRM apps..and also bash and full LinuxDistro rebuilds
but then offcourse from your point of view.. those are still webby apps :)
#7 Wim Mostrey : Working with the community
I can see how your points are valid Philip but I can't agree with your statement about "webby" things being insecure and buggy by definition and how they go out of their way to follow the latest hypes. Do note that we're talking about the core of open source software here, and in particular Drupal core, and not about the numerous contributed modules or plug-ins. Drupal core is very stable and the process of adding new features is well thought of. The addition of Fields in core is a great example of this process.
And when you're talking about security: I find that an unmodified Drupal core tends to be a whole lot more secure than the forked versions I've seen in a bunch of companies I've worked with. When you have thousands of people and a dedicated security team looking at your code, security issues tend to be found a lot quicker than when there's just one or two people. Security in these forks comes mostly from obscurity and not so much from secure code.