Porting to MacOSX can be done in several different ways. MacOSX is special in that it comes with an own Objective-C runtime environment, including an own Objective-C runtime and an own Objective-C Foundation library.

So, depending on the approach, a MacOSX port can be either a system level port to the Darwin BSD system or it can be a port to the Cocoa Objective-C environment. The latter is certainly the preferred goal providing much better integration with MacOSX.

Also, the build system is quite an issue. OGo uses an own branch of the GNUstep makefile package which will not support building on MacOSX. However, a current CVS version from the GNUstep CVS repository will do.
On MacOSX the build environment of choice is Xcode, however. This implies that for proper MacOSX support we will have to create Xcode projects for all OGo subprojects accordingly and - much more important - keep them in sync with the main build system while things change. Because Xcode project files are not (easily) human readable this is a troublesome step. While Xcode support is somewhat desirable, it's not strictly necessary for getting OGo to run on MacOSX, however.

There is no specific organizer for MacOSX ports yet. For now, just contact Marcus Müller.
People which work/worked on the port:

If you're mainly developing on MacOSX, you might want to take a look at the SOPE:X project in the Contrib section of OGo. In short, SOPE:X is a framework and Xcode template set to improve the development experience on MacOSX. It includes an innovative new way of running SOPE applications as regular MacOSX desktop applications (by making use of the new WebKit framework). Further information is included in its README.

macosx@opengroupware.org

The web interface compiles and works just fine on MacOSX. Some ZideStore plugins are disabled due to OSX linking issues.
Compilation on OSX 10.4 produces a lot of warning which you can ignore, gcc 4.0 just got even more strict on some previously legal constructs.

Fixed a URL processing issue due to a bug in Cocoa Foundation NSURL. Mod_ngobjweb builds and runs out of the box!

At least one umlaut issue in SOPE on MacOSX was fixed. SOPE 4.3 and OGo 1.0a compile just fine on MacOSX. The Xcode projects of SOPE 4.3 are cleaned up and ready for use.

Various tweaks and fixes for compilation with gstep-make. Prebinding for SOPE is now also supported when compiling with gstep-make, all the makefiles are fixed with regards to missing/changed library search pathes.
Further, ZideStore now builds and runs on MacOSX using gstep-make. We will need some sourcecode reorganisation to support Xcode builds.
A lot of work by Stephane Corthesy to improve SOPE compatibility with WebObjects 4.5.

The Xcode 1.2 update apparently introduced changes in the dependency tracking of gcc which broke compilation of OGo using gstep-make. This was fixed for most packages in CVS head by adding explicit references. Yet there seems to be a general problem with gcc locating _available_ libraries (this was also confirmed for recent gcc on regular BSD).
So far the basic issues of the port still exist which are: NSNull handling and broken output for non-ASCII characters.

A change to use the Foundation key/value coding instead of an own one unfortunately seems to introduce quite some issues in conjunction with NSNull. For example OGo KVC returns 'nil' when -valueForKey: is used on an NSNull value contained in an NSDictionary. Cocoa KVC returns the actual NSNull object, so client side code needs to deal with that.
In general NGExtensions/FdExt/NSNull+misc.m already contains a lot of "catcher" methods which work around NSNull values in unexpected places - this is a hack and needs to be fixed.

Several "WO" fixes were applied on SOPE, we now have proper support for .woo files and support for WebObjects Builder templates. In addition ZNeK fixed some minor issues in NGObjWeb, enhanced SOPE:X a lot and did apply a more performant workaround for the "mutable dictionary" issue (using some private CoreFoundation API which might go away in 10.4).

Several fixes (and hacks) were applied on the OGo source tree to support OGo in gstep-make on MacOSX. It now works pretty well and was actually used to demonstrate OGo on an iBook/OSX 10.3 at FOSDEM!
Nevertheless some "fixes" are rather hacks: a) somehow Cocoa tries to invoke various methods on NSNull objects, something is wrong here, b) on Cocoa we cannot find out whether a dictionary is mutable - affects NGObjWeb and is hacked around using NS_DURING.

Marcus Mueller committed the source of SOPE:X in the Contrib section of the CVS repository. SOPE:X is a framework and Xcode template set to improve the development experience on MacOSX. It includes an innovative new way of running SOPE applications as regular MacOSX desktop applications (by making use of the new WebKit framework).

