Sure, I think there are things to be open and engaging with the community about, in particular things that are factual and known quantities, but there are things that IMHO should be not discussed also which are things that are more speculative or wishful thinking/best intentions in nature and the like. There are certainly pros and cons to things no matter how it is done, and selecting one communication method for a given thing over another is a process of weighing those pros and cons and coming to some kind of conclusion and accepting the results either way while simultaneously knowing that no matter what you decide to do - share information or withhold it - there will be people out there thrilled to hear it and those who are upset about it, or there are people ok with not knowing and those who are upset with not knowing. It's just a given that everyone can never be simultaneously pleased because of human nature. The key is to not get tied up in an irrational place of trying to please everyone, and to make sensible decisions that find a balance in the middle where business objectives can be met, and you share as much information as you are comfortable and willing to share with the public without delving too much into fantasy land or excessive speculation before things gel into concrete decisions such as product/feature releases etc.

One company may choose to do things in a way completely the opposite of another company in this regard, and I don't think there is any one official "best way" because as said above it is a game of selecting a preferred set of pros and cons and the consequences (good and bad) of both. Personally however I have found that the more open and public a company or project is about discussing some of their future plans or ideas are for a product, the more likely that a fraction of the listeners out there are going to interpret the words as promises and want solid release dates and other commitments or try to hold the company/project to such commitments even if the company never stated they were guaranteed. Not only can one with the best intentions end up promising things that they should not before they know they can deliver (such as No Man's Sky for example), but even if one does not promise anything many people out there have a way of spinning what they personally would like to see happen into imaging that they were promised it.

People can feel upset about something not being communicated to them and having to wait to find out, but in my observation over time if a company puts out a good product that they stand behind, people will be happy about it even if they didn't know all the details in advance etc. and that people tend to be much more emotional and let their imaginations go wild and turn into an artificial reality when they're hyped up with promises or even speculation about what might appear in a product eventually, even if the company genuinely planned to do it.

It really falls into "don't make promises you can't keep" really, and with so much of it being speculative to begin with, so many variables that can delay a product's release or cause a feature to get axed due to lack of resources or time or complexity etc. - making claims and promises even speculatively can be very harmful to a company's reputation.

Personally if I were running a company I'd be more comfortable having a reputation for being silent about things and people grumbling about that, then putting out great products that people love and praise than I'd be openly engaging with people to let them know everything I was doing and have them rip me and my company apart thinking everything was a promise, and feeling like I needed to defend everything I did, or put a webcam over my shoulder to let my customers watch me type out the source code as I wrote it.

I like to find out information about games in advance too and feel some excitement about it, but I'd rather not be told things speculatively that end up not happening in the end due to internal business decisions or other unforseen circumstances over time. That's just me personally both from the perspective of a customer and a developer. I know everyone does not all feel the same way about that though too, everyone has different needs/desires and that's ok.

Overall I think CDPR released reasonable information and came through in the end on most of it though in a nice middle ground. If they planned to do some things with the game that never made it in, I'm not going to burn them at the stake for it and overlook all of the amazing things they did plan to do that they did accomplish though. Anything missing, including the Linux port is IMHO a minor thing in the grand scheme of what they did accomplish and give us in the end. :)

Apple is not embracing Vulkan. They are focusing on their own graphics API Metal on both macOS and iOS.

Thanks a lot for the detailed information about this schmerl :)

Going by the replies in the OP, it unfortunately looks pretty bleak. I had hoped Witcher 3 would be released on Linux at some point, so I could buy and play it, but it looks like CDPR have simply moved on to other things now, and aren't bothered about Linux. Pretty sad for a company that embraces DRM Free-ness.

If Witcher 3 worked via wine, it wouldn't be such a huge deal, but from what I read the game doesn't really run there at all. "Garbage" rating and so on.

