openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Pöml <>
Subject Re: Ditching our mirror system for an inferior solution?
Date Wed, 18 Apr 2012 22:35:51 GMT
On Sun, Apr 15, 2012 at 07:22:55 -0400, Rob Weir wrote:
> Have you ever thought of getting others involved in maintaining the
> software?   For example, it could be an Apache project, to maintain
> and further develop the software?

Of course: even before I started, I made the decision that this becomes
open source. A solution that is not open source would not have made
sense because it couldn't have been long-lived. This decision very much
influenced the design, because I tried hard to keep out project-specific
stuff, and to make it modular, adaptable, understandable, and built on
modern components (which made me a very early adopter of the Apache/APR
DBD framework). The uptake of MirrorBrain became very good, given that 
- there are only a handful people in the world who care that much about
  sophisticated download redirector (mostly large projects)
- projects don't simply replace their mirror infrastructure just for
  fun, because that's usually historic infrastructure grown over a long
- many projects have specific constraints in their mirror infrastructure
Nevertheless, looking at there is a number
of projects that took the step to renew their infrastructure. All these,
or at least the major projects of them, rely on MirrorBrain and have
contributed to it. Either by testing, documenting, or by submitting bug
reports and fixes. So MirrorBrain is not really supported only by
my person.

Part of the equation in this open source project is to increase the user
base to increase the likelihood of good contributions. However, as
usualy, only a fraction of users is willing, able and has time available
to contribute significantly. A user base of 10 or 20 is much for a
software of this kind, but it is small in absolute numbers of users
resp. developers who are willing to contribute (some of the users could
be developers after all). Given these constraints, I am very pleased
with the number of contribution from the user base! 

I am familiar with the ASF a bit (partly because I maintainted Apache
httpd for openSUSE for nearly a decade, and made some small
contributions). I held a speach on MirrorBrain on ApacheCon EU 2008, so
you can be sure that I have thought about donating MirrorBrain to the
ASF :) I am fond of the idea, and wouldn't have a problem with it, but
some parts of the code are also owned by my previous employer, Novell,
so I would have to talk to them first. That's what stopped me from doing
it, so far. If there is interest, yes, I'd would be happy to discuss

However, this wouldn't rise the number of contributions a bit. As
described above, by nature of the software, the number of users (and
therefore developers) will probably remain small forever. Unless the
good name of the Apache umbrella will change popularity drastically ;-)

Of course, if the existing development infrastructure is so bad that it
keeps developers from contributing, then it should be exchanged. But I
hadn't heard concerns so far. 

Another good strategy, IMO, in getting others involved is to discuss
with authours of similar frameworks, to join forces. This has been very
fruitful in the past, including folks from Fedora (MirrorManager),
Mozilla (Bouncer), SourceForge (inhouse solution), Mandriva (Geo McFly),
Debian and others. For project-specific reasons, it is not that easy for
everybody to use a common solution suddently.

An example how difficult it can be to migrate from one solution to
another is When OOo went live with MirrorBrain 2 years
ago, we had been working on the migration about 1.5 years... okay, that
was not for techical reasons. On the other hand, experience shows that
it can be faster of course. TDF mirror infra was completely up and
running in 2 days.

> I think increasing the base of people who can support MirrorBrain is
> critical if we are to rely on it.  This would be true of any critical
> piece of project software, web servers, version control, wiki, bug
> trackers, etc.  We want to use quality software, but we also need to
> avoid single points of failure.  A system that is reliant on a single
> person's effort, no matter how technically elegant it may be, is
> risky.

Then increase the user base by using it. Participate. SCNR ;-)


View raw message