Open source is the way to innovation!

Story: Closed source is dead, open source is the way to innovation!Total Replies: 6
Author Content
ColonelPanik

Jan 02, 2008
12:32 PM EDT
Great article, hope those anti-FOSS folks read this. HKwint is on the Do Read list with TC and that French chef.
azerthoth

Jan 02, 2008
1:19 PM EDT
heck of an article. I think I'll log in to digg (uck) and see where it goes.

*edit* Scott beat me to it */edit*

digg here: http://digg.com/linux_unix/Close_source_is_dead_open_source_...
hkwint

Jan 02, 2008
1:29 PM EDT
OK, thanks folks. I actually have been working on another article the last few days and this was a 'hurry job', so I'm glad it's not too obvious.
Sander_Marechal

Jan 02, 2008
1:52 PM EDT
Yeah, nice article. I see you still have your T-DOSE notes handy :-)

Quoting:open source innovation might be chaotic because it lacks direction


I wonder how this could be improved though. Google's SOC and bounty programs work reasonably to motivate people to work on specific problems, but what other great ideas can we come up with? How can we invite and focus more innovation without losing the benefits of the FOSS development model?
azerthoth

Jan 02, 2008
2:07 PM EDT
I have always like the idea of a "community bounty" sort of like what was done to the nouveau driver.

A need is submitted, interested parties pony up some money ahead of time as a completion reward, then the developer(s) who get a working version of what ever it is gets the reward.

Would also give the developers themselves a fell for what joe computer user is looking for.

hkwint

Jan 02, 2008
2:35 PM EDT
Quoting:Google's SOC and bounty programs work reasonably to motivate people to work on specific problems, but what other great ideas can we come up with?


Right now, I think indeed governments may be(come) an important mainspring behind open source innovation. On the other hand, we should make clear to people it's far easier to start participating in an open-source project than in a closed source project.

The main problem probably is, it's easier to write a new program than to join an existing project, find out how the code works, find out which particular habits and way of doing things the people in this project have, find out the style of the code, find out which of the persons of the project have authority over which parts, how to commit diffs and so on. For example, if I were a developer and wanted to join the KOffice team (I once intended to, but I can't program besides bash, BASIC and 100-line C++-programs), it would be quite hard to find out how to start.

Also, a project has to look 'inviting'. I remember fiddling with the XMMS-code (Don't stir it, it's poo!) to try to make different sizes of skins possible, when I get stuck. I should have asked for help, but for some reason I didn't do it. The people behind XMMS were planning XMMS2 and most XMMS users knew they were using an abandoned ship. Also, there were rumors XMMS' two maindevs weren't that open to new contribution (hence all the XMMS-forks and forks of XMMS-forks). The KOffice project was a good example of something that _did_ look inviting, if it hadn't been that complex and difficult (I wanted to work on MS-format import/export filters without ever having written some decent C++ code, so that was a rather bad joke!)
Sander_Marechal

Jan 02, 2008
10:27 PM EDT
@hkwint: That's why developer documentation is every bit as important as user documentation. I don't mean source code comments and the docs you can generate from it. That's only useful to understand the piece of code you're looking at. I mean a document that gives a decent overview of the system as a whole and explains what fits where. The general structure.

I did something similar for gnome-hearts: http://www.jejik.com/gnome-hearts/developers

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!