Exactly. It already shows how backwards thinking they are. But not just that. They don't update their OpenGL either.
Not yet. But things are moving with DX11 support gradually improving in Wine. Note that they didn't say they cancelled all such plans. They are still "exploring" something. I suppose it can mean they'll give it to subcontractors to port, but as I already mentioned before, it would most definitely mean a wrapper like TW2, in which case Wine is a comparable option as well.

I always assumed it was a contractual thing, that was signed before GOG went Linux. GOG seemed pretty tight lipped about it. I may look up those threads.

The lack of a Galaxy on Linux does not bother me either. However:
1. Cross-platform development is not that difficult nowadays. They could have gone Java for instance, but QT uses this point on advertisements also.
2. Galaxy on Linux could help to even out the platform differences, acting as a package manager of sorts. It could also help out the support team immensely.
3. They could at least talk about a Linux Galaxy a bit more.
4. This is Linux. Make some specs available, and we will build it! It could even help GOG integration with other projects, such as Lutris that could implement Galaxy functionality.

As it stands, I think that GOG lacks proper planning or adequate communication. I'm leaning towards both.

If people think Galaxy is bloated now, they'd definitely need a computer upgrade if it were implemented entirely in Java. It uses the Google Chromium engine though and I doubt they would have wanted to implement their own custom entire web stack in Java just for Linux support.

People think languages like Java are necessary to maximize portability, and while Java is always advertised that way, the truth is that it is totally possible to write non-portable Java applications and I've encountered them over time. Likewise, it is possible to write highly portable applications in C/C++. Highly portable applications can be written in just about any language, and it doesn't require using scripted/bytecode languages.

I do agree that cross platform development is much better these days however it is not zero cost to do it and to test it on all of the combinations that need to be supported either.

Sure, the could talk about Galaxy on Linux more but I really don't think that would do them any good and think it would do them harm unless they plan on releasing it a week later. Going on publicly about what your product is going to do in too much detail leads to things like No Man's Sky. Lots of promises that fail to deliver in the end. It's better to shut up and just work on what you're working on and let people know when it is done. People will disagree with that and they're totally free to as it is a subjective opinion, but one way or another, companies learn this over time by talking too much with good intentions and being unable to meet deadlines they've written themselves into a corner with. Eventually they learn to do less talking and more coding because people can be upset with you for not talking, but people get more upset when you talk a lot and don't deliver.

They're not going to make the specs available until they've finalized the Galaxy APIs to the point they aren't going to make any more core changes to it. Publicizing an API before it is finalized means people start using it while you're still making major changes to it as a part of your development process. That leads to 3rd party developers getting pissed off that the API keeps changing and all kinds of accusations that they change the APIs purposefully to break 3rd party clients and nonsense like that in the end. The other option is to keep APIs and end up supporting multiple versions of the API for backward compatibility if they have to change anything. That results in API bloat and support overhead as well as more paths for bugs to deal with.

They did state originally that they will document and publish the Galaxy APIs when they release the stable product so that 3rd parties can make their own clients if they wish and I truly hope that they honour that because a lot of cool things could happen, but as a developer myself I totally can understand a multitude of reasons why they would not want to publish any APIs until they ship a stable product, as I've been caught up in such situations as a dev myself in the past and it is a very bad road to go down for the reasons I stated above and many more.

Again, just my opinion and most likely a very unpopular one but I think it is a realistic one. Personally what I'd like to see happen and what I think will happen is that they will complete the highest priority subprojects including various Galaxy features and polish it off, and at some point go and polish off any bugs in their internal Linux builds (assuming they do this ongoing), and when they're ready to debut it they'll likely pre-announce it a day/week ahead of time to put Linux gearheads on notice and then put a build out in a day/week after that and go from there. Hopefully they do this before the stable official release comes out though (1.2?)

But... I could be completely wrong too, sometimes they surprise us in ways we can't anticipate.

True enough, but I consider such talk "PR-lingo". Maybe they'll still offer it on Linux one day, but it looks like they have essentially abandoned the idea, but leaving it open as a potential possibility in the future - hence that kind of language instead of a clear "Nope, ain't happening" message.

