Weekly Edition
Return to the Front page
| |||||||||||||
The Linux roadmap
Certain proprietary vendors have long liked to criticize Linux for its lack
of a "roadmap," a multi-year plan with release dates and included
features. Without such a roadmap, they say, customers have no idea where
the technology is going, cannot plan for the future, and have no assurance
that needed features and capabilities will be built into Linux. This
Information Week article is the latest contribution to this debate; the
way the Linux kernel is developed, says the author, "...makes it
even harder for technology professionals using Linux to plan around one
major release that's, say, 18 months down the road." The lack of a
roadmap is said to be a sign that the kernel development process has not
yet "grown up."
We contend, instead, that the lack of a PowerPoint-friendly release and feature plan is a sign that the free software development process is different - and better. It would be interesting to ask the aforementioned "technology professionals" how useful corporate roadmaps truly are - especially in the software arena. Betting the company on another vendor's promised future software releases seems risky at best. Relying on a vendor's claims for software which is available now is dangerous enough; competent "technology professionals" know that reality often fails to live up to those claims. The only way to know whether a given software release will work in a given situation is to try it, and trying it is difficult for releases which exist only on a timeline in some roadmap. Then again, Linux can be said to have a roadmap which can make reasonably reliable predictions fairly far into the future. One need only look at the projects which are being worked on now. With a bit of research, anybody can see what features are contemplated, which of them work now, the amount of development effort which is going into those features, whose priorities are driving development, and more. So, for example, one might make some reasonable predictions about future distributions by looking at what the developers are doing today:
And so on. Predictions of this sort are somewhat unreliable, but they are nonetheless far more trustworthy than a corporate marketing department's rendition of an otherwise obscure development process. Roadmaps can also force a company to ship what it promised, rather than what is best. Imagine if IBM were in charge of the Linux kernel, and that IBM had promised that 2.6 would include its own EVMS volume management software. Can you imagine IBM subsequently announcing that EVMS would be passed over for inclusion because the developers like the device mapper code better? If you make promises about future releases, you have to at least try to live up to those promises. It is hard to switch to an idea which turns out to be better in practice without losing credibility. Without this ability to make decisions based on what actually works and is maintainable, the free software development process would be weaker. The final problem is that the free software development model is resistant to central planning in general. Linus Torvalds can express his vision and desire for future kernel developments, but he is unable (and unwilling) to force anybody to work on those developments. The community makes its own decisions about what it thinks is important. The results are often surprising, but the success of Linux so far makes it clear that they are meeting somebody's needs. Trying to impose a roadmap on this process is unlikely to improve it. (Log in to post comments)
Wrong paradigm Posted Dec 9, 2004 5:26 UTC (Thu) by freethinker (guest, #4397) [Link] ...and have no assurance that needed features and capabilities will be built into Linux."Oh, dear me, we're so helpless. We want these features and capabilities and we're totally at the mercy of the kernel development team to put them in there. We couldn't possibly code them ourselves or hire someone to do it." Sounds like some people still don't understand how to work with free software...
Wrong paradigm Posted Dec 9, 2004 8:48 UTC (Thu) by freddyh (subscriber, #21133) [Link] Freethinker for president :)
It still seems rather difficult for people to think of Open Source as: "if it's not there, build it yourself and feed it back to the community".
FreddyH
Wrong paradigm Posted Dec 9, 2004 10:28 UTC (Thu) by zooko (subscriber, #2589) [Link] > True, however they fail to see that if their competitor uses it, they can use their competitor's stuff as well...
This is not true. If two competitors are both using some free software, and one contributes an improvement or fix then the other benefits. The first gains nothing from their competitor -- they are only helping their competitor at their own expense.
Wrong paradigm Posted Dec 9, 2004 11:19 UTC (Thu) by freddyh (subscriber, #21133) [Link] On the other hand: the competitor has probably fixed or changed some stuff as well. Or you could learn from how they put their system together. I don't agree that the first does not gain anything from helping his competitor.
Yours,
Wrong paradigm Posted Dec 9, 2004 11:40 UTC (Thu) by zooko (subscriber, #2589) [Link] I agree that the first company may benefit from the second company somehow. However, that benefit is not a consequence of the first company contributing to the open source software. The first company would have gotten that benefit just as well while withholding their contribution.
Wrong paradigm Posted Dec 9, 2004 12:24 UTC (Thu) by nedrichards (guest, #23295) [Link] But they'd have also gained a substaintial and ongoing cost of maintaining an out oif tree patch. This is generally unacceptable, especially for companies where software development isn't a core competancy. Much better to let others do the maintenance of your needed feature for you.
Wrong paradigm Posted Dec 9, 2004 16:29 UTC (Thu) by AJWM (guest, #15888) [Link] The first gains nothing from their competitor (emphasis added)True enough, but consider the real situation. Both company A and company B could use some feature X in Linux that is not presently there. They have several options: 1) Moan about it and wait until, eventually, some independent kernel developer creates feature X (although it's more likely to be X', not exactly X). Until this happens, both A and B are deprived of the feature. After, they both have access to the feature. 2) Company A (or B, or both) can add their own implementation of X for internal use only, and never release the source back to the community. This has its own set of problems I won't bother going into, most of you are aware of them. 3) Company A adds (or pays someone to add) feature X back to the public Linux. B will eventually pick up on it and use it, but A has had advance notice of and experience with the feature, and is months ahead of B in making use of it and gaining benefit from it. Neither does A face the ongoing support issues mentioned in (2) above. True, A is then "helping their competitor at their own expense", but they are not "only helping their competitor" (emphasis added), they are also helping themselves, and moreso than they're helping their competitor. The exact tradeoffs will depend on the nature of the companies, their markets, and the particular feature X. But to characterize some company contributing improvements to Linux as "only helping their competitor" is not correct.
Expanded focus Posted Dec 9, 2004 18:10 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link] Nobody's competing on kernel content (other than coders and teams trying to improve on things :-). Not even Mandrakesoft, Red Hat, SuSE, .... Those organizations are competing on packaging, support, community buy-in(?), whatnot. Both company A and company B could use some feature X in Linux that is not presently there.In the world of my first sentence, AJWM's analysis is even stronger. Company A has no direct use for feature X, rather, X strengthens their own (yes, possibly proprietary) offering. So B must pick up not only on X, but also whatever A has that amplifies X's usefulness to them. At that point, the situation is exactly as suggested in the parent post, but still better for A.
Expanded focus Posted Dec 23, 2004 8:46 UTC (Thu) by Wol (guest, #4433) [Link] Plus the fact that B probably actually wants X''. So in order for B really to benefit from A's work, B now needs to maintain an "out of tree patch".
Then add in A's kudos from doing work - if A now says "we need Y as well", independent developers are more likely to jump in and help.
So A has acquired a head start, code optimised specifically for *their* needs, and karma to help with future modifications. B is left trailing behind...
Cheers,
Wrong paradigm Posted Dec 20, 2004 8:24 UTC (Mon) by craigmcc (guest, #26784) [Link] >> ..and have no assurance that needed features and capabilities>> will be built into Linux.
> "Oh, dear me, we're so helpless. We want these features and
> Sounds like some people still don't understand how to work
Alas, this attitude is exactly why FOSS is not being accepted at the rate it really should be. In order to gain mass popularity, Linux software developers need to understand that:
* There are people in the world who are not
* There are people in the world who are not
The reality of the world is that many people are more interested in the results of the software development process than in the process itself. Microsoft (and many other commercial software companies) understand these principles -- that's why you can actually make money at software. But it comes down to goals.
If the attitude proposed by this response continues to be the standard attitude of FOSS developers, then we'd better assume that our potential market share is limited to the number of users both capable and willing to either do it yourself, or hire it done. On the other hand, if we truly want to offer a compelling alternative, we need to (gasp!) listen to the needs of our (potential) users, and meet them on their turf, instead of ours.
The real world doesn't care about whether they "know how to work with open source software." The real world only care about solving their problems. Are we willing to help, or are we going to continue to sneer at them?
NOTE - either answer to this question is perfectly legitimate -- just don't be surprised when the consequences of these two choices are different.
Craig McClanahan
The Linux roadmap Posted Dec 9, 2004 7:10 UTC (Thu) by bryce (subscriber, #16388) [Link] Roadmaps are not incompatible with Open Source. I've been maintaining aroadmap for Inkscape since we started, and we've found it moderately helpful for coordinating activities. (I talked more about this at http://dot.kde.org/1099664490/). A key point is that roadmaps should _reflect_ what developers do, not _dictate_ what they do. In open source you can't dictate what people do. That said, I'm skeptical if a roadmap could be done for the Linux kernel since there's *so* many people involved, and even if it could, whether it would be worth it. Possibly, rather than a 'Linux kernel roadmap' it would be more accurate to ask for a 'Linux kernel forecast'. ;-) Bryce
The Linux roadmap Posted Dec 9, 2004 9:13 UTC (Thu) by tomsi (subscriber, #2306) [Link] I think that when you are making a product like yours, you will have an intended goal, and an idea of how to get there. It is then relatively easy to write a roadmap; except the time estimates, that is ;)
Also, The linux kernel is now so mature that it is more than good enough for most of us.
The Linux roadmap Posted Dec 9, 2004 17:34 UTC (Thu) by bryce (subscriber, #16388) [Link] It's definitely true that with Inkscape the scope is a bit narrower,so coming up with a roadmap is a lot less intimidating a task than it would be for the kernel. However, we also have a lot of similar forces at work as the kernel does. The contributors tend to work on a range of things, things get worked out of order, stuff has to get postponed because no one is interested in working on them, etc. Thus, I wouldn't say that making the roadmap is an 'easy' task, but it can be done. The key I've found is that the development team really has to have good buy-in into it as a useful process, because much like documentation or bug tracking or formal testing it needs to have at least a modest amount of participation from the developers in order for it to function well.
The Linux roadmap Posted Dec 9, 2004 14:03 UTC (Thu) by dan_b (subscriber, #22105) [Link] I'm skeptical if a roadmap could be done for the Linux kernel since there's *so* many people involved,I'm unconvinced that it'd be any use to the kind of person who wants a roadmap anyway: they're interested in the "high level" view, not just in one single component. A "Linux roadmap" for these guys would have to include stuff about the desktop, the applications, distribution, packaging and support issues, etc. The particular issues about the small part of that system that runs in supervisor mode aren't very compelling at this level.
The Linux roadmap Posted Dec 15, 2004 16:03 UTC (Wed) by pauly (subscriber, #8132) [Link] Simply read LWN for this -- IMHO, Jon is actually pretty good :-))
The Linux roadmap Posted Dec 9, 2004 8:00 UTC (Thu) by pascal.martin (guest, #2995) [Link] I would think this represents a market opportunity for LWN: sell a newletter for IS professionals that analyzes the current trends among kernel developpers and estimate completion times, future kernel features, etc..
Basically this would be an expanded variant of the kernel development page, for an additional subscription fee.
After all IBM pundits have made tons of money for years "predicting" future IBM products, and current Microsoft pundits make as much money predicting how late will Microsoft products be released (sometime the same pundits..:).
The Linux roadmap by LWN Posted Dec 9, 2004 8:59 UTC (Thu) by simon_kitching (guest, #4874) [Link] This was my first thought too. Analysing current and future Linux features is what LWN already does (and does very well). Just repackage the contents in Microsoft Word format for CEOs and put a whopping big price tag on it :-)
The Linux roadmap Posted Dec 10, 2004 7:46 UTC (Fri) by aleXXX (subscriber, #2742) [Link] I had the same idea.Maybe not only the kernel, but Linux in general. Alex
The Linux roadmap Posted Dec 10, 2004 18:41 UTC (Fri) by sebastian (subscriber, #4910) [Link] Yeap, I agree, too. This sounds like a potential marketing opportunity.
The roadmay concept does include the desire to control or regulate the outcome...so from that standpoint it is probably a bad idea to use the roadmap terminology. I think one of the UK linux mags does a kernel trends column - which is very much like the lwn kernel pages. Expand that with some techno mumbo jumbo about the advantages of specific technologies, and their likelihood of inclusion into the mainline kernel, and you have a $1M service.
The Linux roadmap Posted Dec 9, 2004 8:33 UTC (Thu) by eyal (subscriber, #949) [Link] With open source software, one can draw one's own roadmap and then pave that road, without having to depend on the whims of proprietary vendors.
Eyal.
Article really wants OS roadmap not kernel Posted Dec 9, 2004 12:40 UTC (Thu) by kfox (guest, #4767) [Link] The journalist is confused. Tech professionals don'tcare much about the kernel itself. They mostly worry about business planning decisions: should we BUY product X to fill a gap in the OS? For those few tech professionals that work for software companies, I suspect they only use the roadmap to guide product development. Nobody wants to see his product go down the tubes because the feature was bundled with the OS.
Roadmaps are more like territory markers than plans.
Microsoft pisses on a tree. Symantec picks up the
Article really wants OS roadmap not kernel Posted Dec 9, 2004 14:40 UTC (Thu) by maney (subscriber, #12630) [Link] Roadmaps are more like territory markers than plans.+1. Superb insight into the corporate thought processes here.
Article really wants OS roadmap not kernel Posted Dec 9, 2004 17:56 UTC (Thu) by knobunc (subscriber, #4678) [Link] Let me get my dog... she is good at marking territory.
-ben
Don't rely on vendor projections anyway Posted Dec 9, 2004 15:03 UTC (Thu) by cruff (subscriber, #7201) [Link] I never rely on a vendor roadmap anyway, as they are too volatile and are sometimes do not even turn out to be true. The only features we can really rely upon are those that are shipping now, which is no different than Linux. As for software to do something we need that a vendor does not provide, the only ones we can really rely upon to deliver it are ourselves.
Don't rely on vendor projections anyway Posted Dec 9, 2004 20:03 UTC (Thu) by sepreece (subscriber, #19270) [Link] Our experience has been that while we CAN do everything ourselves, it's usually better in the long run to have things outside our core competency done by people who specialize in them. We have built filesystems, for instance, but we haven't built a lot of them and evolved them long enough to be really good at it. And, it dilutes our ability to specialize in our own domain.
We have to plan products roughly two years out - it takes a good part of that to design and build the hardware and line up component supplies. We're used to relying on vendors to deliver on schedule, because we have to be. Generally speaking, they do.
We used to do our own chips, but decided we got better chips if we worked with experts, who could leverage their experience in working with lots of customers with similar needs. We used to do our own OS, but decided we were spending a lot of effort on it and not getting the value we could get from OSs that were some company's lifeblood, rather than just an enabling component they use.
I'm NOT saying Linux should have a roadmap or development plan; I understand that the way OSS works makes that impossible. We rely, instead, on a distributor and third-party developers who work out roadmaps and delivery schedules with us and, for the most part, deliver pretty close to those schedules.
The good thing about OSS is that it allows for different models - people who just need desktop Linux on x86 can happily take kernel.org kernels or one of the incredible number of distributions. Those of us with specialized needs can find what we need through distributors and developers. If the maintainers continue to not be interested in the needs of consumer-product builders, we can live with that, because we can get what we need as aftermarket enhancements, specifically because it is open-source software.
Having said that, however, it does seem like Linus and friends COULD make more of an effort to influence the direction that work is going. They may not be able to MAKE anyone work on it, but their influence is substantial. People do read Linus's pronouncements to try to figure out what is more or less likely to be accepted, and if Linux said "It would make me really happy if 18 months from now the kernel could do X", it's quite likely that people would break their backs making sure he was happy in 9 months...
Don't rely on vendor projections anyway Posted Dec 10, 2004 1:56 UTC (Fri) by dkite (guest, #4577) [Link] Kde developers release a plan that is somewhat dynamic in nature, but gives an idea of what is coming. kde-3.4-features.html Each developer decides what he (or she) expects to get done, and updates the plan accordingly. The release coordinator uses this plan during the feature freeze to keep a lid on new stuff. Releases come roughly every 6-12 months. Derek
The Linux roadmap Posted Dec 9, 2004 20:57 UTC (Thu) by error27 (subscriber, #8346) [Link] Three years is far too long to plan ahead in software development. It goes against the open source philosophy of release early and often.
Look at the GIMP. They tried to have a huge release instead of incremental releases but it backfired. Everyone was stuck with old software. FilmGIMP forked. They had to drastically scale back their plans and start releasing incrementally improved software again.
RedHat is moving away from massive releases with their Fedora stuff.
The kernel is moving away from massive releases with the new development procedures.
My feeling is that stuff doesn't get tested or bug fixed as well if it's not released with incremental improvements. It's obvious that no one wants to run the unstable kernel. Also I think there is a feeling sometimes during the devel stage that bug fixes can wait until closer to the end.
Someone should do a study on this...
The Linux roadmap Posted Dec 10, 2004 9:05 UTC (Fri) by gc (guest, #24112) [Link] Hum.. FUD stuff is not the best way to make a point..We contend, instead, that the lack of a PowerPoint-friendly release and feature plan is a sign that the free software Is it really needed to talk about PowerPoint to make your point?
Whole premise all wrong, roadmaps are useless Posted Dec 10, 2004 22:58 UTC (Fri) by bender3000 (guest, #22577) [Link] >Certain proprietary vendors have long liked to criticize Linux for its>lack of a "roadmap," a multi-year plan with release dates and included >features. What are your needs for today and for tommorrow? Linux delivers for today and anticipates eagearly for tomorrow. Woulndn't it be great if Linux were magic eight ball ?
Where's the problem? Posted Dec 16, 2004 10:37 UTC (Thu) by forthy (guest, #1525) [Link] Most people working on free software have some TODO list. Either as file,as comment on a web page, or as something inside the head of the developers. To make a roadmap, you just have to collect the various TODO lists, extract the points that seem to be of higher importance, and put them into some slides. I'd prefer LaTeX-beamer slides to PowerPoint. This "putting into slides" is a marketing task, and therefore should be done by the distributions. Roadmaps are subjects of sudden changes, not binding contracts. It's finished when the work is done.
The Non-Linux roadmap Posted Dec 16, 2004 16:55 UTC (Thu) by dmag (subscriber, #17775) [Link] I think the biggest problem with roadmaps is that they are meaningless. What happens if the vendor doesn't deliver? Does anyone even check? Hmm, just off the top of my head, picking one company at random...
|
|||||||||||||