Posted on 2010-06-04 12:33:12 UTC in 60° 0.000 N 24° 0.000 E 28km S of Lojo, FI to Business. 0 comments.
At Nemein we have a monthly staff meeting to go through all project backlogs, new initiatives and happenings in the R&D side of things. Today the weather was nice, so we decided to keep the meeting in the nearby Sinebrychoff Park, armed with croissants, cake and the company waterpipe. Quite pleasant change from routine!
Thanks to Aslan for the cake!
| save money using, phone card |
Posted on 2010-06-14 17:32:42 UTC in 60° 0.000 N 24° 0.000 E 28km S of Lojo, FI to Business. 3 comments.
Both companies and public administration are starting to understand the benefits of free software: reducing vendor lock-in, possibility to continue development of a project after a vendor has gone out of business or lost interest, and in general enjoying the four freedoms. But unfortunately much of this understanding has been limited to the context of licenses.
In reality, licenses are only a small part of a project being truly open. They are just a layer of insurance comparable to traditional source code escrow.
What we really need is understanding of a bit more wholesome project openness. The actual goals of openness that the license should derive from. Here are some aspects to consider:
If a project aims to have outside users or contributors, they need to be able to see the history of changes in the software, decisions that have been made, and the open list of bugs or enhancements being worked on.
A released software package answers these questions poorly regardless of a license. Instead, what is needed is the project being developed out in the open, preferably using one of the common project hosting environments like Gitorious, GitHub, SourceForge, Launchpad or GNU Savannah. You can also host the project yourself using something like Trac or GForge but this limits access and visibility to the project.
The project must actually use the service, not just by code dumps at release time, but with constant development activity visible as code commits and active issue tracking. Depending on business goals it is also good to have future plans for the project visible to the public.
All of this is mandatory for others to gauge the viability of a software package to their needs. Josh Berkus presented a good list of things you shouldn't do to create a community around your project.
Potential users and developers need to know how they can make their changes available to a package. Is it possible at all, are copyright assignments or some contributor agreements necessary, is there a documented process for submitting changes or even becoming an acknowledged developer in the project? Or is the project being developed behind closed curtains of a company?
Another area some projects fail at is communicating how the software can be built and installed. If the only practical way to run the software is from released binary packages, or through buying consulting, is it truly open? Does the project require additional closed software or specific hardware to run with?
Depending on the type of software other concerns may be being able to provide it as part of a Software as a Service offering, or being able to deploy it on some constrained or closed hardware.
Some software licenses address these questions clearly, like EUPL requiring contributions to be opened also when the software is offered in SaaS manner, or GPLv3 forbidding device manufacturers from locking down or 'Tivoizing' their hardware products.
Most of these questions are well understood within the free software community itself. But we generally communicate it poorly by focusing the discussion on license technicalities. I guess this is because we're so used to working in this open manner that we take the it as a given. But users, especially in the public administration only see the licensing side of things because that is the only aspect we talk about and have definitions for.
A good exception for this is the Apache Software Foundation that has a well-defined set of rules that projects must follow before they can be adopted under the ASF umbrella. Maybe FSF and OSI should also publish some understandable guidelines and definitions for project openness?
Posted on 2010-06-23 12:02:17 UTC in 47° 0.000 N 13° 0.000 E 48km SE of Saalfelden am Steinernen Meer, AT to Desktop Midgard. 6 comments.
Midgard2 10.05.1 was released yesterday, bringing a long-waited feature finally to the Midgard installation packages: the Midgard Runtime.
Midgard Runtime is an application that consists of a simple Qt WebKit viewer that, when run, starts a local Midgard web server on the background and connects to it. This means that you'll have the full Midgard MVC stack available on your own desktop, in a way that is easy to install and easy to run. Get it for your favorite Linux distribution from OBS!
As a whole, the Midgard Runtime stack is quite interesting:
The AppServer is particularly something that other PHP projects might find useful. Since the server itself is written in PHP you don't have any additional dependencies besides php-cli. It also means your application can use a lot more efficient caching as files have to be loaded only once, and things can be kept in memory between requests. Of course the downside is that if your PHP script dies, then the whole server is down. But that is easy to deal with by a bit of defensive programming.
At this point the Runtime is targeted at web developers interested in trying out Midgard, but eventually we'll be using the bundle system also for distributing full Midgard-powered web applications to the desktop. The progress on this can be followed on GitHub.
Compared to Nokia's Web Runtime, the Midgard Runtime should be more familiar to developers as you'll be able to write also server-side PHP code, not just JavaScript. In addition to PHP, the whole system is also accessible via any language that can handle GObject Introspection.
Posted on 2010-06-28 12:54:47 UTC in 60° 0.000 N 24° 0.000 E 28km S of Lojo, FI to Desktop Kde Midgard Mobility. 0 comments.
We tried to get the combined GUADEC and aKademy conferences to Tampere in 2009, but a warmer place unfortunately won. However, we will be hosting this year's aKademy so at least KDE and Qt fans will get to enjoy this beautiful northern industrial city.
The main conference will be held at the Tampere University over the weekend, and then the remaining hackweek will be in the nice Demola facility in the Finlayson district. Expect great connectivity and close proximity to all Tampere nightlife.
I'm involved with two aKademy activities:
In addition there will be a Maemo / MeeGo meetup in the Plevna brewery on Friday evening. See you there!