But if CDPR or a TW2-like wrapper subcontractor doesn't happen, there is at least a glimmer of hope with DX11 support slowly improving on Wine. I hope the game will become playable there, but it really ought to be professionally supported on Linux by CDPR. Witcher 1 should as well to be honest, but at least that baby runs fine in Wine.

What this means, however, is that it's pointless for me to buy Witcher 3, because the Windows days are permanently behind me. CDPR won't lose sleep over 1 such lost sale, but I mention it nonetheless.

gamingonlinux posted article that claim Linux port never planned.

Ooh. That sounds interesting. If and when they release their APIs to let users create their own clients, I'll try to make a super-basic client—installing and uninstalling, launching, and time-tracking are all I need. ^_^

Yup, I do not have a link to the video handy, but Marcin Iwinski and Destro did a video a couple years ago where they mentioned this. It is on Twitch.TV somewhere but next to impossible to find. Someone managed to dig it up last time I talked about it but I have no idea how they found it as I couldn't. Don't have a link to that either though, but it was within the last month in the forums here somewhere and on twitch.tv. If memory serves correct it was October 2014 or thereabouts.

Well, those are different kinds of being portable, aren't they? (binary/bitecode vs. source) I still think that going with Java (or some interpreted language) is a safer bet, while not the only possible way, as you made a point of stating.

As I see it, it really comes to what you say and how you say it. It seems GOG is being too careful about what they say. This strategy does have its downsides.

I understand that. But... isn't the planning phase supposed to prevent them from doing major core API changes? That also hurts them. It also breaks their own Galaxy, unless they always force everyone to upgrade (maybe that is quick)?

Furthermore, it is not as if no changes will come afterwards, and having an idea of how the API is planned would help us get get something up and running much sooner. A "subject to change" on the documentation should be enough to reduce complaints, I think. And if they publish the new API version ASAP.

It seems to me that GOG is not interested in spending the time to document their API adequately for external use.

And then they said nothing more about it. :-(

I can understand what they are doing, and why they are doing it.What you say describes the best case scenario, and it is possible. However, what we see can also represent a not so nice scenario (no Linux support, everything closed), and if that was to happen, do you think GOG would act in any other way? So... wait and see? Or we could ask GOG for some sort of statement that would put us at ease. Something that says "we assure the community that we are committed to the Linux platform". A Linux version of the Witcher 3 would point in that direction, but failing that, some official statement would be welcome.

When they do stabilize and publish the API, it will be possible for some 3rd party developer to make a stub library for Java of the API if they wish, and for someone to attempt to write a client in Java with it in theory. All I can say about that is "best wishes" to anyone who decides to do so. My observations of major applications written in Java as alternatives to those written in C/C++ are that they are massively bloated, consume RAM and CPU resources out the wazoo and seem to have their focus on rapid development rather than resource consumption.

For example, back when I started using utorrent which is written in C++ and was highly optimized it used 6-8MB of RAM fully loaded downloading dozens of large Fedora/CentOS torrents simultaneously. The other popular program at the time was Azureus now known as Vuze, which is written in Java. It used something like 100+MB of RAM. Not sure what the statistics for the current versions of each program are. I know utorrent's resource consumption went up over time due to new features and functionality etc. and I assume Vuze's has also, but I'd wager that utorrent is still far less of a resource hog. Not that I would use utorrent any more nowadays since they started shipping it with built in OpenCandy malware though but that's a whole other topic...

Plenty of examples of just about any other application type out there. I'll take a big wide pass on any major GUI desktop apps written in Java myself, but that's just me. :)

All strategies have their downsides. What strategy one chooses is a matter of choosing the upsides and downsides that match the desired goals etc. the best and only GOG can decide what strategy they think is best. They're also free to change the strategy over time if they think it makes sense to do so, and I think they already have done so.


