[Gnue-dev] Via Libre's contribution to GNUe

[Federico Heinz]

Some months ago, the development team of Vía Libre went shopping for a
framework on which we could develop our solution for small and medium
organizations. It had to meet a lot of requirements, both technical and
philosophical, because we want the resulting program to kick serious ass
in the functional front, but more most importantly we want it to be free
as in freedom.

We looked at GNUe, and we found there was a lot to like about it. In no
particular order:

* a great design
* a wonderful vision
* the right license
* an active, friendly development community

We also knew that GNUe was not ready for prime time: there were and are
implementation issues to be addressed, some of the stuff is still not
there, but we looked at the last two items of the above list, made sure
that we shared the vision and goals of GNUe, and decided that those were
not intractable problems. We are fortunate enough to have secured
financing for our project, so we knew that we could dedicate the effort
needed to solve (not work around) any issues that could come up.

We still think we did the right choice, and if we were doing now the
research we did then, we'd choose GNUe all over again.

But we are having trouble with things that weren't part of the bargain
as we saw it then. We find that the main obstacle blocking us from quick
progress is not technical in nature, but... practical? political?
bureaucratic? I don't really know how to call it.

The problems that have arisen so far are two:

1) we have submitted patches to GNUe that are still to be integrated
into the project's trunk. These are patches that have been extensively
discussed on IRC, don't break anything since they are 100% backwards
compatible, and add functionality which has been consensually agreed to
be useful. We have gone through all the licensing hoops required by the
FSF to contribute significant work, basically the only thing standing
between these patches and their integration is the amount of time the
project's managers can dedicate to reviewing and merging them.

2) we have several issues we'd like to discuss in detail with the
project's main developers, since our work has shown again that some
added functionality (again, all backwards compatible) is needed for
certain jobs that enterprise applications must address. Again, the main
problem is the time available to the main developers to work on the
project and discuss with us (we're competing for the same scarce
resource on two fronts here). And once we discuss, settle and implement
the needed changes, we still can look forward to a rather long delay
until they are incorporated into the trunk.

This is hurting us. I mentioned earlier that we have secured funding for
our project, including the work we do for GNUe. But funding has two
edges. It enables us to have 3.5 great developers working full-time in
the project, in exchange it requires that we meet deadlines. About two
months ago we produced a patch that enables a single data source to
access and update multiple tables. We did it because we needed it (and
we're sure GNUe needs it). The functionality provided by this patch is
vital to our progress, yet more than two months later it's not in the
trunk. If we had waited for it to enter the trunk, we'd be either
massively behind schedule, or our code would be full of ugly kludges
meant only to overcome a limitation that we had already lifted, and
which would have to be removed further down the line.

It is even hurting our relationship. The need to incorporate these
patches into the code we routinely release had forced us to publish a
branch of GNUe, because otherwise the program won't run. We don't want
to do this, we dislike it as much as the next GNUe developer, the *last*
thing we want is to be perceived as rogues, we are counting on
cooperative development, and we put our money where our mouth is. But
the current situation makes us look unnecessarily bad.

Maintaining this separate branch is a story of its own, too. As GNUe
keeps advancing, our branch becomes outdated and we have to somehow
merge the changes regularly, which consumes a great deal of time from
our folks, time that would be *much* better devoted to writing code.

We need to fix this somehow. We appreciate, even admire the work done by
the project designers. We share the vision. We share the philosophy. We
are committed to GNUe. We have bet the success of our own project on it.
We have the skill, the will and the time to contribute greatly to GNUe,
and our contributions have the added value of being validated by the
actual needs of a real-world system which we hope will aid quite a bit
in the dissemination of GNUe at least in Latin America.

We need all this to be acknowledged by the GNUe team. I don't mean the
credit, we all know how that works in free software. I mean that we must
put some mechanism in place by which our contributions can flow more
freely into the GNUe tree. It must be a mechanism that doesn't tie up
our already overloaded project managers, so we can have time to discuss
with them on design and implementation issues. And we need this
mechanism to be in place fast, because every day our branches diverge
more, and that's the last thing any one of us needs.

The only way I can see to handle this is to grant commit privileges to
aprono (or anyone of the PAPO team, for that matter). By now, you guys
have probably figured out he's a conscientious and able person, and well
aligned with GNUe's goals. If there's an alternative solution, I'm eager
to hear about it, if there are arguments against it, I'd love to discuss
them.

The current situation is hurting both PAPO and GNUe, let's do something
about it!

        Federico

signature.asc
Description: This is a digitally signed message part