Open Source About the People 91
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.'"
The Missing Link (Score:5, Informative)
Re:The Missing Link (Score:5, Funny)
I appreciate that the editors don't (edit, that is), but really...
Spank The ScuttleMonkey (Score:1)
Great article! (Score:5, Funny)
Re:Great article! (Score:1)
Re:Great article! (Score:5, Insightful)
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)
Re:Great article! (Score:1)
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.
Re:Great article! (Score:1)
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."
Re:Great article! (Score:3, Insightful)
They are doomed from the start...
It is like being a little bit pregnant...
B.
Not "all good" for the customers (Score:3, Interesting)
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)
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 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
Re:Not "all good" for the customers (Score:3, Informative)
Re:Not "all good" for the customers (Score:3, Insightful)
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
Not hate driving FS adoption? (Score:2)
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
Re:Not "all good" for the customers (Score:3, Interesting)
Actually non-free projects are resurrected all the time. Look at WordPerfect. It's been resurrected at least twice.
Re:Not "all good" for the customers (Score:1)
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)
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.
Re:Great article! (Score:1)
So, really... (Score:3, Insightful)
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)
Re:So, really... (Score:2)
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
Re:So, really... (Score:2)
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
Re:So, really... (Score:1)
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
Re:Word of the Day: Switcher (Score:2)
Replaceable (Score:3, Interesting)
Re:Replaceable (Score:2)
Superstars vs. Interchangable Parts (Score:5, Insightful)
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)
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)
"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)
Re:Superstars vs. Interchangable Parts (Score:2)
If I didn't trust my management to make the difficult decisions without getting "empathetic", then I'd
Re:Superstars vs. Interchangable Parts (Score:2)
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)
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)
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)
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.
Re:The relevance of this article.... (Score:2)
Re:The relevance of this article.... (Score:2)
Talk about an emo AC (Score:2)
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,
Re:Talk about an emo AC (Score:1)
Oh wait, I can..
Re:Talk about an emo AC (Score:2)
Re:Talk about an emo AC (Score:2)
A. None. They just sit there in the dark feeling sorry for themselves.
Maintainable code (Score:3, Insightful)
Re:Maintainable code (Score:2)
Re:Maintainable code (Score:3, Insightful)
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
Re:Maintainable code (Score:2)
"Everyone is obsessed with this bus thing. I'm rich. I go by car." - Linus Torvalds [geekz.co.uk]
Re:Startup business model (Score:2)
The benefits of doing things the "right way" are usually deferred. In a startup you usually can't afford to do anything with deferred benefits. Once your company is profitable, you can take advantage of the cost savings that sometimes goes
Re:Maintainable code (Score:2)
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)
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)
I disagree, but alas, I am not a duck.
The world sucked before FOSS (Score:3, Insightful)
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
Re:The world sucked before FOSS (Score:1)
Re:So, what's new? (Score:2)
My "spending power" is an ugly necessity of modern life- its not the reason I get out of bed in the morning.
Re:So, what's new? (Score:2)
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)
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.
Re:Commitment is not a matter of OS vs. CS (Score:2)
Though I've met a few people there who came from Bosch. And they LIKED it there, saying it's way better. I shiver at the thought, to be honest.
you said design documentation ? (Score:2, Informative)
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
N3P, 2 year college about Open Source (Score:2, Interesting)
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
Re:N3P, 2 year college about Open Source (Score:2)
Perhaps the people at N3P should Open a Dictionary!
I think the example in the article... (Score:2)
Real superstars ... (Score:2)
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