Anyone who has ever done large scale application/API development knows that they evolve over time based on the needs of the project and that you don't want to be tied down to a certain way of doing something that you later learn was not the best implementation. It is completely natural to implement something a certain way and then later realize a better way of doing it and change it. When you have no external things depending on it, you are free to change it as often and as much as you like, and when the entire project is defined as being in development, the API can and does change often based on new features being added, things evolving as a regular part of code churn. Sometimes you even learn a much better way of doing something than what you were doing and throw huge chunks of code away and replace it with a whole new way of doing it.

You change the API, you update your own code that uses it to use the new bits as you go, and it can quite literally happen every day. If one wants to see this first hand, simply subscribe to the mailing lists of any major open source project covering public APIs that is in a deep state of development. Some projects use static libraries instead of DSOs in order to mitigate this, so that they're free to change the API/ABI at will and old programs will still run as they're statically linked. They can then change things in newer releases and it will only affect new code, but that approach brings all kinds of problems on its own and is greatly frowned upon. X11 had this problem over a decade ago with a number of its interfaces, but the usage of static libraries were phased out and versioned DSOs used instead. That's the right way to do it however when you decide to do that you potentially end up supporting multiple versions of every DSO that you decide to change the API of, and that in turn causes many projects to avoid changing the API for a long time because they don't to have to support a multitude of different DSO versions.

The bottom line though, is when you have a project in-development, it is a well defined given that anything can be changed at any time, and that can be a nightmare for 3rd party projects if they are relying on an unstable and ever changing API whether it is documented and published or not.

Another element of this that I've personally encountered that was no end of frustration, was the freetype font rendering library. I'm not sure if the freetype library still has this problem nowadays or not as it has been many years since I have looked at the source code or had to deal with it however a decade+ ago when I did deal with it on a daily basis, the project mixed their public API with their internal private API in the public header files. Many projects including X.Org and XFree86 among various others used both the freetype public API and the private API, and while it's not clear as to whether or not that was on purpose or not, private APIs are NOT intended to be used by 3rd party applications but rather internally by the library itself. These functions should be marked appropriately to not be exported to become available to external programs to use however the freetype project didn't do that for whatever reasons and as such every new version of Freetype whenever they changed their internal implementation of something and it affected the internal APIs as they should be free to do since by definition they are for the internal implementation and not public consumption - 3rd party programs that illegally used these internal functions would break miserably en-masse and various people (myself included) had to go deal with all of the mess.

Not sure if they ever bothered to go and fix that properly and hide internal private functions from being visible to software that used freetype or not but it was certainly a good example of what NOT to do when writing a DSO for public consumption.

A well designed API needs to be forward thinking as much as possible, and it should be flexible. In the process of developing such a thing you may experiment with different ways of doing things and you want to be completely free to keep what works well and to throw away what does not work well or to replace one way of doing something with a better or more flexible way of doing things, and you don't want to have to maintain backward compatibility with each and every change you make that removes an interface or changes the way it works.

Having 3rd party code tied to your ever changing in-development API is a developer's absolute nightmare thought because every single time the slightest thing changes the people who are using it (whether or not they should be such as in my freetype example above), they will breathe the hottest fire down your throat and cry "evil company! Changes the API to break competing product on purpose" or similar crap.

No experienced developer is going to want to put themselves in that position. I for one would never document nor publish an API I was working on whether part of a commercial product or an open source project until it was at a bare minimum nearing completion and I knew with reasonable certainty that no major API breaking changes would be going in. Even then I would warn people that they could occur up until the first official stable release, but I personally would probably hold off from it until I knew for certain it wouldn't change because of my experience in watching how people use these things and react publicly when things break and they're not happy about it because they have to go and change their code.

If GOG has experienced developers working on Galaxy, and I know for certain that they do, then they're probably smart enough to do the same thing, and to date it seems like they're being smart about that IMHO

