The road ahead: Competition
October 19, 2012 Leave a comment
Nearly always when you have a component, resource of item you own, there’s someone else that want to compete with you and beat you with the better product.
In Direct Connect, we can clearly see this competition when it comes to client developers trying to get more users than other client developers. Hub developers vs other hub developers. Hub owners vs other hub owners. Protocol maintainers or proponents vs other protocol maintainers and proponents.
Competition comes from a desire to perform better than their counter-part. The end state is that users have more options (in software or elsewhere) to choose from, thereby allowing both niche and generalities in software and content.
Competition in the present
For example, the initial NMDC client could only connect to one hub at a time. As such, if you wanted to be in multiple hubs, you had to have multiple instances of the application open. When other clients started popping up, they supplied the ability to be connected to multiple hubs at the same time. This provided a clear competition between the two sets of developers as one party could say “hey, users, choose us since we can do this better and you’ll avoid hassle”. The end result was that every client got updated to have this functionality, which meant that users benefited greatly from this exchange. Now it’s almost unthinkable to have a client that can only connect to one hub at a time.
Direct competition can even come from those who help your product: say, if you say “no” to a particular feature, then they can create that feature themselves and distribute the new changes. This is how most client modifications of DC++ arose: the developers of DC++ felt that a feature was too experimental or didn’t follow according to the “mainstream” user, which meant that the feature wouldn’t get included. If a developer wanted this feature themselves, they could simply add that to their own version (and kind as they were, distribute it to others). For example, the use of hashing was an experimental feature that first saw the light of day in the modification BCDC++ but was eventually merged back into DC++.
Competition from the past
An often over-looked problem for software developers is that you do not only compete against the current set of applications or fellow developers. You compete with yesterday’s products. That includes your own product. DC++ has notoriously this problem: when hashing was introduced and became mandatory, a lot of users simply didn’t upgrade as they felt the feature(s) were not enough compared to the downside of hashing. For example, at LANs where you have no (less) bandwidth problems, the need for hashing may (seem to) become meaningless as you can simply transfer the files so quickly. The problem for the current client then is that users don’t want to upgrade to the flashy new version, as the old versions are perceived as better. This means that while you can out-smart your current competitors, you must not be able to manage your past self.
The competition from the past is also easy to spot when it comes to upgrading: upgrading is (considered) difficult and cumbersome. It takes time until people have moved from one (possibly insecure) version to another (hopefully better) version. Any form of automatic upgrade management can provide a good venue, like how most browsers do today (they upgrade without notification and without any form of user interaction).
An interesting management of handling past implementations are to provide an “in-between’ version, that incorporates the good from the past and the present. For example, the current DC++ client require that all files are hashed before they are shared. This is a perceived problem for LAN users (as explained above), but perhaps there’s ways around it. What if you hashed, say, the path of each file and called that ‘the file’s temporary hash’. These files and the temporary hash would then be included in the file list of that user. When a file is properly hashed, the temporary hash goes away. If another client connects and tries to get a file that only has a temporary hash, then that file moves up in the priority queue for files waiting to be hashed. When the file is hashed, the client can send back “hey, this is the new real hash”. That is, let all files be available for browsing and responding to (text) searches whilst not allowing people to actually download those files before the file’s been hashed. (I understand that this would be an undertaking in the software.) The out come would mean that you no longer compete against yourself.
Competition between users
In Direct Connect users also compete with other users when it comes to slots and hub bandwidth.
A slot is one potential upload channel. That is, if a user has three slots open, only three other users can download from them. That is, each user is competing with other users on the availability of slots within the system. Those users who have a fast connection are also able to quickly get their content, meaning that slots get more frequently available. The addition of including ticket systems and the ability for uploaders to decide who they grant additional slots to also provide a new dimension in the hunt for the slot. There are not many other file-sharing systems that behave this way, and I believe this is one of the reasons Direct Connect is prevalent as such: it promotes fast connections, small files and the ability (for the uploader) to manage their resources (bandwidth), all the while allowing the possibility of slow connections and large files.
The hub’s bandwidth is the primary reason that DC scales relatively poorly (compared to e.g. eDonkey); DC rests upon hubs broadcasting of information to most or all clients. That means that the bandwidth of a hub is crucial. For example, if the hub have 1 Mbit/s upload capability, then it is bound by a certain amount of users it can manage. Some hubs manage this resource by restricting how often you can perform certain actions. For example, the ability to search is often restricted to once or twice a minute. Sometimes only active users are allowed to search, etc. This means that as a simple user, you are competing against other users: if you can search, then that means another user might not, etc. There’s relatively little you can do as a user to fix this, beyond perhaps avoiding passive mode and encouraging the hub owner to get a better connections.
Competition from other systems
While the developers of the current system can discuss and argue about internal stuff, there’s an outside world as well. There’s a variety of different protocols and systems just waiting to (further) push down DC (sometimes, they can do so albeit unintentionally).
In the past months, we have seen more and more BitTorrent websites use magnet links. These have previously been an almost exclusively DC-resource. As such, DC client have owned the magnet link resource. As more and more BitTorrent sites require magnet links, so do the BitTorrent clients. That means that the DC clients now must compete against the BitTorrent clients for the ownership of magnet links. This is a battle I believe we cannot simply win, but I think there’s way we can still come out on top. DC and BitTorrent uses different information in their magnet links, and it’s easy to spot the differences. The DC clients (that previously at least) that own the link resource, should prompt its users about unknown magnet information. If the user can then specify that this new magnet information is actually for the BitTorrent client, then the DC client can simply redirect those types of links to the BitTorrent client. That means that DC owns the resource, while those who want to use BitTorrent isn’t left in the dust. Likewise, I believe the same option should go in the BitTorrent clients; if they discover a DC magnet link, then they should try and send that to the installed DC client.
While some systems do not have an intent on diminishing the DC user count, it may be in the system’s nature to do so. If the user isn’t using DC, they’re using something else.
The road ahead
There are no clear cut ways in steering clear of competition. The only way to stay ahead, is to invent features and come up with ideas before your adversaries. When it comes to other systems, the key is to provide ways of attracting users while still giving that system the small part of control.