Hello,
Some time ago, I wrote that I was going to discuss:
1. GUI interface
2. Restructuring the Bacula project
3. Performance enhancements
1. The GUI interface preliminaries have been hashed around quite a lot. There
are a lot more details we will work out over time ...
2. Restructuring the Bacula project is the topic of this email, see below:
3. Performance enhancements. I didn't expect to address this at this point,
but in fact, I expressed most of my ideas already in an email to Eric and
Marc.
Restructuring the Bacula project:
I've been turning this over in my mind and discussing parts of it with
serveral people now for several months. At this point, I have made a lot of
progress but there are still some rather critical grey areas where I am not
sure what the right direction is.
Basic problem: Bacula is now entering or in the Enterprise class of software,
which means that it is becoming a critical component of many institutions.
It is now somewhat over 150,000 lines of code and has largely depassed my
capacity to understand and keep in mind the whole program. Some years ago
when it was 20-50,000 lines of code, fixing most bugs and getting out new
releases was rather rapid -- the full set of regression scripts ran in 15
minutes. Today, my personal development is going exponentially slower (the
overall development speed is remaining the same or possibly increasing). The
regression scripts take something like 4.5 hours to run, getting out a new
release is very difficult. I simply no longer have the time to correctly
manage the project as it is currently organized -- there are a lot of reasons
for this, mostly described above.
The problem is given the above, how do we move forward from here? How do we
ensure that Bacula grows and that it survives in the long term?
======
Before presenting some of my views for your review and comments on how we can
do this, I would like to re-iterate a few guiding principles that you must
always keep in mind when reading forward as they can be easily forgotten when
one is seaching for solutions. I've indicated very rough timeframe for the
changes:
1. I am committed to Open Source and to keeping Bacula as Open Source
(forever).
2. I want to ensure the long term survival and independence of Bacula, which
means it needs some sort of a "legal" structure, a governance, some
reasonable financial means, and a careful examination of the copyrigh
assignment issues concerning contributions (6 mo - 1 year).
3. The current project is *far* too dependent on me, and I have reached my
capacity to contribute (i.e. I can continue to contribute to the extent that
I do now, but I cannot contribute more), so we need to find additional ways
to "leverage" the project so that it can continue to grow without me being
the bottle neck (1 - 6 months).
4. I would as much as possible to avoid that Bacula becomes too commercial a
long the lines of MySQL where from what I understand virtually all the MySQL
development is done by paid employees. In other words I would like to retain
the volunteer Open Source contribution as much as possible -- at the same
time encouraging more "contribution" from those who benefit from Bacula, and
permit those helping the Bacula project to be appropriately compensated.
I hope that everyone can more or less take the above as given guiding
principles otherwise the rest of this email probably doesn't make much sense.
==============
#1 doesn't need much elaboration.
#2 I have discussed before, and I hope that within the next 6 months I can
convert the Bacula project to be a Swiss Association (the closest American
concept I can imagine is a Partnership, in France, I believe they are also
called Associations, and in other countries "Clubs"). Long term (say 5
years) I imagine it would become a Foundation, but that is too expensive
currently. The basic idea here is to get some sort of governing board (even
if it starts out being me), a definition of the project, the ability to open
a bank account, and the ability to hold the copyright.
I had the good fortune recently (thanks to Martin for working out some email
problems) to meet with Georg Greve who is the President of FSF Europe and
based in Zurich. It appears that FSF Europe may be able to help me with
parts of this project transition.
Part of this will be to "cleanup" any possible copyright assignment issues,
which mainly means getting assignment agreements from any major contributors
of code to Bacula and ensuring that all developers with CVS write access have
signed such an agreement. Please see the Developer's guide for more details
on this.
#3 Currently, I am responsible for:
- programming many of the major projects
- helping/organizing/guiding the developers
- doing the English documentation
- making changes to the Web site
- releasing the source code (Scott Barninger handles the rpms)
- releasing the documentation
- testing the code prior to release on Linux, Solaris, FreeBSD, and
to a much smaller part Win32
- with the exception of Win32 (which Robert is handling), doing 90+% of
the debugging/bug fixes.
- testing new features
- documenting new features
- accepting and applying patches from developers that do not have
CVS write access
- more or less maintaining the Source Forge site and the mailing lists
with the exception that Russell Howe handles the big task of being
a spam filter.
In an attempt to free up some of my time and reduce my responsibilities, here
are a few of the changes I am thinking about making:
1. I will probably reduce my participation in big projects and concentrate
more on projects that have a personal interest to me.
2. Future code submissions/new features will not be accepted unless they
are accompanied by documentation for the manual as well as a certain
technical documentation for the Release Notes. To ease into this, I will
accept text and convert (or help convert) it to LaTeX for the manual.
3. I'll probably slow down or stop making changes to the Web site. Hopefully
someone will take this over.
4. I'll continue to release the source code, but I will no longer test on any
machine other than the one I am running, which is currently SuSE 10.1.
This means that we will need testers to step forward. As you read, Peter
Buschman has agreed to setup a test bed, and Dan is going to make
CVS snapshots available. I would hope that other interested parties will
join in and help. Win32 is being covered by Robert Nelson.
5. I will reduce and probably even stop doing debugging on all systems other
than the one I am working on over say the next 6-9 months. This means that
we need technically qualified people to step forward to ensure that
platform specific bugs are corrected -- this affects mainly Solaris and
FreeBSD. If no one steps forward, these platforms will be declassified as
officially supported and put into the catagory of "it seems to work". I
sincerely hope this does not happen.
6. Following the release of 1.40, I will no longer do regression testing on
FreeBSD or Solaris -- hopefully Peter's and others work on this will fill
the gap.
7. All new features that are submitted will be required to have as mentioned
above, documentation for the manual, and at least one regression test
script. Over the next couple of months, I will improve the documentation
for how to write regression scripts -- if you understand Bacula commands
it is basically a piece of cake.
8. Bugs that are difficult to reproduce will need a regression script to be
submitted so that I can easily reproduce them. I've already started this
to a limited extent, and hopefully we will get some help writing
regression scripts from more people (see the next item).
9. I plan to define system of "concentric circles" of people somewhat like
is done in the FreeBSD project so that bug reports and other problems
can be "filtered" before I have to look at them. This can involve ensuring
that bugs are correctly presented with all the necessary info, helping
preparing regression scripts for reproducing the bug, ...
I have some ideas here, but this is probably a subject for another
email.
There will surely be more changes to follow, and as I tried to indicate, these
changes will be phased in rather gradually -- if no one steps forward in a
reasonable time to fill the need, then the need will go unfilled. There is
a lot to be discussed, but most of the above is directly related to demands
placed on me or tasks that I have assumed. As a consequence, since they are
mainly a question of employment of my personal time, I would appreciate the
appropriate consideration. As Bacula becomes more and more important and
more and more used, we need to find ways to spread the responsibility for
implementing new features and resolving problems. I would really like to be
able to implement everyone's special request, resolve all the problems, but
it is impossible, so many of the things that were previously rather simply
resolved will become a bit more formal -- this comes with a program that has
many more features and is becoming increasingly critical for many people.
I mainly view my task from now on (as long as I remain capable of carrying it
out) as ensuring the long term survival of Bacula, which means trying to find
the right structures for it, and to maintain the style, philosophy, design,
consistency, stability and quality of the code and features that go into
Bacula.
#4 This too is a rather big topic which I'll probably explore more in detail
later. However, someone recently wrote: "Consider that Bacula needs both to
become self-funding and to motivate project participants to maximize
their contribution of development time, testing, documentation, etc., Funding
initiatives should be designed so that they do not act as a disincentive for
the participant to participate to the full in other areas."
This is an enormous problem that I feel is now facing the whole of Open Source
software. As big companies are realizing that Open Source is good quality and
can save money, their contributions might in the short term disrupt some of
the current Open Source projects (buy outs, lots of big financial
interests, ...). Even the concept of paying a few Open Source programmers
for serveral months to get the next Debian release out on time has created a
stir. I suggest that this problem or dilema of volunteers being squeezed out
or demotivated by paid employees, has been "solved" long ago. You need only
look at charitible organizations to see that volunteers work along side
people who work for a living for a charity. As far as I know, the fact that
Care, the Red Cross, or Medecins Sans Frontiers have paid "volunteers" does
not seem to stop people from being non-paid volunteers nor does it stop
people from contributing to those charities.
However, Open Software projects have not learned how to deal with this
problem, nor have corporations that benefit from and increase their profits
by using Open Source software projects learned how to contribute to those
projects (some have, but I believe they are the minority -- though possibly
quite important). Hopefully, Bacula and you our users will find the way
forward in this respect.
Well, there you have it or at least the outline, though I admit it is probably
way too much to digest at one time, and IMO the above is only the tip of the
iceberg.
Regards,
Kern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
