Open-Source Component Repository?

Aiken wrote in looking for comments on an idea he's had. To sum it up, what do you all think about this: "The development of a central GPL'd component repository would be an asset to the open-source community". My question: Do you all think this exists (couldn't Freshmeat be used for this purpose) or is this a niche that is still open? There is MUCH more to this, so if you are interested, please click below.

The following was submitted by Aiken:

Premises

• Companies that do extensive programming develop their own software libraries... binary trees, networking code, graphics routines, things that need to be done in all sorts of programs.
• While the open-source community has developed excellent tools (emacs, ecgs, etc.) to do their programming on, we have not developed such components.
• A critical issue facing open-source developers is how to find other developers who will contribute to their project.
• Having access to well-tested and proven components such as these could greatly decrease development and testing time needed for other software.

Conclusion

The development of a central GPL'd component repository would be an asset to the open-source community.

Elaboration

Consider the Standard Template Library. Linked lists, stacks, queues, and the like can all be used without having to write them from scratch and debug them. This saves time and improves readability, since they follow a common syntax and have common operators.
The open-source community is not bound by restrictions held on the standard library. We can write code that deals with networking and image formats that are commonly used, regardless of whether or not they are in the standard.
Generating repositories of these components would allow casual programmers to dip into a vast resource base. Instead of spending their limited time finding other programmers to help out, they could simply take and use the code that was already written for them. Rather than create a subroutine for a single program, you would create a component which could be used in hundreds of programs by developers you didn't know existed.

Issues to Consider

Just some kinks in the idea that I can see needing to be worked out:

• How to ensure that components are GPL'd... e.g. that some student's university doesn't want to claim credit for the code they wrote
• How to ensure quality code and documentation
• Who should run the repositories
• What components to provide

Thoughts? aiken@quakemail.com.

Comments

Why not modify CPAN?

[Imperator]

Why not take the existing CPAN system, modify it to support the features we'd need for this sort of distributed project, and use that? It would need support for multiple languages (say, CPAN::Perl, CPAN::Cplusplus, CPAN::COBOL, all inheriting from CPAN.pm), the ability to specify what parts of the archive different mirrors have (because not every site will want to carry the COBOL stuff), some sort of automatic configuration for people who want it (face it, manual configuration is easier to implement but often unnecessary), and a new name (CLAN? :).

This is a GPL'd system written in a GPL'd language that's available on a wide variety of platforms. Why reinvent the wheel to prove that we don't have to reinvent the wheel? :)

Already exists....

[Forrest J. Cavalier]

Went online in October.
http://www.rocketaware.com/

Includes special sections for GNU software, BSD man pages, FAQs, AskSlashdot (back to the beginning), Programming related books. Even has links to cosource.com, dmoz, yahoo, fatbrain, amazon.
Over 15,000 off-site programming related links. You must check it out. A single idea just like the one that started this thread was discussed about 18 months ago. This is the result.

On tap: (coming up) on site discussion, all of the unc metalab linux archives, and anything else we think of or get suggestions, or gets submitted.

Build GUI-free CORBA SERVERS

[Christopher B. Brown]

Some good ideas here; it is definitely important not to build components so that they will be heavily dependent on one "Desktop Environment" or another.

The example that I keep citing (and nobody has ever done anything to bring to fruition) is that of the calendaring systems. GNOME and KDE both have calendar programs that "grok" the iCalendar specification, but only partially. In particular, iCalendar was designed to allow "Calendar clients" to connect to a "Calendar server" that could provide schedule information for multiple users.

What they should do is to define a CORBA interface to talk to a Calendar server; by having common IDL that would be free of ties to any GUI there could be one implementation of a Calendar server that both the GNOME and KDE clients would talk to.

This is much same idea as the notion that any sort of web browser can talk to an HTTP server.

Don't be so sure that KDE has "dissed" CORBA as dramatically as you're thinking; what they have concluded is that running raw GUI calls through CORBA to implement compound documents is quite ridiculously inefficient. Note that the GNOME guys have largely concluded the same thing. (ORBit appears more efficient than MICO, so GNOME may get away with doing more with CORBA than KDE can...)

The point is that CORBA has enough overhead involved that you don't want to be shipping around tens of thousands of CORBA calls per second.

On the other hand, using CORBA to request:

• ... That a text editor be invoked to edit a file,
• ... That a document, specified as a tree, be submitted to a printer,
• ... That a bundle of configuration data be retrieved

all represent areas where there's large enough "granularity" that CORBA can be useful.