Been there, done that. It doesn't work. You can tell people things can change all you want and when you change them they'll bite your friggen head off. Hell this not only happens for actual API breaking changes but it happens for changes that do NOT break an official API but do change what is "undefined behaviour" even. I have had first hand experience observing 3rd parties (both open source projects and commercial developers) react to changes that have occurred in the GNU C library (glibc) just in terms where the internal implementation has changed in a way that fully complied with the official standard C specifications still but where the behaviour of certain inputs are documented to have "undefined" or "implementation defined" results. People write shitty code who don't read documentation and know what those terms mean and their code relies on the library responding a specific way to what is officially "undefined behaviour" then cry to the ends of the earth about the library maintainer breaking standards when no such thing has occurred.

I could literally go on for like 8 hours and 20 pages describing scenarios like this that I've just personally experienced or observed myself while working in the field. It's a nightmare to deal with as a developer and you're always seen as the evil bad guy who is purposefully trying to break people's code, when it is the people's code that is the actual broken crap. Forgive me if I sound a little emotional about it, but I've had a huge amount of experience dealing with that sort of crap myself and so I'm sympathetic to others in a similar position and how to go about avoiding these kind of nightmare situations.

IMHO the best thing for GOG to do is to continue to work on realizing their vision, and eventually to release it to the public along with documentation. Then based on usage and feedback from 3rd parties over time using that, as well as their own needs and future features etc., continue to evolve the API and eventually release a Galaxy.dll 2.0 etc. and repeat the process again.

It's just not something you want 3rd parties having to try to deal with and understand the reasons behind daily/weekly/monthly internal changes and have to explain or justify or get into heated arguments and crap about, but those things are exactly what happens if you start publishing stuff early no matter what kind of arguments favouring doing so that one might have.

They don't have a public API to document yet. First they need to have a finalized API before they can document it, and trying to change that every day/week/whatever and update documentation and explain changes etc. as mentioned above is a nightmare, and it's also a massive waste of resources. It's easy to criticize them for something when someone isn't getting their own way, but that doesn't mean that they're not doing the right thing, nor that the criticism is factual reality.

Again, I can say from personal experience as a developer, when I'm working on a big project, I'm focused on designing and implementing features, changing things on a daily basis as I see fit, sometimes throwing something out and replacing it with something completely different tomorrow until I settle upon something that I think works well. Documenting any of it is not even the last thing on my list, it is not even on my list at all, and not even on my mind at all. It couldn't even be further off my mind. Once the project is complete and I have to think about the final public interfaces and write documentation, then that's a separate phase of the project where I'll deal with that at that time. If I were to spend time documenting everything I do every day to change it tomorrow and piss people off because they relied upon it and have to change it over and over and over and track my whole project every day, I'd spend up spending half my time documenting things instead of writing code, and 25% of my time having to discuss/debate/argue with people who don't like things changing every 10 seconds.

GOG is very unlikely to come out and say these things because they're busy writing code and engaging in such low level discussion would be counter-productive to them. So I can't speak for them or how they think about this stuff or what their own thoughts about all of this are, but I can speak from a lot of personal experience exactly what my own thoughts about all of this would be if I were one of them myself. If I was managing the project I wouldn't publish any API either until I had implemented all of the features that planned to ship in the first stable version of the product and stabilized them to the point I felt strongly the API would not change. It would IMHO be insane to do otherwise.

What more needs to be said about it? What more would they have to or need to say? What they said already pretty much covers everything. They'll document and publish the API when they release the stable product. The stable product is not released and they do not have any published release date nor have they felt like tying themselves down by announcing a release date. So I can't think of anything that they need to actually say personally. My expectations based on what they have said is that eventually when they do get the client and API to the point where they're ready to release it as stable, sometime around then they may perhaps start talking about the API. While there have been a very few odd times it has been brought up in the forums here over time, it has not been a hotbed of discussion either.

