Open Sourcing Desura Thread - Desura

Hey Guys,

As i'm the only one working on Desura client due to a number of reasons I was looking into open sourcing the client aspect of Desura it self to allow the community to help out implement features and bug fixes faster and contribute this back into the client to benefit all users.

As it stands, the license im looking at using is dual license; GPL v3 for the open source side and a commercial license for the company side how ever the trademark, icons and logos are not included with this. Was also thinking of using GitHub to host the project with wiki and bug tracker.

What is your thoughts and ideas on the subject?

I say go for it. It would probably speed up when a Mac port would be available.

Edited by: Protektor

Gets my +1 so long as there's a decent level of quality control.

I assume you will still be doing quality control on the patches to make sure it doesn't become a mess right?

I'll say +1. This'd be really awesome.

I'm all for it Happy for the use of GPL as it stops (legally anyway) someone taking the source, closing it up & distributing it as their own. The dual licence is good and I wouldn't expect the trademark, icons & logos to be "open". It's just like many Open-Source games where the code is open but the assets/art are not.

The question I guess is how many coders are out there that could/would contribute - though if the code is there it allows people with a passing curiousity to tweak/fix something that they might end up passing back and the bigger Desura gets then the bigger the proportion of interested coders. I'd definitely take a look but no guarantees I can fix/implement anything

@Protektor - I'd expect quality control to be kept otherwise the first patch could crash Desura completely.

GitHub is a great place to add it - users can easily fork the code and submit a "pull request" asking lodle (or whomever at Desura) to take a look over the code and accept/reject the patch. Patches don't need to be accepted in whole - you can accept just the parts of the patch you want or just pull the patch into your development branch and tweak/test it as necessary before pushing to live. It's very "social" and you can place comments on source code changes, etc. I like their bug tracker too (integrates well with repository). (note: most of this paragraph is directed at general members that might not be sure how it all works, I expect lodle knows all this already )

@lodle - oh, also, have you read feilyne's post here?

