

Open source and the ability to modify code - NickLarsen
http://cultureofdevelopment.com/blog/2013/02/28/open-source-and-the-ability-to-modify-code/

======
vog
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.

~~~
cpressey
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.

~~~
NickLarsen
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.

~~~
cromulent
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?

~~~
NickLarsen
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.

------
cromulent
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>

------
jrockway
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.

------
fuzzix
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.

------
csmatt
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?

~~~
NickLarsen
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.

~~~
cpressey
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.

~~~
pasbesoin
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.

------
reidrac
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.

------
jahewson
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.

------
ef4
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.

~~~
takluyver
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.

------
mwcampbell
It is well known that distributed version control systems make it easier for
developer soutside of a project's core team to contribute to the project. But
it seems to me that package managers are counteracting this, because they
encourage a sharp division between user and developer. I'm talking about both
OS-level package managers like APT, and programming language/VM-level package
managers like Maven, NuGet, RubyGems, npm, and the various Python package
management tools.

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.

~~~
takluyver
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.

------
EGreg
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!

~~~
camus
symfony is so modular you dont even need to fork it , just write plugins.

~~~
EGreg
yep, that's what I am talking about

------
hawleyal
ಠ_ಠ Y U no understand how free software works