Friday, the 13th. Hm. OpenGroupware.org now builds and runs! on Panther using gstep-make. Of course it still has a lot of bugs and issues (for example problems with umlauts and the task application isn't working yet), but otherwise it looks just fine.
Next step: build a package.

WebUI builds using gstep-make! All the makefiles are corrected and lots of tweaks were made. In addition ZNeK added proper prebindings to the Xcode frameworks of SOPE:X.
Now we need to check whether it actually runs ... at least Publisher has problems with NSPathUtilities which actually require valid local pathes on Panther.

ZNeK has cleaned up the Xcode projects of skyrix-xml, skyrix-core and skyrix-sope. In addition he has added proper umbrella frameworks so that linking against a framework set is much easier.

The gnustep-db, Logic and DocumentAPI now all compile with gstep-make on MacOSX. Notably various things are not yet ported, so functionality should be buggy in various sections (compilation issues FIXME warnings on those sections).

Helge did some work on the gnustep-db parts. Relevant parts of FoundationExt are now included as a subproject of gnustep-db and various other tweaks are removed. It probably doesn't work yet, but got a major step forward.

One of my major complaints with MacOSX development is that neither Xcode nor IB use an abstract XML (or plist) storage representation but rather use serialized object graphs (yes, like some MS data formats they try to masquerade as XML, but I'm not going into that trap ;-).
This results in new fileformats for almost any release and it makes working in a distributed team on the same codebase *really* hard.
Summary: Helge started to create Xcode projects in addition to the PBX ones. The project is still mostly stuck at the port of ThirdParty/gnustep-db.

Helge did some work on compiling OGo on MacOSX using the gstep-make package (the current one from the GNUstep website) in the apple-apple-nil combo (that is with Apple runtime and Apple Foundation).
So far this seems to work pretty well up to SOPE (well, compilation on G4/OSX is slow as hell, so if anyone has a spare dual-G5 ;-). It's currently breaking at gnustep-db, which requires proper adjustments for the missing FoundationExt library.
Note: this process currently produces shared libraries, not frameworks. Nicola has done some work on a new make project which produces frameworks on OSX and shared libraries on regular Unix systems, we'll check that out later.

Marcus and Helge did some work on the PBX files of SOPE - skyrix-xml, skyrix-core and skyrix-sope should now operate without the dependency on FoundationExt.
See the status overview below.

First, most of the core stuff should at least compile on Jaguar without too much hassles and even the higher level stuff should compile without big problems. And some stuff already comes with ready-made PBX files.

Helge needs to summarize more issues he knows about an OGo Cocoa port ...

Q: I started trying to build, but don't seem to be able to find the FoundationExt that's required (grepping the source tree). I first suspected the extensions that come with libFoundation, but those appear to be different. Some googling revealed that they might be a part of gnustep.

A: The PBX are somewhat "old" (out of sync) - until some months ago you were required to use the so called FoundationExt library which contains all the extensions coming with libFoundation for other Foundation libraries (like subclasses of NSException or RETAIN/RELEASE macros or UnixSignalHandler etc).
Actually I think I moved most/all of the required things into NGExtensions (skyrix-core) and actually the code should be independend of FoundationExt now. "should" like in "did not test".
So if the PBX contains link reference to the FoundationExt.framework just remove it and with some luck it will just compile. On the other side you may need to add some more (new) source files in NGExtensions to the PBX.
In short: OGo should work completely without FoundationExt. If stuff is missing, move to NGExtensions or rewrite the code to work without.

It seems that people agreed in the mailinglist that we should use gnustep-make for compilation on MacOSX. This has the advantages that we only need to maintain a single build environment, and more important, that we can actually work in a multiuser environment on the makefiles (which is basically impossible with PBX due to it's binary nature).

Obviously we should use the latest gstep-make version from the GNUstep project on MacOSX, since the OGo gstep-make certainly doesn't include all the MacOSX fixes Nicola has done in the meantime.

One issue with that approach is that we definitely want to use frameworks on MacOSX and definitely do not want to use frameworks on ELF platforms. It's still open whether we can change gstep-make in a useful way, so that library.make generates frameworks on MacOSX.

TheSin [hu? ;-)], has started trying to port OGo using dlcompat for Fink. Check the mailing list archives of the macosx and developer mailing lists if you are interested in that.