For our October “Staff Pick” Project of the Month, we selected Octave-Forge, a collection of packages providing extra functionality for GNU Octave. Octave-Forge was previously elected “Community Choice” Project of the Month in July of 2015. Recently we caught up with the team behind the project, and they shared some thoughts about the project’s history, purpose, and direction.
SourceForge (SF): Tell me about the Octave-Forge project please.
Octave-Forge Team (OT): GNU Octave is a high level array programming language. It is primarily intended for numerical computations and is mostly known for being compatible with the Matlab language.
The Octave-Forge project provides multiple packages for GNU Octave which extend Octave into specific applications such as control systems, symbolic mathematics, image processing, statistics, and interval arithmetic. It also provides a collaborative environment for development of Octave packages and is another nexus of the Octave community.
SF: What made you start this?
OT: The project started in 2001 by Paul Kienzle and Andy Adler, neither of them is involved in the project anymore. At the time, GNU Octave was developed by John W. Eaton alone and—while the CVS repository was public—he was the only person reviewing the patches from a community rapidly increasing in size. New releases were too slow and patches would take too long to be reviewed.
Their solution was to start Octave-Forge, a separate project where the rest of the community could contribute directly. At that time, the project would make use of subversion, have multiple developers, and have shorter release cycles. With time, new functions in Octave-Forge could be improved and migrated to GNU Octave.
Eventually, Octave-Forge became too large and unmaintainable. A lot of its contributions comprised one-time code dumps. This was all before GNU Octave had support for packages. Then, Søren Hauberg became the administrator of Octave-Forge. To solve the issue, he implemented “pkg”, still the package manger for GNU Octave, and split Octave-Forge into multiple packages each with its own maintainer.
SF: Has the original vision been achieved?
Octave-Forge has 68 domain specific packages and more than 30 active developers. In addition, most of its packages are bundled with the binary releases of GNU Octave and packaged in Debian, Fedora, and Ubuntu.
29 of our packages have received updates within the last year. Most of the packages are compatible with a wide range of Octave versions, thus we can bring regular updates to a large number of users, who may install packages directly from Octave-Forge—even on old systems.
At Octave-Forge we have gathered several developers who are not directly involved in the development of Octave core, but publish extra functionality.
SF: Who can benefit the most from your project?
OT: Anyone who writes programs in Octave.
Not that they need to be told. We don’t believe there’s anyone nowadays writing Octave code, which is not using at least one of the Octave-Forge packages.
However, Octave-Forge packages are bundled with the official GNU Octave releases. We hope that users see the packages as an integral part of Octave and don’t perceive Octave-Forge as a separate software project. So, very few of them might actually know about it.
SF: What core need does Octave-Forge fulfill?
OT: When GNU Octave is missing functions for a particular task, the packages from Octave-Forge provide optional extensions, e. g., libraries of functions, new data types, or new I/O interfaces.
SF: What’s the best way to get the most out of using Octave-Forge?
OT: GNU Octave has an integrated package manager and packages from Octave-Forge can be installed or updated with “pkg”, similar to Perl’s CPAN, python’s pip, and ruby’s gems.
On the Octave-Forge website we also provide a complete function reference for both the GNU Octave language and packages, with examples, demos, and further documentation.
Finally, most functions in Octave-Forge are written in the Octave language (m-files) and so can easily be inspected, modified, and improved by the user.
SF: What has your project team done to help build and nurture your community?
OT: We help new Octave package developers with the technical hurdles of bundling Octave functions into an Octave package which can be used by others. We provide documentation and an example package to help with this task.
During each package release, we help the package maintainer to check for common oversights, licensing issues, compatibility, portability, and completeness of the Octave-Forge package.
SF: Have you found that more frequent releases helps build up your community of users?
OT: Each release announcement is a chance to attract new users. For example, whenever we release a domain-specific package, we can advertise the use of Octave in that domain. However, we have observed little direct echoes from that.
For Octave-Forge, regular releases are rather a method to stay compatible with the development and enhancements of GNU Octave.
SF: What was the first big thing that happened for your project?
OT: Being able to install packages from within Octave.
SF: How has SourceForge and its tools helped your project reach that success?
OT: With SourceForge we are able to host several source code repositories for our individual Octave packages together with a website where we present each package and the functionality that it provides. We have the freedom to choose between several version control systems, i. e., we can use mercurial (which we prefer) and git.
SF: What is the next big thing for Octave-Forge?
OT: We are thinking about a fully decentralized Octave package archive. Something like CPAN. However, this would rather become a separate project.
Currently, we have a small Octave-Forge project team, which acts as a gatekeeper for new package releases. This doesn’t scale well and some package authors want to be able to independently release Octave packages on their own without a central authority.
SF: Do you have the resources you need to make that happen?
OT: Most of our contributors come from a scientific background and their expertise is not in the area of software maintenance.
We would have to build a good set of automatic validation tools and infrastructure to help make releases without manual intervention. Probably this also requires us to simplify package management in Octave core to lower the entry barrier. We would have to evaluate some legal framework regarding the redistribution of foreign, unchecked content.
This project is not a priority at the moment, so it lies in a distant future until we see a stronger need for it.
SF: If you had to do it over again, what would you do differently for Octave-Forge?
OT: We had to learn, which approach works best in the Octave community to attract new contributors and to maintain the overall project. Our setup today—with domain-specific packages, individual package maintainers, and many helping hands to keep the packages in good shape—works quite well, but we have much room for improvement.
This project is constantly improving and changing while contributors come and go. There probably would have been no better way to start our journey.
The post October 2017, “Staff Pick” Project of the Month – Octave-Forge appeared first on SourceForge Community Blog.
[Category: Open Source]