Updates from April, 2007 Toggle Comment Threads | Keyboard Shortcuts

  • Roberto Galoppini 4:46 pm on April 3, 2007 Permalink | Reply  

    (almost) Open Source Security: StillSecure takes off the wraps and tell us about Cobia 

    Yesterday StillSecure, a firm founded in 2000 specialized in creating secure network infrastructure software, announced Cobia, an (almost) open source modular framework for networking and security.

    Christian Koch, Network Engineer at a technology infrastructure services company, said:

    The convergence of networking and security is increasingly requiring administrators to deploy solutions once and then redistribute them across the network as needs evolve. Cobia is the first real option for those who understand the benefits of using an open, modular, software-based approach to networking and security, and how it enables users to take advantage of advances in general computing hardware to dramatically decrease cost of ownership.

    Currently the Cobia platform is in the beta phase, and apparently its community, currently reaches over 1,000 users involved.

    There are two Cobia licenses, the community one, named after the company StillSecure Community License 1.0, is not approved by OSI and I believe it doesn’t qualify, since it requires you to sign a Contribution Agreement if you distribute modified version of the software.

    Mitchell Ashley, StillSecure CTO, summarized Cobia characteristics as follows:

    1. Cobia is a software platform for networking and security.

    Cobia can operate on a variety of hardware platforms (Intel/AMD) including off-the-shelf servers and computers, hardware appliances, blades such as blade servers and blades within network infrastructure gear.
    2. Cobia is plug-n-play network and security modules.

    [..] Cobia is all about modularity, right down to its software architecture. Cobia Modules for networking and security are available today on the Cobia site. Additional modules are under development and as the Cobia community grows, I anticipate there will be a variety of people creating modules for Cobia.[..]

    7. Virtualizing the network.

    [..] Cobia ushers in virtualization for networking and security right now. Today, you can run Cobia as a VMware instance on Windows or Linux. Download Cobia from the site ready to run in VMware.

    Technorati Tags: commercial open source, security, cobia, stillsecure

     

  • Roberto Galoppini 8:12 am on April 3, 2007 Permalink | Reply  

    Free Software Award: Sahana won the annual award for Projects of Social Benefit 

    Sahana , an Open Source Disaster Management system that addresses the common coordination problems during a disaster from finding missing people, has won the 2006 Free Software Award for Projects of Social Benefit awarded by the Free Software Foundation.

    The Free Software Award for Projects of Social Benefit is presented to a free software project that intentionally and significantly benefits society through collaboration to accomplish an important social task.

    Sahana was created, in the wake of the tsunami that devastated Southeast Asia in 2004, to compensate for the devastating consequences of a government attempt to manually manage the process of locating victims, distributing aid and coordinating volunteers.

    Four members from the Sahana team (Chamindra, Pradeeper, Mifan and Ravindra) were present at the meeting to receive the Free Software award for Project of Social Benefit!! This is a truly great achievement, kudos to you all!

    As reported by Anuradha Weeraman besides the four members from the Sahana team (Chamindra, Pradeeper, Mifan and Ravindra) other notable attendees were present, like Bruce Perens and Ted Ts’o.

    The presentation by Mako Hill on “Defining Free Culture” was quite informative on some of the good work he’s been upto lately. Eben Moglen’s oratory was impressive as always and Gerald Sussman confounded the audience with some deep mathematics. RMS spoke on software patents.

    The Sahana project leader Chamindra de Silva said:

    We are deeply honored to receive this award and were so excited we traveled half way around the world from Sri Lanka to attend the ceremony today. The Sahana project is all about a cohesive disaster response between multiple agencies and bringing them together to help victims. None of this would have been possible without the work of the wider free software community, and we would not have been able to bring benefit to the victims and the people who help the victims without that. It is a credit to the whole community.

    Technorati Tags: sahana, FSF, FreeSoftware Award

     

  • Roberto Galoppini 7:33 am on April 2, 2007 Permalink | Reply  

    Open Source Production: Time-based release management 

    Martin Michlmayr, a well known Debian developer and formerly Debian Project Leader, is completing his doctoral thesis at the University of Cambridge with a thesis entitled “Quality Improvement in Volunteer Free, and Open Source Projects: Exploring the Impact of Release Management“.

    Time Time by gastronauten

    I happened to know about his thesis reading an article on linux.com, and I saw also Matt Asay posted on the subject, so over the weekend I took my chance to read it.

    First I wish to public thank Martin to mention our paper “Capability Coordination in Modular Organization: Voluntary FS/OSS Production and the Case of Debian GNU/Linux“. He cited our findings talking about release management in volunteer teams and also about problem of organization when a coordination effort is required to accomplish complex goals.

    I totally agree with him when he states that the ‘release when it’s ready’ policy might heavily affects large (complex) projects, because:

    It can lead to delays, out-of-date software, and frustration, and it also means that users and vendors cannot plan, because nobody knows when the software will actually be released.

    I remember Mark Brewer, Covalent CEO, saying that, even if Covalent has about 40 software engineers involved with Apache, they can’t assure that a feature will be available at a certain date. He also did similar considerations talking about road-map’s decisions. No wonder though, that is the way it is when it comes to community-driven Open Source projects.

    Getting back to Martin research his abstract reports:

    This dissertation explores why, and under which circumstances, the time based release strategy is a viable alternative to feature-driven development and discusses factors that influence a successful implementation of this release strategy. It is argued that this release strategy acts as a coordination mechanism in large volunteer projects that are geographically dispersed. The time based release strategy allows a more controlled development and release process in projects which have little control of their contributors and therefore contributes to the quality of the output.

    I read some chapters of the paper, and I was impressed by the quality and the depth of his studies. I believe that the introduction of time based releases leads to a more controlled development, positively affecting the resulting overall quality. In his words:

    [..] the time based release strategy can be considered as an important means of quality improvement in FOSS projects.

    Kudos to Martin to honestly have highlighted that there are problems in Open Source projects, he also stressed the importance of Regularity and the Use of schedule. As a matter of fact the use of schedule claims a project management function (release manager), reducing somehow the degree of independence among contributors. Our research in this respect stated that:

    [..] a pure modular structure – that is one lacking of hierarchy, such as a market – embeds flexibility, but it lacks coherence, the ability to coevolve after adapting to change.(cfr. Langlois Richard “Do firm plan?” 1995)

    A hierarchy is a must, then, when you need to manage a complex activity coordinating many contributors, either volunteers or employees. Martin makes clear that policies and infrastructures are needed to support his release strategy.

    Reading the paragraph “Limitations and Future Research” I would suggest another question:

    Introducing time-based release management could move developers’ focus from software’s effectiveness to meeting release targets? How to balance the trade-off between time and quality?

    Technorati Tags: Open Source, Modularity, Hierarchy, Coordination costs

     

    • Simon 11:22 am on April 28, 2007 Permalink

      How to balance the trade-off between time and quality?

      I think this is the key question.

      GNOME has happily released versions with key features missing because they weren’t ready in time. This just isn’t viable for a commercial provider of desktops, who would then have to cover for the “failure” of the open source model, probably by not shipping that version of GNOME in their desktops.

      Ubuntu similarly has shipped releases with major holes in them, again something that the proprietary world would not do, because it would slow adoption, and defeat the commercial point of a release.

      Sure clearer time tables, and clearer planning may be good for organizing the work, but ultimately deadlines will go whoosh, if the work isn’t done, and that is how it needs to be if people depend on the product finally delivered.

    • Roberto Galoppini 7:29 pm on May 1, 2007 Permalink

      Simon,

      I totally agree with you, at the end of the day time-based release management can address few issues indeed, but it is not a panacea.

      In another post I mentioned that within an hybrid production model paid employees are often responsible for less attractive tasks, as results from “GNOME, a case of open source global software development”, also by Martin.

      Corporate production has to be on Time on Budget. The firm solves the problem of finding the efficient management of human resources through time not allowing the free entry and exit, and delegating production control to a manager.

      Community-based production on the contrary allows volunteers to enter and choose their tasks. Volunteers choosing what to do apply for tasks they like, and that they are likely to accomplish effectively. They can also freely exit from a project though, or not to end their tasks on time.

      Do you agree?

    • Jon 3:58 pm on March 3, 2008 Permalink

      I don’t see why dropping features to hit a target is necessarily a hallmark of F/OSS process failure. Consider Microsoft pulling WinFS from Vista.

      The company I work for will not consider using Debian for any server because of the lack of any kind of predictable release cycle. Indeed, having a commitment to (say) 12 month release periods, and missing that commitment, would be better than none at all.

  • mfioretti 8:58 am on April 1, 2007 Permalink | Reply  

    File Format: Hidden traps in OpenDocument (or any other open standard) and how to avoid them 

    (Note: this post is an excerpt and a follow-up of an article published in December 2006 in the monographic issue on the OpenDocument Format by Upgrade, the online version of the Spanish magazine Novatica. The whole monography can be read online)

    It is almost sure that, eventually, all major producers of both proprietary and Free software in the office files space will support OpenDocument. In and by itself, however, that standard is open to several ways to keep monopolies possible, or to nullify its usefulness for long term archiving.

    Technically speaking, OpenDocument is very powerful and useful because it can be extended. The standard doesn’t mandate, however, nor it should, that all extensions are licensed in the same way as the standard itself. Even ignoring future extensions, the standard as it is today has plenty of backdoors for proprietary traps. Some examples are (see the full Novatica article for details):

    • digital signatures
    • macros
    • embedded images, audio or any other multimedia object embedded in texts spreadsheets and presentations
    • in-file databases

    Objects of this kind can be placed inside an OpenDocument file even if their format is accessible only through patent-covered or otherwise proprietary software. Nothing in the OpenDocument specification prevents this (and, again, it shouldn’t!).

    The practical consequence is that it is possible to have a perfectly Free as in Freedom XML container which is full of patent-ridden components. A container, in other words, which is culturally, economically and politically useless to guarantee long term preservation of information, public ownership of public documents or a really free market in the software industry.

    If anything, the fact that an office file standard is not owned and controlled by one vendor may make it even easier, not harder, than proprietary extensions appear to keep end users locked in, at least in some scenarios.

    Does this mean that OpenDocument is useless?

    Not at all. Personally, I am still convinced that OpenDocument is by far the best possible solution for a very serious problem. To the best of my knowledge, OpenXML is still much worse than OpenDocument both in terms of feasible support in third party applications and in terms of space left to reinventing the wheel and unnecessary proprietary extensions . For these reasons, I remain convinced that it is necessary, at least for creation of new public documents, to just say no to OpenXml (available to unregistered users by the end of April).

    At the same time, I am convinced that it is necessary to stop, at least in the public sector, to just “switch to OpenDocument” and feel happy about it without looking behind the corner. I believe that further steps need to be taken, steps which, by the way, are not specific to OpenDocument.

    What is the right solution?

    OK, so “100% OpenDocument (or OpenXML) Compliance” isn’t enough to guarantee that an OpenDocument report or law proposal stored today will be completely readable and usable 20 or more years from now. The real solution, however, is not a technical one. Technical ways to apply it once it exists are available, and they are mentioned in my Novatica article.

    This said, this is not a format specification issue. When present, technical extensibility of a standard is (and must remain) neutral with respect to intentions. It would be very inefficient, if not plain wrong, to place specifications of a legal nature inside what must remain purely technical documents.

    What I believe to be necessary is to establish and enforce:

    • in the first place, some official “OpenFile” trademark or equivalent label which can be legally applied only to files in which no component has restrictive licenses or uncomplete documentation
    • immediately after that, laws requiring that OpenDocument files can be stored by, or exchanged with public Administrations, libraries and so only if they carry this “OpenFile” seal. Exceptions to this rule should be temporarily granted only in really exceptional cases, when there really is no alternative

    What do you think? Are these conditions enough? Who should define the “label”? Governments or standard bodies? Who should enforce its usage? Which exceptions could or should be tolerated? Please let me know: I am very interested to hear your opinion and to participate in any future discussions on these issues!

    (Thanks to Roberto for suggesting that I write this post and for hosting it!)

     

    • Llorenç Pagés 9:59 pm on April 18, 2007 Permalink

      I think that your arguments are very interesting and the dilemma you are posing very challenging.

      I have translated your message into Spanish and posted it onto the ATI debate forum devoted to Open Document Standards

      I am planning to summarize and post that summary here, if exist, the most interesting opinions we collect on the ATI forum.

      Thank you very much Marco for giving me permission to make that translation.

      Llorenç Pagés
      Chief Editor of Novatica and Upgrade

    • Hikari 4:59 pm on February 19, 2012 Permalink

      Well, the features you listed are needed, and some of them can’t be open.

      Digital Certificate code can be open, I believe its hash data can also be, does ODF formats support it? But, AFAIK, there’s no open software to handle DC, and editor must access its proprietary DLL to sign the document. In the same way, to validate the sining we must access its AC. Would we wanna give up on signed documents and DC?

      Macro is editor-related in the way that it automates editor features, it can’t be standardized because it’d limit how editors work. Well, we need macros to automate our work, and when we decide to use it we know it will be bound to current editor and we’ll have trouble porting it to other editor, even the same model in different version. The solution would be ODF formats support multiple macros in them, related to specific editors, in a way that one editor can’t change or delete other editor’s macros. OR, macros be completely banned and each editor create external files to store its macros.

      Embedded multimedia data is also trouble. HTML 5 supporters are having hard time for years to define which formats will be standardized. Of course, any user worried with long time storage will use properly formats for their multimedia data as they do with their text, be we also can’t stop users from storing proprietary formats, because they’d get angry and go to Micro$oft ones.

      In general, I think ODF formats don’t need to force “openess”, they just need to support and allow it, and each user uses it in the way it’s better for them. Let’s not forget GIF, whose support is gone for years but is still largely used and supported by readers and editors.

      What we can’t allow, at any cost, is that editors add proprietary data inside ODF files without user explicit knowledge and acceptance, because if that’s done the user will only find out years later when it’s too late.

Newer posts →

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel