easier said than done when everybody wants every fancy new feature 110% solid and yesterday.
Not everybody. What I want more than the fancy new feature is: honest schedules and honest self-appraisals. A vendor who promises me what they think I want to hear or maybe even what I really do wish I could hear is not as valuable to me as a vendor who tells me the bold bald truth no matter how much it hurts my proposed rollout schedule or how much it might help one of their competitors who can deliver $FANCY_NEW_FEATURE earlier.
It took a long long time for one router vendor in particular to pay any attention to a number of high-spending customers who said 'stop implementing the {3,4}-letter acronym du-jour protocols, or at least stop trying to integrate them into s/w we want to run, just fix the bugs the the s/w train we all run'. The lesson seemed to be learnt for a little while, then spent the next year trying (unsuccessfully) to abandon that release train. I can only assume what drives them is the either (a) desire to support slideware protocols early, and in code people actually try and use, (b) the knowledge that such slideware protocols, in aggregate across a large network, eat more router horse power, and thus sales-$$$, for those gullible enough to implement them, or (c) some combination between the two. I guess some time someone will realize routers are both hardware, and software, and shock horror both, if done well, can actually add value. [hint & example: compare the scheduler on, say, Linux/FreeBSD, Windows 95 (sic), and your favourite router OS (*); pay particular attention to suitability for running realtime, or near realtime tasks, where such tasks may occasionally crash or overrun their expected timeslice; note how the best OS amongst the bunch for this aint exactly great]. (*) results may vary according to personal choice here. -- Alex Bligh Personal Capacity