Category Kern’s blog

Why Forking is Bad

I have always felt that forking an open source project is mostly a waste of energy because for the most part you get 1, 1 rather than 1+1, in other words the synergy of working together is lost by forking. Secondly forking divides the community.  Today, there are a lot of advocates of forking, and on the side of forking, I have even written a blog on why not all forks are bad:

On the side of forks are bad, it is important to understand what experts such as Eric S Raymond have to say about it.  I quote:

The three taboos we observed above make perfect sense under this analysis. One’s reputation can suffer unfairly if someone else misappropriates or mangles one’s work; these taboos (and related customs) attempt to prevent this from happening. (Or, to put it more pragmatically, hackers generally refrain from forking or rogue-patching others’ projects in order to be able to deny legitimacy to the same behavior practiced against themselves.)

  • Forking projects is bad because it exposes pre-fork contributors to a reputation risk they can only control by being active in both child projects simultaneously after the fork. (This would generally be too confusing or difficult to be practical.)
  • Distributing rogue patches (or, much worse, rogue binaries) exposes the owners to an unfair reputation risk. Even if the official code is perfect, the owners will catch flak from bugs in the patches (but see [RP]).
  • Surreptitiously filing someone’s name off a project is, in cultural context, one of the ultimate crimes. Doing this steals the victim’s gift to be presented as the thief’s own.

Of course, forking a project or distributing rogue patches for it also directly attacks the reputation of the original developer’s group. If I fork or rogue-patch your project, I am saying: “you made a wrong decision by failing to take the project where I am taking it”; and anyone who uses my forked variation is endorsing this challenge. But this in itself would be a fair challenge, albeit extreme; it’s the sharpest end of peer review. It’s therefore not sufficient in itself to account for the taboos, though it doubtless contributes force to them.

The full  quote can be found in following section:

and the full text of “Homesteading the Noosphere”, by Eric Steven Raymond is at:

As project manager of the Bacula open source backup and restore program, I have experience with two open source forks and at least one closed source fork.  All three were made by former Bacula developers.  The first open source fork was Burp and is what I call a friendly non-commercial fork and was the subject of the first blog I cite above.  The second fork was Bareos. The Bareos fork was created by the four directors of DassIT, which is a commercial company and one former Bacula developer.

The third closed source fork is where a former Bacula developer created a backup appliance based on Bacula and the web site now stated that the code is proprietary.  This fork will be the subject of another blog one day and is not really in the category of open source forks that I am discussing here.

What Eric Raymond exposes in his article is that reputation in an open source project is more important than one would imagine.

All Project Forks Are Not Bad

In general, I believe that project forks are not good. I wouldn’t really say that forks are bad, but they do tend to duplicate effort and split the community. They certainly are justified if the particular project is stalled or is not willing to meet the needs of a community or if the new project has a different goal.

