[Debloat-proposals] Comments on the ISC deliverable section

[Dave Taht <dave.taht@gmail.com>]

A) Explore the elements needed to build an economically sustainable
open source CPE/Home Gateway that would be operationally used
throughout Comcast and the world.

Cool!

B) Explore and deliver a functional requirement document for a initial
generation of open source CPE/Home Gateway.

This is really, really difficult, and an example of the problem we
face in developing specifications in our over-complex world.
Functional requirements documents can be kept short, say, 3 pages, or
made unbelievably long - say, for example, the DOCSIS specs, which
last I looked weighed in at well over 1000 pages.

An example of this sort of rat-hole: "Must have IPv6". Well, how much
of IPv6 do you want? Do you need IPsec? How about HIPL? SCTP? Secure
send? etc?

To take on another rat-hole: Does Prefix delegation count? does PD
have to integrate with bind9, downstream with autoconfig clients,
upstream with dhcpv6, and if so what other parts of dhcpv6 are needed?
To read more on just this one problem see the current features list of
dibbler[1], and note that there's only one guy working on that.

I would suggest limiting the scope of this to 'short, high-level
functional requirements document' to avoid sinking into specification
hell.

I do note that using "IPv6" as a checkbox item hasn't worked yet,
however, despite years of the government trying, and the current set
of "IPv6 certified" products is disappointing, to say the least.
Feeding back into that certification process would be good.

A point I tried to make at the meeting was that I wanted to separate
the 'feature development' from the 'end product'. dibbler and isc-dhcp
need features developed and tested - which can then, later, make it
into products. radvd needs love, as does ipsec in general, and there
are too many other packages to list, here, that in the end will make
or break a successful deployment, when finally integrated by the
vendor.

So, in conclusion I would like to replace this bullet point entirely
with something like:

"Assess the health of various required-for-good-cpe projects (number
of developers, development activity, end-user usage, funding level)
and provide a plan for moving them in the directions needed".

Which is far, far, far easier and more useful than a functional specification.

C) Perform a risk assessment of open source licenses to insure the
structure of the license will support a sustainable ecosystem
particular to BSD/GPL open source licenses.

As I noted in the meeting it was my hope that 14+ years after the
phrase 'open source' was coined that most companies would have
developed a strategy for dealing with this that we could crib from.
That said, I concluded, days later, that some assessment is needed.

I can provide a list of packages and licenses to all that are used in
the openwrt project - but the point to remember is that most of the
license conflicts have been resolved over the last decade, and the
vast majority of software in *userspace* allows for *non-viral
linking*. I'm hard pressed to think of anything left, anymore, that we
link to, that doesn't have a permissive license. And there are far
more licenses than merely BSD/GPL in use - there are apache licenses,
free beer licenses, the isc license, the sun license etc.

What is a risk assessment, exactly, in this context?

Revised wording:

"Perform an assessment of open source licenses to insure the structure
of the licenses will support a sustainable ecosystem."

4) Build a business plan enabling fund raising/partnerships and
building a formal “home” for the project as it progresses.

If it were up to me, this would be number 1. This is a task too big
for any one company or developer group.

5) Preliminary assessment, with rough timelines and budgets, for
additional development of a specific OS (if available), or ground up
development (if no appropriate OS is found) to a level suitable for
deployment as an R&D or production platform, including initial
requirements for necessary management and testing tools.

As for this last one, I'm going to take it on in the next email.

[1] http://klub.com.pl/dhcpv6/#ROADMAP

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com