GNOME newcomers love

Two exciting happenings on the GNOME front.

Outsiders’ developers experience

John Stowers is rocking in this front. This is one of my biggest concerns on the GNOME platform, our APIs are pretty cool, and we’re fixing the remaining ugliness pretty fast lately (kudos to Alexander for this).  I have the strong believe that the fact that a user or developer is not using Linux, OpenSolaris, or *BSD, shouldn’t stop him to be able to get into the free software development. Freedom should be pushed for everyone, everywhere possible.

So, how do we rock on the Win32/Mac OS X land? To make it rock we need  to improve the behavior of our libraries on those platforms, which is hard since 99% of GNOME developers are Linux guys, and setting up a familiar development environment on Win32 is pretty painful, and not everyone has access to a Mac box.

We need to attract "native" developers from those platforms, so they can test and provide useful feedback and, hopefully, patches as well. To achieve that we have to improve the bootstrap of the build environment. Requiring a shell to build is being a major blocker here. I’m not suggesting to replace autootools/makefiles for something else, but we need to explore alternative ways for building on Win32 so jhbuild can be used without an MSYS/Cygwin environment.

GNOME Developer Kit

Ken VanDine, our friend from rPath, what could probably become to the easiest way to contribute code to GNOME, the GNOME Developer Kit. We discussed this idea as part of the Patch Squad effort at last Guadec. It’s basically a Foresight based distro with a nightly build of GNOME from svn.

Most people spend 90% of their first patch, dealing with the tools instead of focusing on the problem (jhbuild, installing dependencies…). The risk there is that lots of people give up meanwhile (I gave up several times until my first gnome patch myself).

With the developer kit, newcomers can just use the Conary packaging system tools to modify the source code and create patches against svn, this is, get focused on the problem, instead of the tools.

Kudos to both John and Ken for rocking on bringing love to our toolchain!

Sun Ray Takes the Red Pill: APOC Goes Open Source!

Finally, after 8 months of hard work behind the firewall, we’ve made available the source code of A Point Of Control (APOC) under the freedesktop.org‘s umbrella. This is the first project released under an open source license by the Sun Ray group for which I work at Sun Microsystems.

 

What is APOC?

APOC provides capabilities to centrally manage
desktops and desktop applications in large scale deployments. It enables system administrators to deliver securely configured open source
desktop environments tuned to the needs and privileges of specific
users, roles, groups or hosts within the organisation.

Now, any system administrator can create grouped configuration settings as profiles for the most popular open source desktop applications and deploy them in their LDAP servers using their already existing hierarchy.

What applications does APOC support so far?

Support for applications are provided through adapters, so far we have only released the GConf adapter which is in the GNOME’s Subversion already. The Firefox/Mozilla adapter will be ready pretty soon.

StarOffice has support for it out of the box already, however, we haven’t started any roadmap to release the adapter code as an OpenOffice.org extension yet since we’ve been pretty busy with the core.

What does this mean from the open source desktop perspective?

It means that a big Unix/Linux deployment using a free software stack is a little bit more tasty for sysadmins, and we’re on feature parity with what Microsoft’s ActiveDirectory has been offering for a while already on the closed source desktop side.

What license have you chosen?

We have released the code under the CDDL/GPLv2 dual licensing model, as our neighbors from NetBeans has done recently. This will deliver both the flexibility of CDDL and the compatibility with the GPLv2 code out there so we can reach the maximum community audience.

How can I contribute?

We need testers!

Originally the code was developed to run in a small set of supported platforms (Solaris and some version of Linux), we’ve made some changes to make it more generic and allow people to try it from a wider amount of platforms, we need people to try it and report any issues that may arise.

We need packagers!

We want APOC to be present in most open source operating system distributions, we’re supporting Solaris here at Sun already so if you’re a distro packager for any of the Linux or *BSD major distributions, you’re more than welcome.

We need adapter developers!

So far we only have adapters for the Mozilla/Gnome/OO.org stack. We would love to see adapters developed for other desktop environments and applications (any KDE brave hacker around?), APOC is not desktop specific, it could be useful for any application installed on large scale deployments.

One tip for the OpenSolaris guys, a SMF backend would allow sysadmins to control which services are enabled or disabled on your build farm if an adaper is developed.

Join us!

Visit the APOC website, join the mailing list and the #apoc channel at irc.freenode.net for more information.

Happy hacking!