Open source and the ability to modify code(cultureofdevelopment.com)
cultureofdevelopment.com
Open source and the ability to modify code
http://cultureofdevelopment.com/blog/2013/02/28/open-source-and-the-ability-to-modify-code/
11 comments
To play devil's advocate: do compiled languages have the same effect? They create a separation between developers (who use the source) and users (who use binaries). Especially for projects with a long/slow build process, like LibreOffice, this can be a considerable barrier to development.
By contrast, even the biggest codebase you use in a language like Python, you can dive into the code directly. Well, unless it's Software as a Service.
By contrast, even the biggest codebase you use in a language like Python, you can dive into the code directly. Well, unless it's Software as a Service.
This is kind of how homebrew works for some formula if you specify --head. I find the homebrew model of having a repository of formulae which point to tarballs or repos to work pretty well.
Well, that's why a good framework should be built in a modular and extensible way. For example, the way we build our Q framework (previous open source version is here: http://phponpie.com) is that you can override the core with plugins, and plugins with your apps. There is a cascading file system, that I learned from Kohana. Very useful!
ಠ_ಠ
Y U no understand how free software works
I agree that, in general, you don't want to maintain a fork because that's a lot of work (or more work than contributing the changes so they're included and maintained upstream), but I don't like the idea of losing the benefits of open source customizability because upstream don't want your changes (sometimes it happens, for different reasons).
So yes: avoid forking when possible, but don't be afraid of maintaining a fork if the benefits are worth the effort.
So yes: avoid forking when possible, but don't be afraid of maintaining a fork if the benefits are worth the effort.
The auther gives a very important advice, but takes it to an unhealthy extreme.
I fully agree that you should always try to contribute the changes you make to a Free Software project. This has not only the advantage of less maintainance work in the long run. It also means that your changes will be reviewed - by people who know the code you're modifying very well. So contributing also means to get a good quality assurance.
However, it makes still a lot of sense to keep a local fork in addition to contributing. And here the author argues too one-sidedly when he recommends that you should do that only for security fixes. There are many other scenarios in which this makes sense:
1) The change may be important for you (e.g. to make the code compile on some strange OS), but not be accepted by upstream (e.g. they don't want to support that strange OS in the long run).
2) The review process, as well as the next release, may take some time. And you certainly don't want to make your own release schedule totally depending on other projects' release schedules.
In the first case, you have no choice but to keep a local fork as long as the project maintainers don't change their mind or provide a better solution.
But even in the second case you'll have a long-term fork, at least if you are contributing regularly. But that's not a bad thing, because everytime the upstream project releases a new version, you can remove some of your (contributed) local changes from your fork. So yes, you'll have a long-living fork, but it will only differ from upstream by the last few patches not yet accepted by them.
I fully agree that you should always try to contribute the changes you make to a Free Software project. This has not only the advantage of less maintainance work in the long run. It also means that your changes will be reviewed - by people who know the code you're modifying very well. So contributing also means to get a good quality assurance.
However, it makes still a lot of sense to keep a local fork in addition to contributing. And here the author argues too one-sidedly when he recommends that you should do that only for security fixes. There are many other scenarios in which this makes sense:
1) The change may be important for you (e.g. to make the code compile on some strange OS), but not be accepted by upstream (e.g. they don't want to support that strange OS in the long run).
2) The review process, as well as the next release, may take some time. And you certainly don't want to make your own release schedule totally depending on other projects' release schedules.
In the first case, you have no choice but to keep a local fork as long as the project maintainers don't change their mind or provide a better solution.
But even in the second case you'll have a long-term fork, at least if you are contributing regularly. But that's not a bad thing, because everytime the upstream project releases a new version, you can remove some of your (contributed) local changes from your fork. So yes, you'll have a long-living fork, but it will only differ from upstream by the last few patches not yet accepted by them.
I agree. Local forks are often valuable. And a project can't be expected to accommodate everyone's vision for how the software should be used.
The pain comes in when the upstream project decides to refactor the code in a way which forces you to completely rewrite your patches.
The pain comes in when the upstream project decides to refactor the code in a way which forces you to completely rewrite your patches.
This is exactly the pain my advice helps you avoid. The implicit cost of creating a fork is that future changes higher up the chain could either cause you to be stuck at this revision or give you an additional bulk of work in order to update. Of course anyone can update and run a custom build for their project, but the cost is often not worth it.
It should be noted that the situation where you intend to fork and maintain the project, this does not apply, and by all means make your changes. In the case where you intend to update, this pattern will help you avoid the pain.
It should be noted that the situation where you intend to fork and maintain the project, this does not apply, and by all means make your changes. In the case where you intend to update, this pattern will help you avoid the pain.
So, where you intend to fork and maintain, then fork and maintain.
If you do not intend to fork and maintain, then do not fork and maintain.
Is that what you are saying?
If you do not intend to fork and maintain, then do not fork and maintain.
Is that what you are saying?
Yes, with a strong bias to not forking and maintaining. Stale project, well you gotta fork and maintain. Active project, avoid forking with the intention of using a custom build in your system.
Nick - it's just different levels. One can say the same thing about future versions of libraries not maintaining backward compatibility, and breaking APIs that applications depend on. So does this mean you should never download upgrades of libraries that your apps depend on?
The way I see it there are there levels in a good stack:
1. CORE 2. MODULES 3. APPS
Ideally, the thing should be extensible enough that the module writers can respond to changes in the core but keep their own API backward compatible. There are fewer modules than apps, and there is only one core.
So I think the whole argument isn't black and white, it's a matter of degree! Things have to get done, and sometimes things change. That's the only constant, you know :)
The way I see it there are there levels in a good stack:
1. CORE 2. MODULES 3. APPS
Ideally, the thing should be extensible enough that the module writers can respond to changes in the core but keep their own API backward compatible. There are fewer modules than apps, and there is only one core.
So I think the whole argument isn't black and white, it's a matter of degree! Things have to get done, and sometimes things change. That's the only constant, you know :)
I've managed this with a couple of projects. With one, it was C source, pretty discrete set of modifications so used git to do the leg work - one remote was our own repository, the other was upstream. I can't recall seeing a conflict when rebasing from upstream branches.
The other project explicitly allows for code modifications and accomodates them in a separate directory you can keep in revision control. Again, no memory of major conflicts in stuff we did correctly - i.e. used the provided overlays or callbacks.
So, when is it a bad idea? When you step outside certain constraints (like our callbacks example above) and override or replace or modify directly the project's own code in some significant fashion.
So, modification of open source for your own needs is a major plus if the project accomodates it sanely or the scale and nature of the changes are controllable.
edit Removed "and only if" in last paragraph, attempts to preclude people from providing better ideas.
The other project explicitly allows for code modifications and accomodates them in a separate directory you can keep in revision control. Again, no memory of major conflicts in stuff we did correctly - i.e. used the provided overlays or callbacks.
So, when is it a bad idea? When you step outside certain constraints (like our callbacks example above) and override or replace or modify directly the project's own code in some significant fashion.
So, modification of open source for your own needs is a major plus if the project accomodates it sanely or the scale and nature of the changes are controllable.
edit Removed "and only if" in last paragraph, attempts to preclude people from providing better ideas.
Not according to some:
"The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run the program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her."
The Free Software Definition http://www.gnu.org/philosophy/free-sw.html
"The freedom to run the program means the freedom for any kind of person or organization to use it on any kind of computer system, for any kind of overall job and purpose, without being required to communicate about it with the developer or any other specific entity. In this freedom, it is the user's purpose that matters, not the developer's purpose; you as a user are free to run the program for your purposes, and if you distribute it to someone else, she is then free to run it for her purposes, but you are not entitled to impose your purposes on her."
The Free Software Definition http://www.gnu.org/philosophy/free-sw.html
This brings up a good point. The two companies I've worked for have used a ton of open source software and have contributed nothing back. It kind of disgusts me. Am I wrong to feel that way?
Were they actively making changes to the project and running custom builds? If not then they just had nothing to contribute to the project and there is certainly nothing to feel disgusted about.
Even if they were making local changes, I personally couldn't fault them, really; they're playing by the rules.
If they want to give up the intangible benefits they would get from sharing those changes (at least the non-business-strategic ones), that's disheartening, but I wouldn't lose any sleep over it.
If they want to give up the intangible benefits they would get from sharing those changes (at least the non-business-strategic ones), that's disheartening, but I wouldn't lose any sleep over it.
That doesn't mean we don't get to question the rules. And... to consider our individual choices.
In my case, I started feeling like I was working for a parasite. And... I didn't particularly want to continue working for a parasite.
In my case, I started feeling like I was working for a parasite. And... I didn't particularly want to continue working for a parasite.
You're not wrong to feel that way. It is not strictly required to contribute back to the community when using F/OSS products - but doing so is the best thing to do by a wide margin. It's okay to feel uncomfortable when the company you work for is being a free rider.
I don't find it that hard to maintain forks with git, even ones in which thousands of lines of code have been changed locally.
My usual reason for having a fork is Solaris support, or removing code which I don't need for performance reasons, or replacing the CMake build system with something sane. These aren't the kinds of changes which many maintainers are willing to accept.
Another frustratingly common case is that the original maintainer has gone AWOL and I need to fix a few bugs and maybe add a couple of features, but I do not want to become the de facto maintainer of a public fork.
My usual reason for having a fork is Solaris support, or removing code which I don't need for performance reasons, or replacing the CMake build system with something sane. These aren't the kinds of changes which many maintainers are willing to accept.
Another frustratingly common case is that the original maintainer has gone AWOL and I need to fix a few bugs and maybe add a couple of features, but I do not want to become the de facto maintainer of a public fork.
This is precisely one of the areas in which Git shines. It used to be a pain to maintain your own patches on top of an open source project. But with Git it's easy.
Git helps with keeping track of your patches, and can deal with simple structural changes, like if a function you've modified is in a different position in the file. But it's still up to you to deal with real functional changes coming from upstream, and I think that's the author's main point.
As an upstream maintainer, I prefer that people contribute rather than maintain their own forks. It just makes it easier for other users; what if they want a feature that's in user A's repository and a feature that's in user B's repository? It's not their job to figure out how to merge them: I do that so they can focus on adding features instead.
But with that in mind, there are plenty of cases where you do need to maintain a proprietary fork: testing new ideas, integrating with internal infrastructure, and so on. This is certainly more difficult than letting someone else maintain the project, but less difficult than being the maintainer yourself. You basically miss out on big refactorings, but it's no different than being a regular user of a library that makes incompatible API changes.
But with that in mind, there are plenty of cases where you do need to maintain a proprietary fork: testing new ideas, integrating with internal infrastructure, and so on. This is certainly more difficult than letting someone else maintain the project, but less difficult than being the maintainer yourself. You basically miss out on big refactorings, but it's no different than being a regular user of a library that makes incompatible API changes.
One solution might be for applications to pull in all of their dependencies as subrepositories in their version control systems. But then where would we stop? At the implementation of the application's main programming language or managed runtime? At the C library? At the operating system itself (assuming the OS is open source)? This would also seem to encourage a single dominant version control system.
So I have no definite answers.