Subject: The future of NetBSD
To: None <netbsd-users@netbsd.org>
From: Konrad Neuwirth <konrad@mailathome.or.at>
List: netbsd-users
Date: 09/01/2006 14:11:58
Whilst certainly not competent enough to be in any role as contributor or
developer to the NetBSD project, I've been using NetBSD on various systems
since around 1.0.

Reading both Charles M. Hannum's original message (and Alistair
Crook's announcement as what I take to be possible context of the internal
discussion that preceded the first piece), from my very limited view I
could relate well to the general sentiment.  Having a little background in
technical project management, a few issues strike me about the current
state of NetBSD.  And a fair number of them boil down to the
leadership/direction in the Project, too.

Whilst NetBSD certainly remains to be a useful and versatile tool for a
high number of applications, I personally feel that it has slowed down in
the adoption and integration of new functionality; instead focusing
primarily in supporting yet more hardware (of course, always a noble goal
for an operating system, whilst at the same time necessary to even be in
the relevant set for modern hardware). But even there, some things are
obviously not progressing as fast as the market: I continue to be amazed
how much energy needs to be spent on getting NetBSD/amd64 to run on
specific pieces of equipment.  I won't iterate on all the other deficits
that have been named during the discussion (though personally, I'm most
amazed by how long the struggle for a production-ready LFS takes), but I
share the view that NetBSD losing its standing as an operating system with
the feature set t be a general-purpose OS.  Of course that's a perfectly
valid position to take: If the focus is on providing functionality for a
clearly defined set of circumstances. It would be a very legitimate
decision to make, if the consensus goes into that direction.

I would like to point out that I'm not all pessimistic: The work on Xen, at
least to me, is significant progress and changes the options my company has
in a very, very positive way.  We're in the process of rolling out a new
system built largely on a NetBSD/Xen foundation.  I'm most fascinated by
the work Elad Efrat is doing on getting a better security framework
introduced to the entire system.  But still, there's a lot to be desired.

Of course, the hard question is: What can be done about the situation? As
with all endeavors, it's mostly a question about humans.  Maybe the Project
(and to a certain degree, also the Foundation) should ask itself whether it
would make sense to ask specific key figures to return, looking on what
might be done to accomodate their coming back.  Of course, the question on
what could be done to get new people involved is always open and discussed;
maybe a new policy in that regard might also make sense.  For instance,
I've not yet seen the question discussed on how the Foundation can bring in
people other than the Summer of Code.  Are there any new research
institutions that would be interested in sponsoring NetBSD development, for
instance by having MSc or PhD students working on specific,
research-relevant parts?  Is there a list of things that are desirable,
where the Project sees itself in dire need of support? Would it make sense
for the Foundation to employ programmers -- and would companies or
individuals be willing to sponsor such full-time NetBSD developers that are
not under their control?  What can be done to encourage more code donation:
Should, for instance, there be some form of official recognition for people
who contribute significant new functionality or who finally solve
long-standing issues -- along the lines of a 'developer of the month' on
the website?  And, of course, what steps should be taken to further develop
the Project: Should it just remain an almost exclusively developer-driven
entity, or should other aspects of the Project be handed off to people who
are not, first and foremost, technically astute enough to contribute code?
Does the Project (or the Foundation) want to develop a roadmap for itself,
setting goals and targets for not just the Operating System?  And if so,
what resources is it willing to spend on those organizational issues?

For my company, we have decided to stick with NetBSD for a while longer.
We're looking forward to the NetBSD 4 release, and probably will stick
around after that.  But in the last year or so, we've looked at other
options much more often than in the previous years.

Konrad