How to encourage more developers to be involved

[mcarans]

Currently, Oolite lacks developers to take it forward. It is a big undertaking and I applaud those who have created the builds and DOxygen documentation on GtHub as that is a very necessary starting point.

There are a few challenges. From my high level browse around the repository and the wiki, in my opinion, the main one is that the code is in Objective-C which few developers know. The others are the increasingly outdated dependencies.

There are two ways to go - start again or refactor. In my experience, starting again rarely leads to success because it is such a huge job. That leaves refactoring - going through many baby steps to get to the goal rather than a big bang.

The question would then be where to begin with refactoring - keep everything the same as much as possible while building wrappers around the Objective-C code and migrating more and more of it to another well known language, or sticking with Objective-C and upgrading dependencies like SDL GNUStep etc. to latest versions first. The latter probably requires a greater understanding of Objective-C and its peculiarities than the former.

Another question is what language would be a good choice to draw more developers: C++, Go, Rust? I suspect the easiest to get working would be C++ as due to its age and longevity, it will work with both old and new dependencies.

These are just some thoughts to hopefully spark a discussion.

[another_commander]

There are a few challenges. From my high level browse around the repository and the wiki, in my opinion, the main one is that the code is in Objective-C which few developers know.

This is correct. Objective-C is like Latin these days, people don't use it and they just don't care about using it neither do they know much about it (other than it used to be a thing for Apple machines many years ago).

This is a pity though, because all Obj-C really is is C++ with a different syntax and literally a couple of rules for setting up memory. Anyone familiar with C++ would be able to read up on the syntax and start using the language within no more than two to three days. Source: me, that's how I did it.

The others are the increasingly outdated dependencies.

Agree, but only in the case of Linux. For Windows the dependencies were locked years ago and they are still totally valid today. That was a deliberate decision which has enabled us to work on game features rather than keep running after the new versions of libpng or gnustep or libxml or [your favorite dependency here], which to me looks more like herding cats to be honest. By keeping strict control on the dependencies, we are even able to back-port code from later versions if that becomes necessary, like in the case of critical security patches or a new feature we can't live without.

There are two ways to go - start again or refactor. In my experience, starting again rarely leads to success because it is such a huge job. That leaves refactoring - going through many baby steps to get to the goal rather than a big bang.

The question would then be where to begin with refactoring - keep everything the same as much as possible while building wrappers around the Objective-C code and migrating more and more of it to another well known language, or sticking with Objective-C and upgrading dependencies like SDL GNUStep etc. to latest versions first. The latter probably requires a greater understanding of Objective-C and its peculiarities than the former.

Another question is what language would be a good choice to draw more developers: C++, Go, Rust? I suspect the easiest to get working would be C++ as due to its age and longevity, it will work with both old and new dependencies.

These are just some thoughts to hopefully spark a discussion.

For me it would be unrealistic trying to migrate the codebase to another language. This would require some big brains combined with levels of dedication and resolve never seen before. It would be far easier to try and make people realize that Obj-C is really nothing difficult or special, it's just another object oriented language which is notably easy to get into.

[Cholmondely]

1) Might it not be, that with the development of AI, that we could eventually hand over development of Oolite to a more developed AI?
- viewtopic.php?t=21850 - Qwen's suggestions for modding Oolite
- Wildeblood's recent publications of AI derived scripts (Witchbank for just one example)
In another century, we won't need any developers at all. Latin-speaking or otherwise!

2) Cody told me that our developers had decided a decade or so ago that Oolite was finished, with no work needing to be done. Personally speaking, while there are things I would love to see in-game (3D galaxies with more than 256 systems in each, the ability to describe the system in-game in 3D cordinates (find the rock hermit 30,000 cavezzi beyond planet a moving sunwards) and provide a map on the F7F7 screen, more realistic planet landings, et cetera - and some of this might be OXP-able), I do find the vanilla game perfectly good enough. As long as it will run on my AppleMac!
Personally I think the OXPs are much more important in terms of giving me the game I crave. I'd be more interested in a finished SOTL Exploration and a finished LitF with different interiors for different stations. And more things to do with PF2's landing sites.

[another_commander]

