Re: First draft of application to Sovereign Tech Fund

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Karl,
I think you are right. Let us concentrate on Automake first. Your changes to the application are making the statements more clear, thank you. I removed OpenJDK and LibreOffice, as they are not using Automake. If you know two other widely known projects using Automake, we could add them instead.

Find the complete application text below. Can you please confirm that I should submit the application to STF?

Kind regards,
Christoph


>> Application

> Category

Join the Bug Resillience Program

> Application name

Autotools

>> Project

> Project title

Automake Direct Contribution 2024

> Link to project website

https://www.gnu.org/software/automake/

> Link to project repository

https://git.savannah.gnu.org/cgit/automake.git

> Where is your open source technology project being
> used (describe all user bases)?

GNU Autoconf and GNU Automake are the core of the GNU Autotools. They help in making source code packages portable to virtually all Unix-like systems. They are used by GNU GCC, among thousands of other packages. The interface that they implement is the standard for GNU.

> Why do you consider your open source technology project
> to be relevant and critical?

Many projects rely on Automake (and Autoconf) as crucial part of their build system. Moving to alternatives is challenging. Without a working build system, users might not be able to build the software using the build system.

> How does your open source technology benefit the public interest?

A build system is like water or electricity, it is supposed to work and nobody thinks about it. Once service is disrupted, we realize how much depends on it. Many users never know of Automake. The programmers and packagers work behind the scenes, relying on the build systems effectiveness.

> Please describe the history and state of development of your open
> source technology

Automake automatically generates input files for Autoconf and adds dependency tracking. Version 1.0 was released in 1996. Automake is (primarily) implemented in Perl, and also uses m4 and shell scripts.

Automake is completely dependent on Autoconf, which is an extensible package of M4 macros that produce shell scripts to automatically configure software source code packages.

Autoconf and to a somewhat lesser extent Automake became very popular in the 2000s, as extremely portable and adaptable build systems. It is often possible to configure a package for compilation on a new system without user intervention.

Plenty of projects haved switched to other build systems for various reasons, but numerous projects still rely on the Autotools.

> Which BRP services are you interested in?

[x] Direct Contributions
[ ] Bug Bounty Program
[ ] Secure Code Audits

> Describe why your project needs those services?

Automake (and Autoconf) have relatively few contributors, and thus releases are infrequent and some bugs, especially system-dependent ones, have remained unfixed for years. The many dependencies (GNU m4, GNU libtool, plus (f)lex, bison/yacc, compilers, etc.) make it relatively difficult for newcomers to make substantive contributions without significant effort.

On the other hand, C, C++, Python, and other languages are evolving, and the new versions of these language standards are often backward-incompatible with existing code and practice. Thus the Autotools must adjust.

We are hoping for direct contributions, particularly fixes for open bugs.
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake




[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux