5 ms·

I think the best way to answer this question is to observe large open source projects and see what works best. Not because open source is inherently better tha

by dfranke 19y ago

I think the best way to answer this question is to observe large open source projects and see what works best. Not because open source is inherently better than industry at getting it right, but rather because open source projects conduct their business in public, so you can collect data a lot more easily.

wheels 19y ago
Well, I've been on the inside of that for years (in the KDE project) and could write volumes about what I've seen working and not working. But a lot of it doesn't work on the same plane; in most of the larger projects the drive to market the software and work in a business sphere comes years after the technology is there. An open source project can survive for a very long time with a simple website and a couple of mailing lists. But when it does try to make that jump it's often less than finessed.
- dfranke 19y ago
  Well, I've been on the inside of that for years (in the KDE project) and could write volumes about what I've seen working and not working. If you wrote that book, I'd buy it. The only writing on the subject that I'm aware of is a few passages of "The Cathedral and the Bazaar" and "The Magic Cauldron", and it seems like there's a lot more to be said about the topic.
  - wheels 19y ago
    The major points that I'd mention, reacting to what you said are: - It's not as open as it looks. Once projects grow over a certain size, either formally or informally a lot of the decisions are made behind closed doors. - There's a lot of variety here, from open source startups (Ximian, Canonical), to projects that after many years begin playing in the business field (GNOME, KDE). Open source startups work more or less like normal startups from what I can tell, except for you know, the code part and a little nominal open-ness. Big open source projects that started open and move to emulate corporate processes go through a lot of the fallout that happens any time there's an attempt to change established processes in an organization, but it's probably even uglier because the contributors have no particular obligation to stay and often the people pushing through the changes are learning how to do it on a several hundred person organization (which rarely happens in business). That doesn't mean that there's no real progress, but it's not something I'd want to emulate in a business. - Developers getting into a large OSS project usually learn how to be developers in that project. Most of them start off comparatively mediocre. This was certainly true for me, though I didn't realize it at the time. But usually after a project has been running for a few years they've developed a stunningly hard-core development culture which can take a mediocre hacker and turn him into a wunderkind in six months. When marketing first shows up on the radar, the guys are similarly mediocre, but they're several years behind the curve on developing a marketing culture and have to deal with a couple hundred hackers and their associated hubris to boot. - Eric S. Raymond is a bozo. Seriously. And just for reference, this isn't all specifically about the KDE project. I hang out around enough OSS guys that I've seen the same happen in several projects. There may have been some that have avoided it. I can't name any off the top of my head. Edit: I take that last point back. I can think of an exception. The guys that ate my lunch. :-) Amarok. From day one they starting building a community, marketing, worked on bringing people of all sorts into the project. That impressed me. (And from the get-go, we've been friends and swap a lot of code, so there's no bad blood.)

by dfranke 19y ago

wheels 19y ago

Well, I've been on the inside of that for years (in the KDE project) and could write volumes about what I've seen working and not working. But a lot of it doesn't work on the same plane; in most of the larger projects the drive to market the software and work in a business sphere comes years after the technology is there. An open source project can survive for a very long time with a simple website and a couple of mailing lists. But when it does try to make that jump it's often less than finessed.

dfranke 19y ago
Well, I've been on the inside of that for years (in the KDE project) and could write volumes about what I've seen working and not working. If you wrote that book, I'd buy it. The only writing on the subject that I'm aware of is a few passages of "The Cathedral and the Bazaar" and "The Magic Cauldron", and it seems like there's a lot more to be said about the topic.
- wheels 19y ago
  The major points that I'd mention, reacting to what you said are: - It's not as open as it looks. Once projects grow over a certain size, either formally or informally a lot of the decisions are made behind closed doors. - There's a lot of variety here, from open source startups (Ximian, Canonical), to projects that after many years begin playing in the business field (GNOME, KDE). Open source startups work more or less like normal startups from what I can tell, except for you know, the code part and a little nominal open-ness. Big open source projects that started open and move to emulate corporate processes go through a lot of the fallout that happens any time there's an attempt to change established processes in an organization, but it's probably even uglier because the contributors have no particular obligation to stay and often the people pushing through the changes are learning how to do it on a several hundred person organization (which rarely happens in business). That doesn't mean that there's no real progress, but it's not something I'd want to emulate in a business. - Developers getting into a large OSS project usually learn how to be developers in that project. Most of them start off comparatively mediocre. This was certainly true for me, though I didn't realize it at the time. But usually after a project has been running for a few years they've developed a stunningly hard-core development culture which can take a mediocre hacker and turn him into a wunderkind in six months. When marketing first shows up on the radar, the guys are similarly mediocre, but they're several years behind the curve on developing a marketing culture and have to deal with a couple hundred hackers and their associated hubris to boot. - Eric S. Raymond is a bozo. Seriously. And just for reference, this isn't all specifically about the KDE project. I hang out around enough OSS guys that I've seen the same happen in several projects. There may have been some that have avoided it. I can't name any off the top of my head. Edit: I take that last point back. I can think of an exception. The guys that ate my lunch. :-) Amarok. From day one they starting building a community, marketing, worked on bringing people of all sorts into the project. That impressed me. (And from the get-go, we've been friends and swap a lot of code, so there's no bad blood.)