In 2011, there was a fork of Bacula started by Graham Keeling, called Burp (  In the past, Graham had contributed some interesting features  to Bacula.  What is clear is that Graham and his fork are not at all hostile towards the Bacula project, in fact it is just the opposite.  Graham does have different ideas of backup or different goals, which are nicely explained on his site.

I have been aware of this fork since its inception, and when looking at the source code, I noticed a few minor problems with the copyrights, but decided that it was not significant enough to mention.

However, recently Graham asked a question on the Bacula web, and I did my best to respond to it.  In my response, I mentioned that I found a few issues with his fork.  Graham immediately contacted me, and off-list, I explained that I felt that few of the file headers should really include the Bacula FSFE copyright.  The next day, Graham posted a commit that in my view fixed all the problems and in exactly the right way.

I must say that this surprised me in a very positive way, because I just mentioned the problem and Graham fixed it.

I asked Graham if Bacula and Bacula Systems could include some of his code in the and Bacula Enterprise versions, and Graham,  stated that any of the burp code can be used in (they are licensed the same) and anything that goes into can also be used in Bacula Enterprise — the mark of a real gentleman.

Conclusion: Burp is a fork of Bacula that has implemented something different and both projects can benefit from the other.

The Hidden Cost of Creating Open Source Code

Just because it is called open source (or Free Software), that doesn’t mean that it is free, and it doesn’t mean that it didn’t cost anything to develop it.  In particular, I would like to explain what open source means to me and what it has personally cost me, but please permit me to start from the beginning.

I wrote my first computer program on an IBM 1401 in the basement of the physics building on the Berkeley campus of the University of California in 1961. That lead to other programs on their “mainframe”, and IBM 7094 located in the Berkeley Computer Science center.  Later while at the University of Maryland, I programmed on a Univac 1108 machine both by batch operations with punched cards and on 110 baud teletype machines.  On day, I noticed that every time I did a particular operation, the machine crashed, so I went to the computer science center and told them that I was crashing their machine.  They did not believe me, but they did put me on a terminal and asked me to do my thing, which of course crashed the machine.  After everything calmed down (a lot of guys running all different directions when the machine crashed), they told me not to do that again because we were in final exams and usually there were 100 students at a time using the machine.  They also offered me a job, which I accepted — that was in 1971.

Guess what my first project was?  Well if you didn’t guess, it was running, correcting, and enhancing their backup program that was called “Secure”.  Now in those days, backups were done as they still are at 2am in the middle of the night, but if something went wrong, I was called to come in, so very quickly, I learned how to stabilize an unstable program (all in assembly language) and how to modify and test it in a way that I could be sure that it wouldn’t crash. Note, all the code that I wrote while at the University of Maryland (quite a lot) was “open source” in the sense that it was freely available on request and could be used by anyone.

To keep the story from being too long, from there in 1978, I went on to work for Bechtel Power company in San Francisco where I was responsible for backups, performance, upgrades, facilities, capacity planning for their large mainframes  (Sperry Rand and IBM).  Finally in 1982, I went to work for my own startup company, Autodesk, where I helped create a computer aided drafting (CAD) program named Autodesk.  I finally left Autodesk definitively in late 1995.  After that, I continued working doing small programming projects on my Solaris computer and experimented with Windows, but I was looking for something better, and in 1996, I started working with Linux on PC machines learning how  to use open source and setup my own server.  After a year or so of learning, my first major project was APCUPSD, a UPS monitoring program.  By late 1999, I was looking for a larger program, so I started my own project named Bacula.  After two years of building the basic components, I released it under the GPLv2 license to Source Forge in April of 2002.

With all that said, I would now like to get to the costs of writing open source.  First, it should be quite obvious that to create a project the size of Bacula, one must spend many hours programming, documenting, debugging, and helping people use the program.  In addition, for a program like Bacula, you need tape drives, autochangers, fibre optic networks, multiple computers of various architectures, …  At one point, I calculated that in cash outlay mostly for hardware, I spent about $8,000 per year.  This did not include the electricity, printers, ink, paper, and everything else it takes to run computers.  This is not an enormous amount, but since the project has just now finished its 14th year of existence, a quick calculation shows that the out-of-pocket expenses to me have probablyamounted to $112,000.  Over the same 14 year period, donations amounted to $5,000 — thanks to all who donated.

I suspect that for other similar open source programs the costs were similar.  So, open source is not free.

In 2007, I realized that in order to ensure the future of Bacula, I would need to either find a corporate sponsor or create a company that could carry on the project and ensure that it was properly funded, and even hire people to work on it.  In the end, in July of 2008, Bacula Systems SA was created by myself and 7 other founders, all of whom put their own money into the company to create the CHF 450,000 of working capital that would ensure that the company could function. The concept was to offer service for Bacula and to contribute a certain amount of development to Bacula.  As a consequence, it was 100% open source — that is in 2008 the Bacula Enterprise source was publicly available, and all the fixes and enhancements that Bacula Systems created went directly into both the community and enterprise versions, which were identical.

The problem is that Bacula was designed for large enterprises, not for small business.  A small business (for example a doctor’s or dentist’s office)  will generally have only one or two computers and can do backups with a very simple program that simply backs up to a CDROM.  While Bacula is not a simple program in addition, requires a Linux system, a network, and usually something like a tape drive or an autochanger for backups.

This meant that even if the Bacula Enterprise code is free, small businesses were not interested, and large companies, are reluctant to work with a new small company such as Bacula Systems was at the time, or they already had the technical means to take the open source software and use it.   Since the Bacula community provides a lot of help and bugs were quickly fixed, there were not many customers for Bacula Systems.

By 2011,  since much of the Bacula Systems working capital had been spent, we realized that either Bacula Systems had to be liquidated, or we had to obtain venture capital — that is sell a part of Bacula Systems to an investor.  But no investor would invest without a different business plan that would increase the chances of success which meant differentiating Bacula Enterprise from the community code base and thus Bacula Enterprise would become open core. Between the choice of closing Bacula Systems and probably thus abandoning Bacula, for me the choice was clear.  We did find an investor who believed in this and that is why today Bacula Systems is an open core company.

However, Bacula Systems is a bit different from most open core companies, because we will give our “proprietary” source code to customers, providing they agree not to distribute it, and we also firmly believe in open source, and contribute a significant percentage of what Bacula Systems produces to the Bacula community version, including all bug fixes.  Contributing back to the community has been a part of Bacula Systems from the very beginning, and though it slowed down a bit from 2010 until the end of 2012 while the differentiation process was getting started. Recently Bacula Systems, went farther and worked with the FSFE to create an agreement whereby Bacula Systems formally states that it will contribute all its development, not bound by a third-party proprietary agreement, to the Bacula community version within a maximum of 5 years delay.

Coming back to the question of cost.  It turned out that the Bacula Systems founder (one of eight) who was supposed to be the CEO of the company was an excellent Business Development person with some skills in Marketing and Sales, but he found it difficult, if not impossible to be a CEO, and due to his personality and background could never survive as a CEO of Bacula Systems. The company offered him a Business Development position, but he decided he preferred to leave if he could not be CEO.  To make this work, we had to buy him out — that meant that myself and the principal investor had to put up a significant amount of money to re-purchase his Bacula Systems stock.  So for me, developing open source at this point became very expensive, but if I started over again, I would do the same thing.