Two thousand open source applications for the public sector

The European Union's Open Source Observatory and Repository (OSOR.eu) as of today is offering public administrations access to more than two thousand free and open source applications.
The OSOR is a platform where public administrations can exchange information and experiences and collaborate in developing free and open source software. The platform has managed to bring together more than 2000 such open source software applications in just sixteen months after its launch.
The most recent projects added to the OSOR repository include Zorb, an extension to the open source network monitoring tool Nagios, Comerzzia, meant to aid public administrations in providing services to SMEs and Genericoder, an open source converter for XML files.
Francisco García Morán, Director of Informatics at the European Commission, welcomed the milestone of 2000 projects. "I officially opened the site in October 2008 at the Open Source World Conference in Malaga."
-
- Login or register to post comments
Printer-friendly version
- 1241 reads
PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
Events: Video Conferences, Code.gov, and LibreOffice
| GitLab Web IDE
|
Record Terminal Activity For Ubuntu 16.04 LTS Server
At times system administrators and developers need to use many, complex and lengthy commands in order to perform a critical task. Most of the users will copy those commands and output generated by those respective commands in a text file for review or future reference. Of course, “history” feature of the shell will help you in getting the list of commands used in the past but it won’t help in getting the output generated for those commands.
| Linux Kernel Maintainer Statistics
As part of preparing my last two talks at LCA on the kernel community, “Burning Down the Castle” and “Maintainers Don’t Scale”, I have looked into how the Kernel’s maintainer structure can be measured. One very interesting approach is looking at the pull request flows, for example done in the LWN article “How 4.4’s patches got to the mainline”. Note that in the linux kernel process, pull requests are only used to submit development from entire subsystems, not individual contributions. What I’m trying to work out here isn’t so much the overall patch flow, but focusing on how maintainers work, and how that’s different in different subsystems.
|
Recent comments
3 hours 4 min ago
3 hours 5 min ago
3 hours 6 min ago
6 hours 13 min ago
6 hours 24 min ago
13 hours 17 min ago
1 day 15 hours ago
1 day 16 hours ago
1 day 22 hours ago
2 days 23 hours ago