I can see how it looks but actually most of the underlying libraries have already been adapted or are almost finished being adapted for segwit. Since segwit is not live on mainnet, most are not released (either still in PR form or merged to a development branch). As a software developer, I think you can appreciate that libraries cant actually release a segwit supported versions until segwit is released as final in 0.13.1. Obviously consumers of the libraries cant update for segwit until the libraries are released - you get the idea. I wouldn't be too concerned about the adoption chart, it's just very difficult to reflect the actual state of affairs. For example Trezor is marked as wip, but they have had an updated, but unreleased firmware version for many months[1]. We are in the process of planning a migration guide and updating the existing development notes[2]. Additionally, many companies are already planning to update their services for segwit.

Regarding BIP9, it's purpose is to co-ordinate *miner upgrade* and activation. The starttime delay is simply designed to avoid miners signalling before the soft fork has been made available for general release; so the starttime prevents unreleased software from setting the version bit prematurely. The whole BIP9 state machine allows predictable activation. Non mining full nodes are under no constraints to upgrade on a specific schedule, which is by design of soft forks. Signalling will not begin until the first diff retarget period after the starttime of 15th Nov. Practically it means there will be a minimum of 4-6 weeks at the very least before activation can happen.

[1] https://github.com/bitcoin-core/bitcoincore.org/pull/30#issuecomment-217329474
[2] https://bitcoincore.org/en/segwit_wallet_dev/

On Sun, Oct 16, 2016 at 7:20 PM, Tom Zander via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Sunday, 16 October 2016 09:47:40 CEST Douglas Roark via bitcoin-dev
wrote:
> Would I want anyone to lose money due to faulty wallets? Of course not.
> By the same token, devs have had almost a year to tinker with SegWit and
> make sure the wallet isn't so poorly written that it'll flame out when
> SegWit comes along. It's not like this is some untested, mostly unknown
> feature that's being slipped out at the last minute

There have been objections to the way that SegWit has been implemented for a
long time, some wallets are taking a "wait and see" approach.  If you look
at the page you linked[1], that is a very very sad state of affairs. The
vast majority is not ready.  Would be interesting to get a more up-to-date
view.
Wallets probably won't want to invest resources adding support for a feature
that will never be activated. The fact that we have a much safer alternative
in the form of Flexible Transactions may mean it will not get activated. We
won't know until its actually locked in.
Wallets may not act until its actually locked in either. And I think we
should respect that.

Even if all wallets support it (and thats a big if), they need to be rolled
out and people need to actually download those updates.
This takes time, 2 months after the lock-in of SegWit would be the minimum
safe time for people to actually upgrade.

1) https://bitcoincore.org/en/segwit_adoption/
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev