I just set up a mock election on Selectricity, just to see what it could do, and was pleasantly surprised that they created a very simple interface for creating Schulze/Condorcet elections that pretty much anyone can use. I tried getting to this point a few years ago with Electowidget, but sadly didn’t get to a usable enough place (nor a maintainable enough site).
There’s a bit of a flamewar going on right now between the main PulseAudio developer, and another Linux desktop developer who grew frustrated by some very real problems caused directly and indirectly by it. PulseAudio is the latest of many savior technologies that promise to make audio on Linux not suck. I’m actually pretty optimistic that the fifth(?) time’s a charm here; there’s a lot of very sensible things about the design.
Anyway, Jeffrey Stedfast wrote a series of blog posts culminating in “PulseAudio: I told you so“. In these, he documents his frustration with being given the runaround when trying to point out PA problems that he ends up debugging to the point of finding and/or filing several bugs/patches in various bug trackers. PulseAudio creator Lennart Poettering had enough, and posted to his blog with a long rebuttal, claiming that Stedfast’s blog post “flamed my software and hence me”. It’s a pretty run of the mill developer flamewar, which only caught my eye because I’ve had a few frustrating problems with PA myself and was hoping to learn more.
(more…)
This article in CIO Magazine touches on things that you should look for in choosing open source software:
- Project stability: Can you trust the project to be there when you need it?
- Project support: Can you get support when you need it?
- Internal software management: Does your company know what open-source programs it’s using? How it’s developing and deploying them both in-house and to customers?”
I’m not so sure that these problems are truly bigger problems for open source as they are for software in general. When people in companies select a new piece of software (for use as a standalone product or as an integrated component of a larger system) they miss one important thing: it is much more like a hiring decision than they probably realize. Many of the considerations people make for new employees (reputation, cultural fit, how they are to work with) are equally applicable to new software components and systems.
(CIO article via Matthew Aslett @ The 451 Group)
Here’s a description of the organic open source panel at OSCON (which I’m participating in): “The OSI’s Open Source Definition attempts to set the minimum bar for a software license to be considered “open source”. However, there’s much more to a software project than just the license. Are software projects dominated by a single company still open source? Does a project need to be ‘organic’ to be truly open source? What does “organic” even mean in this context?”
My answer to the first two questions is “yes, of course projects dominated by one company are still open source, and no it doesn’t need to be ‘organic’”, where “organic” is (arguably) defined as a project which the first release included source, and is generally characterized as by a distributed development team with no single company truly in control, and “inorganic” is generally code that started off life as a proprietary effort. Yay, panel concluded, thanks everyone!
No? Ok, the line of questions above implies a question of quality, and there are very real qualitative differences between “organic” and “inorganic” open source…..
(more…)
Powered by WordPress