[Xorp-hackers] Recent developments and patch submission

[Ben Greear]

On 03/07/2010 08:21 AM, Bruce Simpson wrote:
> Ben,

> I can't apologise enough for what has happened with XORP, Inc., even
> though it was neither my decision nor my responsibility. Ultimately,
> private investor's money, and a degree of credibility, has been lost.

As soon as xorp was made GPL, and xorp.inc made the decision not to publish
their changes upstream as they made them, then it ceased to make much difference
either way.  So, I'm sorry for the folks that lost their jobs, but other
than that, it doesn't seem to have made a large impact in the daily operations
of xorp @ sourceforge.

> Unfortunately, this does affect the sustainability of any effort which
> follows. It is going to make it more difficult to attract investment on
> a commercial basis -- word gets around.

There are people offering cash on the mailing list for help debugging xorp
configuration.  If I weren't already running a company, I'd try to fill
that need.  For that matter, I might consider it anyway.  It doesn't
take a big company to do this..a single engineer who understood routing and
understood xorp at least a little bit could do this on their own.

> I think I speak for the original instigators when I say that it was our
> shared hope that introducing a healthy commercial interest would
> vitalize development. Again, unfortunately, this hasn't happened, due to
> circumstances beyond my control.
>
> Having said all this, basic ground rules do need to be followed. It just
> makes life much easier for collaborative development if patches intended
> for submission go in an issue tracker.

A project needs an active leader or set of leaders.  As far as I know, only
you have commit priv for the svn repo.  If you are not actively picking
stuff out of the tracker and fixing up any bugs and/or patches in there,
then who is?

If you are waiting for xorp.inc.2, then how long will you wait?

What happens if no one ever funds a xorp.inc.2?

Even while xorp.inc was active and had cash, there was no one else committing
to the public svn repo.  I think that xorp.inc missed the whole point of how to
run an open-source project, but that is water under the bridge now.

> However, solving more general issues with piecemeal patches in the here
> and now, is going to take more effort and thought.
>
> It is regrettable that your requirements for virtualization weren't part
> of the development roadmap. Had they been, and had we had a better
> platform for collaborative development from the outset, then there might
> not be the wide gap that exists between your private git tree, and SVN,
> now.

A great deal of my code is just making sure xorp handles interfaces coming
and going w/out asserting and crashing.  Nothing in my code should hurt any
'normal' use of xorp either.  If it does, then it's a bug and I will fix it.

I think that someone who has interest and at least enough time to commit
patches should start actively doing so to the svn repo.  I think that the
patches committed do not have to be perfect, but they should be better
than what exists.  Performance is way less important than correctness.

>> I'm using git for my source control, so it's trivial to view/extract
>> each patch
>> that goes in later should anyone ever want to accept it upstream.
>
> I would argue that the use of git may make code sharing trivial for
> those who use git and are familiar with it, but probably not for the
> majority of the open source user base.

Anyone that can deal with xorp in any fashion can:

*  Install git and gitk
*  Clone a repository
*  run 'gitk' to view patches and history.
*  use gitk to export patches to text and apply them however they want.

For that matter, one can directly import back into svn from a git repo.
With commit privs, I could dump my entire tree back into svn and retain
the history and individual patch sets.

> Even for developers, hosting code separately from a main line of
> development makes things that much more difficult, even if they use the
> same source-code control technology.

I'd love to get all of my patches upstream.  Or, if you want to give me my own
svn tree on source-forge, I'll happily push stuff there.  But, as thing stand
now, either I keep all my changes totally private like it seems other developers
are, or I host my own tree since upstream is effectively blocked.

> It would be fair to say that there's infinite demand for free goods.
> Unfortunately, sanity needs to prevail -- open source is a work product,
> not a free lunch.

If you are implying that we should be offering cash for xorp.inc.2 instead of patches,
I think you are wrong.  I have written and made freely available more xorp code
than xorp.inc (with the distinction being 'made freely available').  Lots of other
users have also contributed small but critical bug fixes and testing efforts.  These
small bug fixes add up, and that is what makes an open source project successful.

But, the project must be able to effectively absorb these patches in a timely manner.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com