OSCOM has organized a hackathon/sprint on January 22nd and 23rd, 2004, at the ETH Zurich, Switzerland. Henri has posted the IRC logs of day one and day two.
Oh, what’s it about the OSCOM lemming effect? Discussed on day one:
(11:09:08) bergie: Michii is expecting to see a “lemming effect” if Epoz
goes to OSCOM and showcases that “leading CMSs” are implementing it
(11:09:13) bergie: …others would probably follow
An Economic Analysis of Scientific Research Publishing:
The report has been published to support constructive dialogue between key players in the scientific publishing field – publishers, researchers, academic institutions and funders. The ultimate aim of this dialogue would be to develop a publishing system that meets the needs of all groups, and best promotes the public good of scientific work – that is, disseminates research outputs to all who have an interest in them.
A good overview of problems, believes, solutions in scientific e-publishing, but the latest innovative incentives and projects are not mentioned – what about Weblogs, Creative Commons???
via gap-forum mailinglist
Peter Suber has put together lists on some aspects of the open access movement like
via gap-forum mailinglist
… asks Larry Rosen on the mailinglist of the Open Source Initiative and answers:
Of course we disclaim most warranties and liability in our licenses. Why should we willingly accept potential liability when we give our software away for free? Despite what our licenses say, however, we are subject to local laws relating to gross negligence and fraud. As a matter of public policy in many civilized jurisdictions, we can’t recklessly distribute damaging software to consumers and expect to get away with it.
So we should treat free software businesses as real businesses. Behave professionally and ethically in all our intellectual property transactions. The chances of being sued when we do that are slim to none. But it is wise
to put some money into your bank account just in case you need to hire a lawyer to answer all your questions.
In Germany, you are always reliable for the software you are selling to your customers.
If you really need to go to a lawyer, you should know what you want or need before you go there. Your lawyer is only as good as you are self-aware of your case.
The best thing you can do, is not to do any businesses with customers you sense that they act strange, overdemanding, insidious. If you do not feel good, don’t do it. Well, often you cannot afford sending away customers, then make sure you have enough money on your bank account, just as Larry Rosen proposes.
At LinuxTag, I got interviewed by a journalist from Politik-Digital, a German online magazine on political topics. Now, The online article has been published in German. It is a portrait of me, Sandro, the Open Source philosopher and revoluzzer 😉
The first public and stable release of the ZZ/OSS Installer Client (ZIC) is now available for download. The installer is an installation wizard as well as developer tool which allows for advanced release management and reusable components.
Read more about it in a online article in the International PHP Magazine about the ZIC.
Find more information about our new cool toy at the ZIC homepage http://www.zzoss.com/projects/installer/
In case, you have not heard about PECL yet or not yet trusted in it, read Wez’ posting to the internals mailinglist. In summary, PECL will make release management and installation of PHP extensions much smarter:
- PECL provides a way to keep your extensions self contained and allows you to keep your own release cycle.
- In addition, the packaging systems allows you to mark the package with explicit, versioned, dependencies.
- It is very easy to our users to install and upgrade these “pickled” extensions.
The ZZ/OSS Installer is based on the same packaging technology as PECL and makes release management and installation of PHP applications just as smart 😉
The OAI data provider PEAR::OAI developed by ZZ/OSS and implemented with PHP in PEAR fashion is now listed in the tools section of the OAI Web site.
The ZZ/OSS Installer Client (ZIC) for the Web browser will be released as a stand-alone application on December 15th. This is when the forthcoming issue of the International PHP Magazine ships with an article on the ZIC.
Currently, I am cleaning up the code base and I will later add some additional features. Alltogether, the ZIC should then be ready for use in PHP projects that want to profit from advanced packaging and release management, ensuring a high reusability of the application components.
These are some of the features of the ZIC:
– Provides a Web GUI aka installation wizard look and feel.
– Command line interface is under development.
– Allows definition of packages, applications, and distributions in XML.
– Automatic resolution of package dependencies.
– Tools for easier development of packages.
– Plugin framework for build routines (e.g. to set up or update a database from SQL dumps).
– Customization of HTML layout for in-house products.
– Supports full, minimal or customized installations.
– Allows for non-conflicting installation on shared hosts environments
– Installer can upgrade itself.
– Sources are LGPL licensed for greater flexibility in usage
Some known PHP developers have commented on the preview version of ZIC at this year’s Linuxtag:
Wez Furlong
Lukas Smith
Christian Stocker
My company partner Christian Zonsius is currently working on the ZZ/OSS Installer Server (ZIS) which forms the backbone of the envisaged deployment architecture for distributed package hosting. The ZIS will as well be released on December 15th, not as stable as the ZIC, but as a preview version for testing.
Both, ZIC and ZIS are based on concepts, ideas, and libraries that evolved within PHP’s PEAR community, namely the PEAR package manager and the PEAR Web. ZZ/OSS has extended these technologies, to make use of the defined standards and furthermore bring advanced release management to the application level (as compared to PEAR, where release management is only able on the package level of class libraries).
The PEAR group recently published New Guidelines for BC breaking releases. The idea is simple, for example one variant would be:
Old API: MyPackage-1.2.tgz
New API: MyPackage_2-0.9.tgz
Sandro Groganz 