@Zarius - GPL doesn't stop anybody from packaging and distributing the project under another name so long as it's still distributed under the GPL (it doesn't prevent commercial derivatives either).

Edited by: Cheeseness

I hope you have some expirience managing an open source project. That's an entirely different job than developing one yourself. And if you have any security vulnerabilities they will be found and exploited in a very short time so a complete code review with a different developer is a required part of preliminary work to open a piece of software. OTOH you'll be sure that your security does not rely on obscurity.

But if you'll manage it's a great idea. I can finally try to fix the selection buffer in Gentoo. ^^

Edited by: naryl

@Cheeseness - I've read the GPL The key parts it stops are "closing it up & distributing it as their own" - ie. the GPL enforces attribution and openness.

@naryl - that's a good point. Mind you people can and have cracked another prominent games distribution client even whilst closed-sourced. Good advice on a code review though.

@Zarius - No worries. Just clarifying for anybody who hasn't

I agree. Security through obscurity is poor form wherever it's practiced - it's just that you can't really get away with it in open source projects.

Beware that if you use the GPL, all the code must be under GPL as include GPL software in Proprietary Software violates GPL terms (this even at linking level). If you want to simply separate code from asset than go for GPL, but if you want to have a mix of GPL'd and Proprietary code, you should go for LGPL (which is like GPL but allows the use of code in proprietary derived and linked work).

Aside from that i'd be happy to see Desura open the client source, and eventually contribute.

Edited by: _Journeyman_

Thats what the dual license is for Journeyman, as the copy write holder i can license the company under different terms.

Love the idea of a code review just need some one to help out and do it. Security in Desura is all on the web server so should be no harm in open sourcing it.

Edited by: lodle

Some coding guidelines and standards would probably help the process of reviewing commits/patches (and give contributors something to measure their work against before submitting stuff).

i hold master degree in computer security i would like to help in reviewing code and report any thing if there is any problem. also open sourcing software is a good security practice not the vise versa. when you open the source you will know your weakness and you will be more strict in developing the software for that linux is more secure than closed source OS.

I like the idea of open sourcing it but is it really worth it? I mean you will then have added time of trawling through patches, reading up on them, testing them as well it all adds up.

Open-sourcing the client would be great!

This would be great.

Awesome!

Would especially like to see mumble integration, something like SteamWorks ( "DesuraJustWorks" ^^ ) (especially matchmaking and other multi-user stuff ) and something like XMPP-integration for chat and messenging and so on.
Open Sourced it would be a finger snip away

So yeah!
Definitely a PLUS 1 for open source!

Hey everyone, i'm Samual Lenks-- one of the project leaders/core programmers for Xonotic, a free opensource fast paced FPS.

First of all, I would greatly support the idea of opensourcing Desura client. It would be a major step forward with regards to the world of indie/free games, and i'm very much so sure that it will benefit your project in the long run.

Secondly, as you've had some questions/concerns.. I would like to give some advice on how to structure the project for opensource -- especially regarding repository and permissions, and code review. I've been around the block with opensource development for quite a while, and i've seen many different systems of managing projects. I think however Xonotic has one of the best systems set up, and it's fairly simple to work with as a developer. I would recommend using Git for managing the repository for code review. It makes separating stable/experimental branches very easy, and it allows for people to submit code for review without it being put directly into master immediately.

Basically, with git, you can have users with different levels of access.. And for example you can set it up so that those users can ONLY commit to their own branches, and not master itself. This is the way we manage our code while still allowing users to contribute freely. Another thing we do is set up a merge request system on our development tracker: The basic concept allows users to go to our git website and file a report with our redmine tracker which automatically adds the task for us to review the code and see if it's something we want in the game.

With these systems coupled together, it works extremely well for our project, and I could easily see it working for you too. If you have any questions or concerns, feel free to contact me.

By the way, I would recommend hosting the git repository yourself.. I always find GitHub runs into many different restrictions/problems with development, and it's more of a hassle than a help when it comes to work flow and setting up users... as I said, i've found that setting up the git repo yourself + redmine development tracker has worked best for me in the past.

This would be great on the Linux side, distributions might start including it which could bring in a lot more users to Desura and eventually more commercial games too.

lodle wrote: As it stands, the license im looking at using is dual license; GPL v3 for the open source side and a commercial license for the company side

I'm not clear what you mean by "commercial license". If you want to own the copyright of the whole software distribution, then your contributors will have to sign a contributor agreement -- to assign their copyrights away to the company. This is a good way to reduce the number of potential contributors and is generally not liked in the open source world.

Iodle wrote: how ever the trademark, icons and logos are not included with this.

If that's all you are concerned about, don't implement dual licensing/copyright assignment. Your trademark is protected under trademark laws anyway -- no need to enforce that via a copyright license.

Look at Mozilla/Firefox for example -- they are pretty strict about what can be called "Firefox" and what cannot. If you check out the Firefox source repository, the default build configuration creates a whitelabel version -- without any Firefox references, logos or texts. All necessary art is included in the repository and licensed the same way -- you can activate Firefox branding with a build option, BUT trademark laws forbid anyone else from releasing their product as "Firefox" or use the Firefox logos.

But regardless of which way you decide to go in the end, open sourcing would be a welcome thing.

Edited by: intgr

This is honestly the best decision you could make.

From a business perspective you have a lot more to gain than to lose. Since Desura is already a operating under a service-based business model, there is really no incentive to keep the client closed. Desure makes it's money from the service of selling games, not the client. The client is essentially a drain on company resources.

Having a closed client puts a lot of pressure on the developers and encourages users to scream "I WANT THIS!" "FIX THAT!" because they are powerless to do anything about it. While opening the client won't eliminate these issues, it will decrease their intensity.

Having a open client makes it possible to add value to Desura as a product at a lower cost to the company. It empowers users to make Desura the best client they can.

There are things to keep in mind when considering open-sourcing the client though, because it can be a difficult change for the uninitiated.

1. Makes sure that the GPL is the right choice. What is you want integrate with proprietary games, such as a Steam-like overlay? What if you want to sell client plugins? While I personally would prefer a GPL'd client, a duel license might not be able to solve these issues. (Google Chrome vs. Chromium is a good example of this situation.)

2. Make sure to manage the community. Take pull requests seriously. You may get paid, but contributors might not. It's important for contributors to feel appreciated so they are encourage to do more of it. Listen to the concerns of the contributors. Make sure community discussions are open, productive, and positive.

3. Enforce strict quality control. Give contributors an opportunity to improve their submissions before merging them. Discourage hit-and-run submissions.

4. Put even more focus the service side of the business. Have a strong service discourages forking which will help the client to move forward.

I highly recommend reading "Producing Open Source Software" before proceeding. It's available here: Producingoss.com

I hope Desura will make the right decision. Good luck.

About StylishHoBo's point two. IMO nothing encourages potential contributors to stop looking for a community to help and join yours than having a core developer available for a chat.

I as the only developer will always be around for a chat/help and direction of the client. Thanks for your tips and suggestions got a bit of reading/research to do before this goes through.

The dual license is so the company can do other things that the gpl doesnt allow and yes that would mean patch contributors going up stream would have to agree to this.

Edited by: lodle

Definitely go for it. There are literally no disadvantages.