Slashdot Mirror
Open Source About the People
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 anonymous submitter was apparently too cowardly to submit a link to the article. I think that's the one he wanted.
Sorry, no.
The link that post contained pointed to what may well be the most informative, insightful, and entertaining read I've had all year.
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 FUD further down the front page than you may realise...
What part of "a well regulated militia" do you not understand?
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.
Philosophy.
Change is certain; progress is not obligatory.
I can't tell if this is meant as serious or as an insult aimed at mac fanboys.
Philosophy.
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.
Of djb. The guy who releases "open source" software. Yet all of his software is dying a terribly, horrible, timely death. Mainly because it's patches on top of patches on top of patches, all written by Joe whatshis name. Even if DJB does say his software does have a security guarentee, he doesn't honor it. It could be a totally legit error, and DJB will deny, deny deny - sort of like a congressman.
Of course, his OOB software may be somewhat secure, but that's just like saying if you buy this model T ford, your power steering won't break down - because it has no power steering! If you want power steering, you need the 12 patches that add it, which of course, means there's no security guarentee anymore.
The point is, there's open source - Linux, GNUtools, Mythtv - and there's "open source", which is qmail, Apple's facade, NMAP, etc. Apple/qmail/etc, could give a flying fuck.
You should just be happy to know that other people actually use them, too.
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.
My blog
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, luke' *hums starwars theme* master jedi can find a balance to the source, and can cut out the 'tainted' lines of code, or simply use them, to build a stable application. Just remember not to turn to the dark side young jedi, for we can always watch the fate of poor anakin, who struggles his entire life with the way he allowed his own fear to twist his fate, as he wound up being the very man who fufilled the prophecy that he dreamed would happen unless he persued great power.
ah well who really cares life would get boring if we didn't have a few crazies turning to the dark side. I'm just glad we can all choose our own destiny.
https://www.gnu.org/philosophy/free-sw.html
You need to get over yourself.
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.
"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)
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*.
/resources to do anything themselves. Just look at sourceforge and see the number of dead projects.
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, particularly smaller users who do not have the money
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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 work. It really doesn't matter. Neither is automatically more prone to success or failure. What matters most is the personalities of those doing the really hard work (is there a good mix?) and whether or not they're willing to go all the way (through documentation and customer support). Closed source projects are usually motivated by cash, and nothing more. FOSS projects, on the other hand, tend to be motivated by ideals and good ideas.
The total "fit and finish" of the end product often reflects the motivations of its creators: do you, as a user, not like it? Chances are pretty good that the development team didn't, either.
Founding member: He-Man Windoze Hater Club
It's always the editor's fault.
"No fear. No envy. No meanness." Liam Clancy
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 on design when they're not even told so ?. if that changes someday it will be a pretty good play for FOSS projects expansion and lifetime, don't you think ?
From N3P:
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 will carefully screen the applicants for doers, not talkers, while persistence, passion and the ever so important ability to sell, are other important criteria.
The future will show a great demand for individuals that have the ability to implement necessary changes. They should be entrepreneurs, fluent in new technology, project management and marketing. They also should excel in sales and development of new products and businesses. N3P identifies them as "Project Entreprenerus".
Most of our students will form their own business before graduating, and it is our expectation that many will be very successful.
...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 absorption, but until then.....
is to basically just write a bunch of quick and dirty code to get enough of a market presence to sell the company before anyone has a chance to realize how bad the code is.
Extremely so. It's ok if the new owners realize when they buy the start up that they have to rewrite the entire code base. Assuming someone actually knows what the code is supposed to do. "quick" usually means not documenting anything or even doing a design. Not knowing what the code is supposed to do makes debugging rather interesting.
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 patterned upon, and replacing it with a widespread practical community attitude.
There is, AFAICT, no globally better way of dealing with hate.
The rest of your post, AC, I quite enjoyed. The item about "five answers" is particularly telling, because FS tends to address real-world needs (after all, who is it written by?) more effectively than the management-inspired fleet of esoterica which motives so much closed source software might hope to, and addresses them from a far wider range of perspectives.
Got time? Spend some of it coding or testing
...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 quite a culture shock. Since it was open source, they split it off. Had it been closed source? Then they would have moved to other positions in other companies. Making sure that key people stay on board after a takeover is a critical success factor - but it has absolutely nothing to do with open vs closed source.
Live today, because you never know what tomorrow brings
"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.'"
What company? Sometimes it's just a project. I do agree though. More often than not, when the primary coder(s) quit, the project stagnates or even dies. The coder's logic is that when they leave someone else can easily take over, and this is technically true, but, it's very rare indeed that it actually happens. Look at, for example, WinLIRC. The primary programmer stopped doing anything years ago and the project has become worthless for most of today's remotes (which use USB, which is not even supported, though it still works if you don't mind building your own COM port remote, though it may be possible that COM ports and LPT ports may both dissapear from computers in the not so far future thanks to USB and firewire doing the same job better.) I have seen a few cases where the primary coder quit and someone else took over and the project actually survived -- even one or two where it actually improved -- but, as I said, this is quite rare and usually the project just stagnates to the point of becoming useless in a modern system or even actually completely dies.
I don't know. If you think about it, the equivalent really does tend to apply to commercial software quite often. Once the company stops supporting a product -- except in a few rare cases like operating systems where the removal of the product can be costly and pointless -- the product usually ends up dying out. The worst case being things like old games that are no longer being produced and sold so it becomes impossible to ever obtain a legal copy except maybe a used copy (often for an insane price) on sites such as e-bay and specialist forums. If you go far enough back, such as PC-Engine/TG-16 games, obtaining an original even used can become all but impossible for those of us who are not filthy rich. At least with opensource, you can often find an old copy with enough searching, and it's legal for you to get it without taking out a mortgage.
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/) even if it gets rated biased towards wxWidgets. IMO it's incredible important for OpenSource as for ClosedSource to make code as readable as possible and nothing is better suited to show how than sample code.
Sure enough it would make a lot sense to have sample code for other frameworks or environments but sorry, as a spare time developer I don't have that much time.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html