Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Open Source About the People 91

Posted by ScuttleMonkey from the shiny-happy-people dept.
An anonymous reader writes "InfoWorld has a nice look at what defines an open source venture. It seems that the main area of interest, and difficulty, rests with the personnel surrounding the project. From the article: 'But the muddier waters are around the personalities and commitment of the engineers who created the code. How long do they intend to stay? What is their level of commitment? These are fuzzy types of questions - but we know from history that when the core team of engineers that best understands the code up and walks out ... it tends to send a company into a death spiral.'"
This discussion has been archived. No new comments can be posted.

Open Source About the People More

Open Source About the People

Comments Filter:

  • The Missing Link (Score:5, Informative)

    by Baricom ( 763970 ) on Sunday June 18, 2006 @02:49AM (#15557467)
    The anonymous submitter was apparently too cowardly to submit a link to the article [infoworld.com]. I think that's the one he wanted.
  • The link that post contained pointed to what may well be the most informative, insightful, and entertaining read I've had all year.
    • Though it lacked depth and breadth, it was uncannily accurate.

    • Re:Great article! (Score:5, Insightful)

      by ozmanjusri ( 601766 ) <aussie_bob@hoMOSCOWtmail.com minus city> on Sunday June 18, 2006 @03:48AM (#15557556) Journal
      Great article!

      You're kidding, right? All it says is that if key developers leave a project, the project will struggle. Duh, and obviously that's not unique to open source software, it's true of closed source projects too.

      What's not said in the article is that if the core engineers leave a closed source project, the project and the company may fail and leave the customers stranded. If the core people of an open source team leave, they are free to take the code with them and fork the project, so the customers have continuity (Xfree, Mamba etc are examples)

      From a company's point of view, that's scary - if you upset your developers, you stand to lose your entire product, as well as the people who built it. For the customers and developers though, it's all good. The company has to keep the developers happy so they'll stay, and the customers know their software will outlast the company.

      • Re:Great article! (Score:3, Informative)

        by Eideewt ( 603267 )
        Yes, he's kidding. There was no link in the post.
        • Yes, he's kidding. There was no link in the post.

          Do'h! Hey, can everybody please submit a bunch of good stories and get this off the front page in a hurry. I'm feeling really dumb right now.

          • Do'h! Hey, can everybody please submit a bunch of good stories and get this off the front page in a hurry. I'm feeling really dumb right now.

            Here's a good thing to keep in mind, both in slashdot and in real life. It turns out that nobody really cares about you as much as you think, so don't sweat it. I don't mean you specifically, I mean generally. I just couldn't bring myself to write the retarded "nobody cares about one as much as one thinks."

      • Let's get beyond the simple binary 'all closed source is bad for customers/users, all open source is good". In an ideal world yes, but open source developers as people have many of the same motivations as closed source developers and the reason they leave a project may be similar - they might be bored with what they are doing, get a better job offer somewhere else, and *not support the software any more*.

        The open source code might *potentially* be resurrected by other developers, but it might not. Leaving c

        • Re:Not "all good" for the customers (Score:4, Insightful)

          by asuffield ( 111848 ) <asuffield@suffields.me.uk> on Sunday June 18, 2006 @06:21AM (#15557748)
          Let's get beyond the simple binary 'all closed source is bad for customers/users, all open source is good". In an ideal world yes, but open source developers as people have many of the same motivations as closed source developers

          Let's not. The simple binary is in fact the right answer, so long as you don't complicate it. Here's what I mean:

          A software project can have many attributes that determine how good or bad it is for you. One of these is whether or not it is free software. A free software project is always superior to a non-free project that is otherwise identical (if you're the user). It has been repeatedly shown that this particular attribute is not tied to any of the others - it doesn't determine their values. It may share causes with some of them, but there are many possible causes to choose from, so just knowing whether or not it's free software doesn't tell you anything. So a project can be free but otherwise suck, or it can be proprietary but otherwise good, or any other combinations.

          So long as you keep it as that one-bit value, 'free' vs 'non-free', it makes sense. The failure you're referring to lies in assuming that this bit affects any of the others - it doesn't really. Often people confuse 'free software' with 'community-driven', or 'resembles project X', and that's the mistake.

          The open source code might *potentially* be resurrected by other developers, but it might not. Leaving customers/ users just as stranded as if it was a closed source project

          Looking at this statement in those terms, things become more clear. The free software project can be resurrected by somebody else, the non-free project cannot be resurrected. So it's definitely better to have free software here, because then you've got a chance, instead of having no chance.

          Any individual project may be easier or harder to resurrect, and it may be more or less likely to need it. But these things are not determined by whether or not the project is free software. You'll have to look at other aspects of the project to discover them. Better yet, look at the reasons why the project is the way it is, that tells you even more.

          • Re:Not "all good" for the customers (Score:1, Insightful)

            by Anonymous Coward
            Open source means you can read the source, much like an "open book exam" means you can read the book. The correct term for software that belongs to the community is Free Software. With Free Software, you are guarenteed to have the four fundamental software freedoms. With "Open Source", there is no such guarentee.

            By my definition, even Windows is Open Source. In principle, I can view the source code to Windows. It's difficult and I have to sign a whole bunch of documents but I could do it with sufficient pa
            • "Open Source" traditionally means more than just that you can read the code. It also implies that you have certain rights, such as the right to modify and recompile the code. Also, with Windows, you can't see ALL the code. You can see a pretty small fraction, as I understand it. You certainly can't get your hands on enough to compile a Windows build yourself.

              • Re:Not "all good" for the customers (Score:3, Insightful)

                by Anonymous Coward
                Free Software doesn't have a coherent set of goals. Ask any three Free Software hackers why they write Free Software and you are likely to get five answers. What Free Software has is an economic model that works.

                Take Linux, for instance. What are the chances of an undergraduate student from Finland being allowed to hack on a commercial operating system? None, there is no chance that anyone would have give Linus a shot at meaningful work on a commercial operating system when he first started hacking Linux. O
                • Many of my own customers choose Linux over Microsoft simply because they hate being charged sideways (or fined) for stuff years after they bought it and forgot it (bonus for funds then sent overseas, worsening our (Oz) balance of trade), and they hate having stuff constantly breaking.

                  Free Software (and to a large extent, mere Open Source) addresses those particular hates with loves, quite directly.

                  There is more hate, and FS is addressing it by destroying it as the hostile alienation which closed software is
          • "Looking at this statement in those terms, things become more clear. The free software project can be resurrected by somebody else, the non-free project cannot be resurrected"

            Actually non-free projects are resurrected all the time. Look at WordPerfect. It's been resurrected at least twice.
          • >Looking at this statement in those terms, things become more clear. The free software project can be resurrected by somebody else, the non-free project cannot be resurrected. So it's definitely better to have free software here, because then you've got a chance, instead of having no chance.

            The same argument is offered by people selling lottery tickets, and we all know what the odds of winning the lottery is.

            Open source has its advantages, but let's not be disingenuous about it.

        • Re:Not "all good" for the customers (Score:4, Insightful)

          by turbidostato ( 878842 ) on Sunday June 18, 2006 @08:49AM (#15557922)
          "Let's get beyond the simple binary 'all closed source is bad for customers/users, all open source is good'"

          And your end point is that once we go beyond those simple binary assements, if the core developers of a project "resign" due to varied number of reasons, the open source clients are in a worst case scenario no worse that their close source counterparts, and given some not so improbable conditions, they might be better to much better.

          Now, I think this clarifies the waters quite a lot.
      • At the time I made my post, the story did not have a link associated at all. Must've been corrected subsequently. (Glad I checked and saw it was updated, before I made my reply to your comment...)

  • So, really... (Score:3, Insightful)

    by NoMaster ( 142776 ) on Sunday June 18, 2006 @03:02AM (#15557487) Homepage Journal
    So the real gist of the article is "Open Source is interesting - but watch out for the IP issues, and if the original developers leave, you're hosed."

    Hardly a glowing recommendation, is it? It shares more in common with the SCO [slashdot.org] FUD [slashdot.org] further down the front page than you may realise...

    • Re:So, really... (Score:4, Insightful)

      by Baricom ( 763970 ) on Sunday June 18, 2006 @03:09AM (#15557500)
      I don't read this as saying that the ownership of IP is something to worry about. I think the writer's point is that the most important IP is not what SCO and the MAFIAA are suing people about...it's the creators of that IP. This is especially the case with code, since it needs to be maintained for longer periods of time than other kinds of IP. When you have software that is the lifeblood of your company, and the team that wrote it retires or gets hit by a bus, you have big problems.
      • Its FUD since the same applies - and more so - for any close source project.

        The good part of a successfull open source project is that a lot more people has seen the source code and thus knows something about the project. The number of people who knows the code for a closed source project is much less and thus a lot more knowledge are in the heads of fewer people for closed source program code - should they disappear then the problem will be much worse for a closed source project than for any open source p
        • I don't think you have read the article, really. You should: it's not great, but it is very short.

          The article raises the point that the difference, and 'the real IP', is the motivation and commitment behind the core developer group, not just familiarity with the source. Keeping the code free does not eliminate all the risk, because being open-source does not magically make every collaborator able to carry on the torch.

          Summary quote: "The code without the people is worth nothing". I tend to agree.

          Yes, the sa
    • They say the code is nothing without the people that wrote it. core people take a lot of time to replace. I somehow can't imagine this is different with proprietry source code....
      I'd even say that it might be easier with open source due the fact it is more likely to be written with that aspect in mind, having others read and work on it....
      Not that it is a guarantee though :)

  • Replaceable (Score:3, Interesting)

    by Umbral Blot ( 737704 ) on Sunday June 18, 2006 @03:17AM (#15557515) Homepage
    After finding the article and reading it this is what it really seems to say: open source is great, since so many more people understand your code you are that much cheaper to fire after you have done the creative work and replace with someone cheaper. I love open source, but if companies are really thinking like this it would be a good reason to make your projects closed source, as sad as that sounds.

  • Superstars vs. Interchangable Parts (Score:5, Insightful)

    by buckhead_buddy ( 186384 ) on Sunday June 18, 2006 @03:56AM (#15557566)
    Proprietary software development companies have found that promoting (or even acknowledging) developers causes a problem where the developers can be hired away. When the most knowlegeable developers disappear, there's a huge learning curve even for the "second tier" that must come to fill the void. It's a well-known risk for proprietary companies to have these "assets" so exposed and open to theft by other HR departments. Even if they aren't hired away, superstar developers mean that they can leverage huge salaries. Proprietary software companies have found that keeping their development staffs unacknowledged and easily replaceable means they keep costs down. They've developed a way to keep the developer a cheap, replaceable asset.

    It seems that this article is trying to focus on how this applies to open source software development companies. It's not open source development in general, but companies which profit from open-source as an integral part of their business (admin services, proprietary add-ons, special distributions, etc). Even if the source for a critical part is open, the company will only have a handful of developers who understand the code inside and out on staff. This is a potential liability.

    Accountants and capitalists don't want to consider developers as "artists" or "superstars", they'd much rather consider them as sheep to be sheperded. Simple, replaceable, interchangable. The article tries to make the point "Don't assume open source means your paid development staff will become a constantly refillable, always-replaceable, cheap resource." It doesn't change the problems of hiring developers that you had when you considered proprietary software funding.

    • Re:Superstars vs. Interchangable Parts (Score:5, Interesting)

      by Tim C ( 15259 ) on Sunday June 18, 2006 @05:11AM (#15557651)
      Perhaps I'm cynical, but it's my experience that companies don't want to think of any of their employees as anythng but resources. That makes dealing with them so much easier - if you think of them as people, you might actually feel a little empathy or even guilt when you make them redundant just to make a small cost saving, or refuse bonuses and pay rises while the senior management award themselves both.

      I don't think it's any kind of coincidence that "Personnel" departments all got renamed to "Human Resources".

      • Re:Superstars vs. Interchangable Parts (Score:2, Interesting)

        by Anonymous Coward
        I think both you and grandparent are mostly right. But I think he is mistaken when he says
        "They've developed a way to keep the developer a cheap, replaceable asset."
        A company may be able to keep the wages down by simply refusing to acknowledge good developers, and get away with this for a while. But when the frustrated developers eventually leave anyway, management will notice that the "replaceable" is not always so easy.

        Posting anonymously today because the topic might become hot at my current place of wor

        • Market forces... (Score:2, Insightful)

          by John Guilt ( 464909 )
          ...impressive as they are, can work slowly and/or sporadically. If most companies that hire most developers are stupid in exactly the same way, there's a good chance they won't feel the ill effects for awhile---they can lumber through as hundreds or thousands of bright, innovative, start-ups do the smart thing, live for awhile, and die, like so many virtual particles. Eventually, perhaps, one of them will either succeed or the information that acting in a particular way will propagate up the food chain by
      • Perhaps I'm cynical, but it's my experience that companies don't want to think of any of their employees as anythng but resources. That makes dealing with them so much easier - if you think of them as people, you might actually feel a little empathy or even guilt when you make them redundant just to make a small cost saving, or refuse bonuses and pay rises while the senior management award themselves both.

        If I didn't trust my management to make the difficult decisions without getting "empathetic", then I'd
    • "Even if they aren't hired away, superstar developers mean that they can leverage huge salaries."

      What superstar developers? Being a superstar in any field is more about image than substance. If there are any true superstars in software their most likely characteristic is that they no longer write software. They end up with jobs like Apple fellow.

  • The relevance of this article.... (Score:5, Interesting)

    by pieterh ( 196118 ) on Sunday June 18, 2006 @04:19AM (#15557597) Homepage
    Of course the people are key to any business, not just software, and not just open source. A large part of building a sustainable business is to solve this problem and build structures that survive change. Sustainable software is built in layers so that no single team determines the life of the whole. Individual projects will die if their key developers leave but the whole can keep running.

    The article seems mainly aimed at VCs involved in the new boom in Silicon Valley - open source - and is warning them, "buy the developers, not the software".

    Good advice but hardly profound.

    • Re:The relevance of this article.... (Score:4, Insightful)

      by asuffield ( 111848 ) <asuffield@suffields.me.uk> on Sunday June 18, 2006 @06:05AM (#15557725)
      A large part of building a sustainable business is to solve this problem and build structures that survive change. Sustainable software is built in layers so that no single team determines the life of the whole.

      Of course, a lot of people get this wrong. They manage to build a structure that survives change, but does so because it isn't dependant on the skills of the individuals at all. That sounds good, but it really means that the system cannot benefit from the skills of the current employees - in effect, everybody is reduced to a minimum baseline level, in order to ensure that they can be replaced. This is one of the symptoms of the classic 'big software house' disease. It's not enough to get good people, keep them, and survive after they leave - you've got to do all that without impeding their work.

      Very few people manage to build a structure that survives major change and can still benefit from the expertise of the workers. It's really hard.

    • Re:The relevance of this article.... (Score:4, Insightful)

      by killjoe ( 766577 ) on Sunday June 18, 2006 @06:34AM (#15557763)
      The larger the corporation you work for the less people matter. I have worked for some large corporation and I have no idea how they kept going. Their products were crap, nobody gave a damn, the workers were treated like shit, the customers worse. Despite all that they kept winning large contracdts and their profits were going up. Their products and services are measurably inferior to the competitions and they cost more but the customers kept choosing them because they were a big company.

      A large company build it's own momentum. People buy the products and services because they think a large company will be more reliable or something. It's crazy.

      Anyway a programmer no matter how brilliant just does not matter to a large corporation. If anything they are a liability because they will be disruptive to the crappy programmers and will not enjoy using the chosen bondage language (java, c# or VB.NET).

      Smart people matter to small companies.
  • I think that AC was so emo that his grass cuts itself because it feels sorry for him.

    projects can die when good coders leave, projects can have a lot of trouble dealing with bugs etc. but you know what? that's life -- wouldn't you get really bored if everything was as easy as say, snapping your fingers and poof it happened that way?

    There are way more projects that are doing awesome even with all the chaos of people leaving and swapping around than those failing. it's all because you can 'use the source,

  • Maintainable code (Score:3, Insightful)

    by PietjeJantje ( 917584 ) on Sunday June 18, 2006 @05:26AM (#15557668)
    If you have two or three "superstars" who, when they leave, would leave behind a project with a huge learning curve for new developers, they were no superstars to begin with. Of course, any project, especially as it gets more complex, will imply that it gets harder to get into. But I've been in many open projects for many years, some I've seen whither, some grow and survive after the original creators left or even the generation(s) after them. It all depends on how these developers are creating stuff and from what perspective they work. Many, most if you will, are the so called 80% developers, they love adding new stuff and features, but when it comes to making the code clean for others to understand, finish the glitches, work it better into the system, make documentation, they fail. These systems stabalize and/or die after one or two generations, they become unmaintainable. To survive, a better programmer is required. One that programs with this in mind: if I'm hit by a bus tomorrow, will this code be understood and survive? There will still be a learning curve, but much less steep and much more enjoyable and attractive. Moreover, it produces better code and more thought-out software. The downside: les "quick" success, which is not to be underestimated. Although it was closed software, this story in a nutshell would be the old Netscape Browser. My grandma would be ashamed of the source code, the same speed that produced that code allowed it to grow beyond dreams, and it was their downfall, among others.
    • Many, most if you will, are the so called 80% developers, they love adding new stuff and features, but when it comes to making the code clean for others to understand, finish the glitches, work it better into the system, make documentation, they fail.
      True for some developers. In other cases, you have "80% management" that refuses to invest in cleanup work once the features appear to work.
      Back to the topic of the article (sort of), this will happen in a typical corporate environment rather than in a communit
    • if I'm hit by a bus tomorrow, will this code be understood and survive?

      "Everyone is obsessed with this bus thing. I'm rich. I go by car." - Linus Torvalds [geekz.co.uk]

    • To survive, a better programmer is required. One that programs with this in mind: if I'm hit by a bus tomorrow, will this code be understood and survive?

      Actually i advise any good programmer to keep the following in his/her mind instead:
      - "Do i want to get stuck fixing all software i made for the rest of my career in this company because nobody else can understand it?"

      No need for grand feelings of protecting the company in the event you're gone (temporary or for good) - good old selfishness and a little wis

  • So, what's new? (Score:5, Interesting)

    by Cicero382 ( 913621 ) <clancyj@tiscalBLUEi.co.uk minus berry> on Sunday June 18, 2006 @06:00AM (#15557718)
    "The code without the people is worth nothing," according to Phillipe Cases, partner at VC firm Partech International. "A million lines of code is like a million problems that you have to solve. So the risk on any open source investment project is that the 2-3 guys that created it and maintain it could leave. The commitment of the developers is often the IP -- not the code itself."

    I don't think this is unique to open source... or software development in general. Of course, once VC is involved we're not talking about FOSS in the *strictest* sense - these guys want to make money. Ok, it may be that the revenue stems from support, but that's the same for nearly *all* software projects. (No, I don't mean just fixing bugs - that's a flawed business model to start with... Oh, wait)

    Just to give an example - and to prove the quote above from TFA is wrong (sometimes, anyway):

    Back in the early 80's I was asked to look at a program which required some adjustments. It was written in FORTRAN and it was a *mess*! "Spaghetti code" didn't even begin to describe it - it had GOTOs to GOTOs, looped out code, redundant variables by the dozen - you name it, it had it. It didn't have anything in the way of provenance. It took me two days to trace out how to implement a trivial change. The weirdest thing was there was no way I could really document what I'd done because that would need a framework - and there wasn't one. And, you know what? The company didn't care. They had paid a junior programmer for two days to implement something they needed RIGHT NOW. They didn't need to keep on the original developers (and God knows how many preceded me), nor did they need to insist on adequate documentation. If they needed to make a change in the future, they would just do the same (albeit with a younger and cheaper programmer). They wouldn't employ me to look at it - I'm too expensive.

    My point is that it isn't the software that gets too expensive - it's the developers themselves. Who among us hasn't used a project to enhance their Kudos and desirability in the market?

    So VC's are looking at FOSS in the wrong way. We don't really do it for money (though that's nice), we do it for the satisfaction of getting it right and being able to point to something and say "I did/helped_with that".

    Anyone disagree?

    (Ducks)

    • Re:So, what's new? (Score:1, Funny)

      by Anonymous Coward

      Anyone disagree?

      (Ducks)


      I disagree, but alas, I am not a duck.
    • I don't disagree at all. I'm as old as TFA author, and I remember those days. There were no options, no choice. In fact, computers weren't even a commodity item way back then. One couldn't own a 'serious' computer -- no, Apple }{ was not one of those (and besides, it was $2,000).

      I can't imagine the world of commodity hardware without FOSS. Billy would have us all by the short and curlies -- face it, if FOSS didn't exist, someone would have to invent it.

      I've done quite a bit of closed & open project w

      • I can't imagine the world of commodity hardware without FOSS. Billy would have us all by the short and curlies
        Unless I'm missing something, wasn't it the primarily the rise of the IBM compatible PC and MS DOS that lead to affordable computers?
    • Don't duck, stand up proud. I think you nailed it.

      My "spending power" is an ugly necessity of modern life- its not the reason I get out of bed in the morning.
    • I don't see any correlation between your point about poorly-written commercial code and "we do it for the satisfaction of getting it right and being able to point to something and say 'I did/helped_with that'"

      Usually I write code for the sake of writing "good code". Other times I hack something together in a weekend because I want a program to accomplish a task, even if the code sucks. In both cases, I'm writing code for the "I did/helped_with that" feeling.

      But, futhermore, think of this hypothetical si

  • Commitment is not a matter of OS vs. CS (Score:5, Interesting)

    by Opportunist ( 166417 ) on Sunday June 18, 2006 @08:24AM (#15557882)
    I've had my share of both.

    I've been working for a large German corporation where I was supposed to develop software. Mostly I developed reports, but that's a different matter.

    Schedules were tight, burnout was running rampart and in the 9 months I worked there, the AVERAGE stay time for a team member was about 3-4 months. With one month being the time necessary to give the person an idea of what the heck's going on in the (very badly written) code.

    That's closed source, ladies and gentlemen.

    It can be the same with open source. With a few very interesting differences.

    With OS, it's no problem to give your applicants the code instead of having to wait 'til you decided for one of them. There is no NDA to sign. You can already base your interview on the question "did they understand the code?". You start with a team member that already knows the basics of your code and knows what is going to come. He already knows if he WANTS the job, since he knows what kind of beast he's going to be pitted against.

    The average stay time will be first of all longer, and more importantly, your new team member has a head start. He already knows the basics of the code, he is getting productive in less time.

    That's open source, ladies and gentlemen.

  • At that point the company must find new developers / engineers that understand the technology, and it can take months and months for them to decipher from a code perspective how the product works

    Well, in this point, I must say he's right. FOSS projects tend to have poor design documentation, and sometimes it's really hard for new devers to commit code in a relatively short period of time if at all.

    yes I know, if programmers usually don't like to document code, how can you imagine they will document

  • Here's another group working with Open Source;

    From N3P [n3p.se]:

    N3P offers a two-year college level training in how to become a successful Project Entrepreneur in Open Source. Our students will learn not only the technical possibilities, but also how to exploit new business opportunities, manage profitable ideas, and create flourishing businesses.

    The typical student is between 20 and 30 years old, driven by one of three motivations; 1) the desire for prosperity, 2) independency or 3) to radically innovate. N3P

  • ...is pretty much the only relevant case. I think hobbyist projects have a lower turn-over than commercial projects. Smaller projects work themselves up to core members being able to get paid - to get "recruited" to that position you've already shown a big commitment. Even when you get past that point and start hiring general IT people, I doubt you're worse off than on a closed source project. What happened here was that a big corporation went in and bought them up. The employees didn't like it, it can be q
  • don't write code which needs several month to get accustomed! That's the same mistake as is usually done in science. This isn't limited to science or computers, it's all over the world.

    Yet computer code is more sensitive to this kind of miss interpretation since neider coders nor their bosses know all the necessary "things" making their code more understandable for others. That's one important reason I still stick to the sample code within the wyoGuide guidelines (http://wyoguide.sf.net/ [sf.net]) even if it gets ra

Slashdot Top Deals

Receiving a million dollars tax free will make you feel better than being flat broke and having a stomach ache. -- Dolph Sharp, "I'm O.K., You're Not So Hot"

Close