1) Might it not be, that with the development of AI, that we could eventually hand over development of Oolite to a more developed AI?
- viewtopic.php?t=21850 - Qwen's suggestions for modding Oolite
- Wildeblood's recent publications of AI derived scripts (Witchbank for just one example)
In another century, we won't need any developers at all. Latin-speaking or otherwise!

In many many years, provided that license issues are sorted out, maybe. Right now AI is completely unfit for purpose and is only good for giving a general idea of how one would go about designing a feature or where to start looking for fixing a bug. Apart from confidently giving completely wrong and unusable answers in way too many cases when prompted, there are serious issues with licensing due to the way the AI models acquire their info. They harvest the net for anything they can find and in doing so they end up using code with inappropriate licenses or just proprietary code that can't be integrated anywhere. Oolite should not use AI generated code until there is a resolution to this.

[Wildeblood]

1) Might it not be, that with the development of AI, that we could eventually hand over development of Oolite to a more developed AI?
- viewtopic.php?t=21850 - Qwen's suggestions for modding Oolite
- Wildeblood's recent publications of AI derived scripts (Witchbank for just one example)
In another century, we won't need any developers at all. Latin-speaking or otherwise!

I think Cholmondely's extrapolation of, "In another century," seems about right. Using AI to re-learn javascript (the world's most common programming language) and letting it anywhere near Oolite's full codebase of Objective-C are two very different propositions.

[mcarans]

Agree, but only in the case of Linux. For Windows the dependencies were locked years ago and they are still totally valid today. That was a deliberate decision which has enabled us to work on game features rather than keep running after the new versions of libpng or gnustep or libxml or [your favorite dependency here], which to me looks more like herding cats to be honest. By keeping strict control on the dependencies, we are even able to back-port code from later versions if that becomes necessary, like in the case of critical security patches or a new feature we can't live without.

For me it would be unrealistic trying to migrate the codebase to another language. This would require some big brains combined with levels of dedication and resolve never seen before. It would be far easier to try and make people realize that Obj-C is really nothing difficult or special, it's just another object oriented language which is notably easy to get into.

Thanks for your response. I agree that many dependencies are not worth upgrading, but thinking of SDL specifically, it looks like SDL3 would open up possibilities for making enhancements in audio, video etc.in future. Is GnuStep the means by which Objective-C can be made to work on non- Apple systems? I had a brief look at the Pioneer codebase and that uses SDL2 and since it's in C++, there is no GnuStep.

To get a developer to spend several days learning an increasingly outdated language just for one project is I think a big ask. The developer that might be prepared to do so would have to be a very dedicated Oolite fan who also happens to have a lot of spare time on their hands. I do accept though that it's a big job to migrate to another language although if C++ and Objective-C are fairly close, maybe it's not inconceivable to do it gradually without breaking anything?

[another_commander]

Thanks for your response. I agree that many dependencies are not worth upgrading, but thinking of SDL specifically, it looks like SDL3 would open up possibilities for making enhancements in audio, video etc.in future.

Possibly, but a previous attempt at a transition to SDL2 at some point didn't go well. It failed to achieve 1:1 parity with the SDL 1.2 build we had at the time, broke the Windows port badly and uncovered inexcusable bugs related to OpenGL support in Windows with the then current version of SDL2. Things are probably fixed by now but someone will have to come up and take it upon themselves because I am out of steam to try this again. If interested you can enjoy all the gore and splatter by searching the issues on github for "Oolite is still on SDL 1.2".

Is GnuStep the means by which Objective-C can be made to work on non- Apple systems? I had a brief look at the Pioneer codebase and that uses SDL2 and since it's in C++, there is no GnuStep.

Yes. You can think of GNUStep as the stdlib of Objective-C.

To get a developer to spend several days learning an increasingly outdated language just for one project is I think a big ask. The developer that might be prepared to do so would have to be a very dedicated Oolite fan who also happens to have a lot of spare time on their hands.

Absolutely. This is why I believe the best way to attract developers is to be in position to show an as great game as we can possibly make it. Make it look professional, stable, extendable and worth playing. Then we might be able to grab the attention of talented people wanting to push it even further.

