Open source is the way to innovation!
|
| 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!