I don't recall Pactor's reputation being tarnished by poor AEA and MFJ
implementations. But if AEA's and MFJ's implementations were in fact
sub-standard, then they were doing SCS a favor by expanding the base of
Pactor-I users and creating an upsell opportunity to "the one that really
works". If they SCS failed to capitalize on this opportunity, the open
protocol specification was not to blame.
Today, the strategy of agreeing on open specifications and competing on
implementations is a major driver in computing and telecommunications.
Closed specifications make sense when the objective is to harvest a niche
market, but long-term adoption and growth require open specifications.
Metcalfe's Law: a network's value is proportional to the square of the
number of users.
73,
Dave, AA6YQ
-----Original Message-----
From: rtty-bounces@contesting.com [mailto:rtty-bounces@contesting.com] On
Behalf Of psussman@pactor.com
Sent: Sunday, January 15, 2006 11:32 AM
To: Joe Subich, W4TV
Cc: rtty@contesting.com
Subject: Re: [RTTY] ARRL Bandwidth Proposal - FCC Invites Comments
Joe raises an `excellent point. When PACTOR-1 was released by SCS, the
protocol was made freely available. AEA and MFJ made drastic cuts to the
specifications (esp. in the relm of A/D converters) while others used
software short-cuts that undermined the effectiveness of the mode.
HAL sure noticed that when they released CLOVER and remember G-TOR, that
'enhanced knockoff' of PACTOR-1. So when SCS released PACTOR-2 they did NOT
make the protocol freely available. After all their PACTOR-1 reputation had
been tarnished by 'cheap knockoffs' of their freely released protocol. Can
you blame them?
The protocol is intellectual property and 'releasing' it without insuring
safeguards against illegal copying or distorted (cheap) reproduction by
others must first be addressed.
Anyone who wants to monitor G-TOR, PACTOR, CLOVER, PACKET, etc need only
invest in the manufacturer's hardware/software. It is sure a lot better and
cheaper than building your own lab.
And.. as I mentioned earlier, requiring the manufacturer to make
available (at little or no charge) units capable of monitoring only is one
potential solution. But there must be a balance between supporting a mode
and remaining solvent. Hey, shades of napster and other licensed software.
Comments??
Phil Sussman
Clayton, Ohio
---------------
Quoting "Joe Subich, W4TV" <k4ik@subich.com>:
>
>
>
> > From: Bill Coleman
> >
> > On Jan 14, 2006, at 1:04 PM, Bill Turner wrote:
> >
> > > A question for the gentleman who wanted all digimode software to
> > > be "freely available":
> >
> > That won't fly. It's the PROTOCOLS that need to be freely available.
> > They need to be published and available to anyone who wants to
> > implement.
> >
>
> No ... protocols do not do a bit of good if a vast majority of
> amateurs are not software developers with access to many thousands of
> dollars in development tools. With analog protocols (voice, CW and
> even RTTY) building a relatively simple direct conversion receiver (or
> PTT TU) would enable any amateur to demodulate and decode any signal
> he could hear. That is not possible with many of the new digital
> systems.
>
> 73,
>
> ... Joe, W4TV
>
>
>
> _______________________________________________
> RTTY mailing list
> RTTY@contesting.com http://lists.contesting.com/mailman/listinfo/rtty
>
_______________________________________________
RTTY mailing list
RTTY@contesting.com http://lists.contesting.com/mailman/listinfo/rtty
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|