The road ahead: Software
October 19, 2012 Leave a comment
There’s a wide range of different applications that are for Direct Connect. There’s a bunch of clients, each with their own special niche or cool feature. The same applies for hubs.
Many applications promote the use of open-source, allowing multiple developers to add their thoughts and ideas to the product. Don’t like where the application is heading? Fork it and create your own. As is says in the DC++ documentation (paraphrasing); “eventually your modification may have a higher user count”.
The software that is produced are most often not code reviewed or tested very much. There’s only so many people that can write code or documentation, review code or test the application. The fact that people are doing much Direct Connect work for free on their spare time means that there’s only so much time in the ability to continue developing the software.
Most companies are structured around specific people writing code, specific people testing, specific people writing documentation, etc. This isn’t directly possible as people can’t be forced to do something. However, I believe that this means that people do what they like. By doing so, they don’t mind putting X hours into development of a feature if they feel that it was fun or interesting to do.
While it’s a novel thing to build the applications, it’s silly when people don’t envision the future. You don’t have to have a “business” sense or likewise to explain what you want with your product.
Each application should have a definite goal and specified stages where certain features are implemented. The goals can simply be “let us fix bugs X, Y and Z by the next version.” The goal doesn’t have to be “we must have X amount of users by the end of the year.” The goals should be sufficiently easy for someone else to do: that is, if you as a developer don’t have time to complete a feature, then someone else might.
Each application should strive for a certain type of freedom for its users. Lately, this freedom has come in the form of plugins for clients. While many clients have offered this ability in the past, adding this ability in DC++ will probably increase the diversity of plugins. The current DC++ plugin interface is C, so the goal should be to provide an implementation for C# (through C++/CLI and/or Mono) or Java users. Python and other languages could probably be incorporated also through middle ware plugins. A clear goal would be to have wizards for Visual Studio or Eclipse or Netbeans, allowing developers little time in having to set up their environment. Base classes could also be added that help common operations for plugin developers.
If the software is provided with the source code, a clear goal should be to have clear and concise instructions for building your own version of the software. Project files and scripts for automatically downloading and building the software can greatly decrease the turn around time for development. In fact, you can increase your own productivity if you don’t have to do fifty things each time you need to compile or pull down the source code.
While it is great that we have a lot of applications for the Windows platform, there’s still missing applications for Linux and Macintosh based systems. Applications like WINE on Linux help, but only so far. The need to have applications and developers for each platform is important.
An important part in today’s society is to provide applications for the mobile platform; phones and tablets. An interesting aspect would be to create native Blackberry, Windows Phone, iOS and Android interfaces. This would allow users to chat and share files through their mobile device. The network traffic cost could of course be an impact in the amount of users, but anyone with a flat rate plan would have no problem.
Easy as mobile devices are, another avenue may be adding support for Facebook, Spotify or other media directly in clients. Additionally, for example plugins in Facebook for DC could open up a new world of users. Just imagine that you can download and share photos from your hub straight onto Facebook, even while not being at home.
The road ahead
As more and more features get supported in each application, it is important to continually take a break and make sure that each feature is properly implemented. Any new user is a potential source of questions and requests. The important part is to not bury the head in the sand, but to provide ample support for users whilst trying to continue developing the product. Any time a product has a capability that will allow the user to extend it (either through someone else’s plugin or themselves directly) it will mean that the user is much more interesting in the continuation of using the product.
An application signing can be a great way to provide a receipt that the software is genuine and not tampered with. While this may cost, it will increase users confidence in the authenticity of the software.
Videos, articles and other media that can be used for helping users (either starting users and long time users) will always be considered useful.
Going through the list of feature request on a regular basis may provide a good insight in what users want.