I do accept though that it's a big job to migrate to another language although if C++ and Objective-C are fairly close, maybe it's not inconceivable to do it gradually without breaking anything?

Whilst it is easy to write Obj-C code if you know C++, porting entire classes interacting with eachother and spanning 250K lines of existing code to C++ would take forever and carries a considerable risk of failure. In theory it is possible but in practice not so much.

[hiran]

For me it would be unrealistic trying to migrate the codebase to another language. This would require some big brains combined with levels of dedication and resolve never seen before. It would be far easier to try and make people realize that Obj-C is really nothing difficult or special, it's just another object oriented language which is notably easy to get into.

Thanks for your response. I agree that many dependencies are not worth upgrading, but thinking of SDL specifically, it looks like SDL3 would open up possibilities for making enhancements in audio, video etc.in future. Is GnuStep the means by which Objective-C can be made to work on non- Apple systems? I had a brief look at the Pioneer codebase and that uses SDL2 and since it's in C++, there is no GnuStep.

Today Oolite is already a mix of C/C++ and Objective C. Just take Oolite core (Objective C), the main classes for the various operating systems (C++, Objective C) and classes contained in dependencies (C/C++). If functionality were transported class by class, method by method we could have that smooth migration mcarans proposes.

To get a developer to spend several days learning an increasingly outdated language just for one project is I think a big ask. The developer that might be prepared to do so would have to be a very dedicated Oolite fan who also happens to have a lot of spare time on their hands. I do accept though that it's a big job to migrate to another language although if C++ and Objective-C are fairly close, maybe it's not inconceivable to do it gradually without breaking anything?

I see that exactly the same way. There is no chance for me to learn Objective C just for Oolite - especially since it is open source and GPL there is no monetary value in it. Thus the learning curve needs to be as low as possible.

If the game is considered complete then it is the best time to keep it compatible with today's operating systems. Locked dependencies did not stop the OS to move on. This way the current Apple Mac platform is unsupported, and Linux is aging away. Just Windows seems to still cope with the old code. Although that would also just be a matter of time, unless Oolite starts maintaining the dependencies.

Oh, and it is worth updating even dependencies like the JavaScript library. Oolite runs on a specific flavor of JavaScript that today's developers might find quirky and unpleasant.

[mcarans]

I believe the best way to attract developers is to be in position to show an as great game as we can possibly make it. Make it look professional, stable, extendable and worth playing. Then we might be able to grab the attention of talented people wanting to push it even further.

There is no chance for me to learn Objective C just for Oolite - especially since it is open source and GPL there is no monetary value in it. Thus the learning curve needs to be as low as possible.

I think this highlights the challenge of attracting new developers to work on the core code even those who are fans of the game. I have similar concerns.

If the game is considered complete then it is the best time to keep it compatible with today's operating systems. Locked dependencies did not stop the OS to move on. This way the current Apple Mac platform is unsupported, and Linux is aging away. Just Windows seems to still cope with the old code. Although that would also just be a matter of time, unless Oolite starts maintaining the dependencies.

Oh, and it is worth updating even dependencies like the JavaScript library. Oolite runs on a specific flavor of JavaScript that today's developers might find quirky and unpleasant.

I would imagine that the main reason to do locked dependencies is lack of capacity to maintain the project which means that eventually the game will approach end of life which would be a tremendous shame. Dependencies have not been updated for so long that the question is whether we're heading to the point at which starting afresh would be more productive than trying to refactor and bring them up to date.

Possibly, but a previous attempt at a transition to SDL2 at some point didn't go well...someone will have to come up and take it upon themselves because I am out of steam to try this again.

Whilst it is easy to write Obj-C code if you know C++, porting entire classes interacting with eachother and spanning 250K lines of existing code to C++ would take forever and carries a considerable risk of failure. In theory it is possible but in practice not so much.

Good to get a perspective on the scale of the task from an expert in the code. From what you've said, it sounds like the code could be getting to or past the point of no return where it might be more productive to start again than to try to bring it up to date. Is the best approach to try to keep it ticking over until it ceases to be possible?

[hiran]

