OpenSource

I'm not convinced that moving SoulseekQt to an open source model at this point will really aid its development that much. First of all, the open source model demands a high degree of community participation, and as it is right now the level of user participation is not very high. This is especially true on the Linux side. I almost never hear from Linux users. It's great for me, since I can only work on a few things at a time, but I don't see the need to change the scale of development so far.

Also, while there are very well managed open source projects out there, first and foremost in my mind is Qt itself, open source development for smaller products doesn't guarantee better software quality. If that were true you wouldn't be asking for SoulseekQt to be opensourced, you'd be using one of the already existing third-party clients instead.

Finally there are a couple of other reasons which make open sourcing the Soulseek clients unappealing to me right now. First is that it opens the client to the possibility of fragmentation, which can become a major annoyance, for example, if someone out there starts changing the peer to peer or file transfer protocols. They might very well think they're improving on those things, but end up hurting the overall network's compatibility. Even more likely is the possibility that someone will try using the code base to make malicious changes to the client, ones that could be used to hamper the functionality of the distributed network and other network operations.

The last reason is more selfish, which is that SoulseekQt is built on top of a data management system I've developed over the last few years. For personal reasons, I'd like to keep it private for the time being.

I don't expect every user out there to agree with my reasons, but this is where I stand on the subject. If I truly believed open sourcing the Soulseek client would make a major positive difference for the system I would, at least in some form. I just don't think that's very realistic.

I would also like more openness then we have right now but agree that fragmentation is often a problem with open source desktop software implementations, even more with indie network protocols. Since I moved to Mac in 2006 using soulseek or eMule has been a problem for me. I was a very active user on both networks and not having a good client I've been away from the network since. Now I am back, and I saw some opportunities to improve on the interface and was looking to see if I could manage some interface tweaks.

I understand and will not bother you further if you don't change your mind, but what about a mixed effort?

How about an official binary distribution but consisting only of the headless part and a protocol (either native bindings, tcp or even restful json) between a daemon and GUI? The QT GUI could be open sourced or not, but if some protocol or API to interact with an official daemon was documented, each platform could have an open source initiative for a Native GUI. It could be much alike museek but the binary itself could be centralized rather then open source. This could prevent fragmentation, it would keep you data management layer closed source. All the opinionated implementation and almost all features and network communication code would remain as is.

The main reason I am revisiting this post is that I believe final user experience could potentially improve by efforts of others. i.e. On the mac, if you take a look on iSoul (previously Solarseek) and compare to the QT experience, it is noticeable how much easier it would be to use iSoul, and how much mac-like iSoul is. But on the other hand it lacks stability regarding network connection and folder scanning. iSoul is particularly faster and uses less memory on my system. Competition in user interface is great, since one client can be inspired by another. Clients that already exist could be encouraged to adopt such library and effort in reverse engineering and reimplementing the protocol layer would not be wasted anymore by those already investing on open source clients.

Does this idea seem good to you? Since only you have access to the code, only you can measure the effort and reason how this could be achieved. I found this post while looking for a good daemon to make an experiment coding a native cocoa GUI, maybe based on iSoul or not. What I like to do is solve Human Computer Interaction and User Experience problems by coding good UI. But needing to code the core stuff or using partially stable network implementations didn't seem that appealing.