Personally, I think they should have never announced that they would release a public API in the first place. If they never mentioned that, there might be people who wondered about it or asked them to do such or similar but it would be a different conversation because they wouldn't be able to say "you said you would do XYZ, when are you going to do that?" That's the thing with saying you're going to do something or even announcing dates or timelines. People always want to know more and more and more and ultimately want it yesterday, and these things are not always known in advance. In software development in fact they are almost never known accurately in advance. When I'm forced personally to give a rough estimate to a manager or customer etc. over time I use a formula someone far more experienced than I passed on to me which has worked out great over time. If it is even possible I do my best to estimate my honest guess as to how much time will be needed. Then I double that. Then, I triple that. That's the timeline I tell them. (Thanks for the formula Kevin! You're probably not reading this but it's the thought that counts!) :) The best though is to not have to give a timeline at all, and to not have to be tied into giving details at all.

As a user, like you and many others - I always want to know when a game is coming out, when the next version of XYZ is coming out, what features it will have, when I can test it, when I can use it, when <insert random things here>. Sure, we all do want to know these things and that is completely natural. I'd love to know what the release date of Galaxy stable edition is, and when the API will become documented and published. If someone from GOG wants to respond to me saying that with an answer for these things, fantastic for myself and all of us! But that's where I have to put my developer/project manager hat on too, with understanding from the other side of the fence as to why they (or I if I were them) would NOT want to mention all of these things, or to be very very careful about what I do say, how much I say, and the specific words I use to say it if I say anything at all. People _always_ try to hold you tightly to your words, even taking your words and often putting interpretation spin on them to put their own meaning on them and it can get out of hand easily and you end up getting 2 virtual black eyes, and that's just in real life. On the Internet, it can take on a whole life of its own and potentially be a huge PR nightmare.

It's a game that must be tread very carefully and while it is an unpopular public opinion, especially to the general public, you generally do less potential damage by publicly sharing more than sharing less when it comes to extremely early product announcements and discussing features and details of what you're doing etc. You run the potential risk of being considered detached perhaps, or being too silent or other things, but IMHO they tend to be lower risk of damage than saying too much, and that is why a lot of companies keep their lips sealed about these kind of things despite the fact that it does upset some people.

So I want to know what you want to know more or less as much as you want to know. But I have total respect for GOG if they happen to choose to not only not tell us, but to stay completely radio silent on the matter, and if I were actually them I probably wouldn't utter a peep about it all until I knew for sure what I was going to say was solid and the pros and cons of sharing weighed in the favour of sharing.

Of course this is all my personal opinion, and it may potentially be wildly unpopular perhaps. I'm not trying to be popular though but to share my own insight into why things are done this way and why it makes sense to do it this way. There will always be people unhappy about how things are done no matter how things are done, and always people who will cry you afoul if you're a developer no matter what you're doing nor what your intentions are. The successful don't get caught up in that and focus on writing code and doing their job and not on getting 100% popularity ratings for public discourse.

I'm not always 100% happy with every decision GOG makes, and I might be crazy but I have a pretty good amount of faith in them and that they're doing the right thing with all of this even if it may not look that way to everyone and if it seems it is taking a long time. I can't prove that and it's my gut feeling, but only time can tell if I'm on the money or not. I guess we'll all have to wait and see... although hopefully sooner than later, but then Rome wasn't built in a day. :oP

Well, I managed to find it. :D

Recreated steps:
- Make this Google search: site:gog.com/forum "api" "public"
- Find this thread (should be the fourth link) and go to the first page to find at the fourth post—no kidding—you!
- Then @Gydion gave you a link to a post by @shmerl. Unfortunately, the link @shmerl gives is kind of broken since you cannot see the Twitch video, but we now know that it was in October 2014 (your memory served you correctly!).
- Now that we have enough information, go to the GOG.com Twitch profile. Click on "Highlights" and scroll down until you encounter the video titled "GOG.com Community Q&amp;A" (alternatively and more easily, just hold the End key for a while and search for the title).
- Thanks to @shmerl's post, we don't have to sit through an hour-long video just to find a small bit, so just skip to about 49:40 and voila!

All in all, it was pretty easy, but there were a lot of steps. Thanks for putting me on the right track! ;)