Good to get a perspective on the scale of the task from an expert in the code. From what you've said, it sounds like the code could be getting to or past the point of no return where it might be more productive to start again than to try to bring it up to date. Is the best approach to try to keep it ticking over until it ceases to be possible?

It is happening.

The game was initially developed on the Apple Mac. Test cases were run manually in XCode - the Apple IDE.
Since whenever all Apple Devs have left. Apple has switched OS and CPU architecture. Oolite no longer compiles on current Apple Mac hardware. So main (maintenance) development has shifted to Windows, without any automated testing. Hence noone touches the core or dependencies.

Someone is experimenting which dependencies need and can be updated to at least run on up to date Linux installations.

Plus I wonder how many young developers who have not fallen in love with Elite/Oolite would do so these days. What made Elite special is quite common today, and there are way too many alternatives out there.

[another_commander]

Today Oolite is already a mix of C/C++ and Objective C. Just take Oolite core (Objective C), the main classes for the various operating systems (C++, Objective C) and classes contained in dependencies (C/C++). If functionality were transported class by class, method by method we could have that smooth migration mcarans proposes.

OK. Any volunteers?

To get a developer to spend several days learning an increasingly outdated language just for one project is I think a big ask. The developer that might be prepared to do so would have to be a very dedicated Oolite fan who also happens to have a lot of spare time on their hands. I do accept though that it's a big job to migrate to another language although if C++ and Objective-C are fairly close, maybe it's not inconceivable to do it gradually without breaking anything?

I see that exactly the same way. There is no chance for me to learn Objective C just for Oolite - especially since it is open source and GPL there is no monetary value in it. Thus the learning curve needs to be as low as possible.

Well, kaks, cim, phkb and myself all learnt Objective-C just for Oolite and it didn't go as bad as you might think. If one is driven enough, one can do it.

If the game is considered complete then it is the best time to keep it compatible with today's operating systems. Locked dependencies did not stop the OS to move on. This way the current Apple Mac platform is unsupported, and Linux is aging away. Just Windows seems to still cope with the old code. Although that would also just be a matter of time, unless Oolite starts maintaining the dependencies.

The Mac ended up unsupported for reasons not related to maintaining dependencies and the only entity responsible for it is Apple themselves. As for locked dependencies, I have already agreed that it is an issue to be looked at for Linux. For Windows though, I think I'll stick to my guns and continue defending the decision taken years ago to keep dependencies locked. Not only does the Windows port continue to run unaffected and is compatible with today's operating system - in fact, it had Win 11 24H2 functionality before Win 11 24H2 officially launched, but in some cases it is pioneering technologies not seen before. Did you know that Oolite is the first and only game featuring native HDR output support under OpenGL? For years it was thought that OpenGL cannot achieve HDR, until Oolite for Windows came and demonstrated the opposite. This was only possible because of keeping every dependency locked and because, as you have mentioned in the quoted text, we are, in fact, maintaining our Windows dependencies.

[another_commander]

Good to get a perspective on the scale of the task from an expert in the code. From what you've said, it sounds like the code could be getting to or past the point of no return where it might be more productive to start again than to try to bring it up to date. Is the best approach to try to keep it ticking over until it ceases to be possible?

In practical terms starting over is not a viable option. You can't just start over a project that has been running for 20+ years. Well OK, in theory you can, but I really don't think this is something that can work.

The SDL2 attempt we discussed earlier failed because the person who was porting over to SDL2 stopped working on it. The problems were there, yes, but they were not unsolvable and at no point did we ever approach the point of no return. It just needed some more time and dedication which were not there for whatever reason - not blaming the guy here, just to be clear, he did a good job with what he had available, but didn't stay until the end to see it finished. I will also include myself here, I tried testing the SDL2 port under Windows and in the end I just gave up in frustration. I could have done it if I had dedicated more time and had more patience, but I just didn't back then.

For Linux yes, by all means we need to sort out the dependencies. For Windows this is not necessary, at least not now. If we do ever need to update our dependencies it can be done just as it has been done quite few times already in the past. Refer to the document entitled ExternalLibrariesSourceCodeChanges.txt in the source Doc folder for examples of what we had to do to the support libraries to get them to run the way we wanted them for Oolite.