Why is SDKBOX not open source?

Why is SDKBOX not open source?
0.0 0


My experience with Cocos2d-x over the last 2 years has been mixed, let down too often by quality issues. I’m not saying this to complain, anyone thats developed cross platform code will understand the challenges, plus thats not the point of this post.

The main thing that has given me comfort (and the main reason I chose the framework in the first place for my apps) is the fact that it is open source. If needed I can get in and fix issues myself. I’ve done this several times and contributed fixes back to the main project where possible.

SDKBOX has in my experience also been let down by frustrating quality issues. In my most recent app release two SDKBOX plugins have been causing crash reports from end user devices, in scenarios that cannot be reproduced here in testing. Investigating the cause without source code is obviously much harder, and forget any possibility of fixing.

Thats why I have to ask a question that has been asked before. Why is SDKBOX closed source?

This is essentially wrapper code around other companies’ sdks and published APIs, with some glue to bridge with the cocos2d-x runtime. Nothing proprietary to protect, and the argument that has been voiced previously that it needs to be closed source to maintain quality is hard to understand right now.

Why not adopt the same open source model as the Cocos2d-x project?


I’m not sure this needs to be discussed. SDKBOX is a company. They are separate from Cocos2d-x. They choose to be closed source. I’d e-mail contact@sdkbox.com if you want to voice your concerns. We don’t need a flame-war started.

SDKBOX use policy

Flame war? Thats a bit strong @slackmoehrle

My comments were neither angry or abusive in any way. I’ve posted in a forum category dedicated to SDKBOX, a forum in which SDKBOX employees participate.

If one user voices some feedback maybe thats useful to the company (separate company or not, this is a community forum as I understand it and SDKBOX is providing a service to the community). If others did join in the thread to agree/disagree then that discussion should be even more valuable to the company. Not cool to try and shut it down, in my opinion, I just don’t see any harm.

Thanks for the contact email though.


This should absolutely be open for discussion and I don’t think @pandemosth is trying to start a war but instead continue the debate by bringing their own experiences to bare.

It is - in my opinion - critical to question every company’s reasons for keeping a project closed source. Of course the decision belongs with SDKBOX but the opinions of developers who invest time and resources into using SDKBOX should not be prevented from discussing improvements to the service.

Personally I have found SDKBOX to be very stable, and have had no reason to access the source.

SDKBOX is a great abstraction for key services across multiple platforms, and I appreciate the proprietary nature of such an abstraction’s implementation as justification for a closed source project.

However I do worry that I am reliant on SDKBOX to provide fixes and updates as the API they abstract are updated. Making the project open source would provide the stability and flexibility cocos2d-x developers know and love.


I’m not saying you are starting one, but when others get involved one just starts. I want to avoid that.

This topic has been discussed a number of times already. There isn’t anything new to talk about. SDKBOX is it’s own entity. If you have feedback, e-mail is best.


I understand your concern, I thought open source is a great idea, that developers will contribute feature and patch fixes when I was maintaining the first generation of SDKBOX known as plugin-x.

Soon I found out simply open source it is not enough. I rarely see any contribution for bug fix to plugin-x, to keep it up-to-date and adding new features, you really needs a dedicated team working on it. That’s why we decided that SDKBOX would be close sourced. And we’ll create the plugin as a service to the SDK providers and with the revenue we created a team to make it much better.

Why dose it has to be close sourced? It enables us to build our own proprioritory technolegy like LiveOps, also it makes things on the business end much simpler. Different companies have different policy towards open-source and we don’t have to deal with that. But the most important thing is that now you can guarantee that there is always someone addressing your problem with SDKBOX.

Couple developer actually share crash analytics with us, we did monitor live crash data and address them. I can’t say SDKBOX is 100% crash free, but I’m pretty confident you can count on SDKBOX as a stable product. Because we keep a close eye on the crash data everyday. If you have specific live crashes please let us know, we’ll try our best to address them.


Thanks @nite, appreciate you contributing to this discussion and thanks also for following up on one of my two current stability issues. The other one is here - Tune plugin crash (JS)

So ideally yes, a stable SDKBOX where we, as users, don’t feel any need to get under the hood to troubleshoot and fix issues would be great :slight_smile:

Personally I still believe the wrapper code around the 3rd party SDKs would benefit from being open source (LiveOps or whatever else could still be closed, as well as any that have restrictive licensing). Even if contributions were minimal, it would still enable collaboration on fixing issues, especially more obscure ones. When your developers are asking for PRs against the sample projects to try and work out an issue, suggests opening up to that level of collaboration would be beneficial. Just my opinion though and I understand there is internal business context that I cannot comment on.

In any case, are there plans for a more structured approach to issue reporting and tracking?


You could make it open source, but do not accept any pull requests =)
For example, I need SDKBOX compiled with c++_static right now but I don’t have it. I could easily solve it with source code, but I can’t, nor it will be solved soon… So I’m droping the usage of it…
Interfaces should solve problems with LiveOps =)


+1 open source SDKBOX for cocos2d-x.

For example, InApp purchases is important part of the game, but without sources you cannot debug and understand what is really wrong.
Why i have error “[GoogleAccountDataServiceImpl] getToken() -> BAD_AUTHENTICATION” on one of my devices when InApps in other games/apps have no error on this device?
Why its segfaults with Google reserved product IDs for testing?
All of this is forcing us to implement InApps by ourself, without SDKBOX.


Same here, with the ads sdk. It is great as a start, but when things get dirty, it’s impossible to figure out what’s going on inside :tired_face:

If it is close-sourced I would expect at least to have a very decent documentation, but in fact I realised it is not up to date in some cases. For example the field “strategy” for the “placements”… the documentations says it can only be “round-robin” but in the example I also saw “weight”. So it makes me question, can it also be something else? :slight_smile:

There are many other fields I must guess what they are because I can’t find any documentation about them. Also there are some things I think that are missing, for which I just must assume sdkbox is doing some black magic for us. For example, to use admob, google documentation says that first thing that needs to be done is to initialise their system with the application id, but this parameter is not even specified in the sdkbox configuration, so I don’t know what’s going on?

In any case I do appreciate a lot your work, but in my opinion there is a lot to be done here.

For now I will skip this SdkboxAds plugin and try to write my own manager, trying to make use of the individual ones.



So sorry for the SDKBoxAds’s document.
We will improve the document and explain all the fields.