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 for the core code even those who are fans of the game.

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 think the main reason to do locked dependencies is lack of capacity to maintain the project with the expectation that the game is approaching end of life. The question is whether we're heading to the point at which starting afresh would be more productive than trying to refactor.

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 and hence the best thing is to try to keep it ticking over until it is no longer possible. Would that be a fair assessment?