LWN: Comments on "The Linux roadmap"

Expanded focus

Wol — Thu, 23 Dec 2004 08:46:21 +0000

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,
Wol

Wrong paradigm

craigmcc — Mon, 20 Dec 2004 08:24:06 +0000

>> ..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...

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
technically capable of "code them ourselves" --
in the case of the Linux kernel, I'd certainly
classify myself in that camp, although I am more
than middlin' capable at software development
within my domain of expertise.

* There are people in the world who are not
willing to "hire someone to do it" and then
have to figure out how to (a) hire such people
(or acquire an appropriate contractor), (b) figure
out how much to pay them, (c) understand how to
manage them.

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 Non-Linux roadmap

dmag — Thu, 16 Dec 2004 16:55:29 +0000

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...

Cairo, WinFS, etc. - Oops, did we say it would be in this release? We meant the next release. Promise. We really mean it this time.
HailStorm - oh, drat, it didn't work so we scrapped it
.NET services - Umm, maybe we over-hypped it a little..
Passport - scaled back to the point of obscurity
Blackbird - Anybody remember MS's proprietary version of the Internet?
Foxpro - They prommised not to pull the plug, then they did.
Java support - Arrg.
RDAC? (Remote Data Access Component?) - Supposed to make it easier for web pages to get data from your DB thru IIS. Turned out to be just another security hole.

Where's the problem?

forthy — Thu, 16 Dec 2004 10:37:29 +0000

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 Linux roadmap

pauly — Wed, 15 Dec 2004 16:03:37 +0000

Simply read LWN for this -- IMHO, Jon is actually pretty good :-))

Whole premise all wrong, roadmaps are useless

bender3000 — Fri, 10 Dec 2004 22:58:55 +0000

>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 ?

The Linux roadmap

sebastian — Fri, 10 Dec 2004 18:41:42 +0000

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

gc — Fri, 10 Dec 2004 09:05:21 +0000

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?

The Linux roadmap

aleXXX — Fri, 10 Dec 2004 07:46:05 +0000

I had the same idea.
Maybe not only the kernel, but Linux in general.

Alex

Don't rely on vendor projections anyway

dkite — Fri, 10 Dec 2004 01:56:38 +0000

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

error27 — Thu, 09 Dec 2004 20:57:24 +0000

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...

Don't rely on vendor projections anyway

sepreece — Thu, 09 Dec 2004 20:03:19 +0000

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...

Expanded focus

Max.Hyre — Thu, 09 Dec 2004 18:10:10 +0000

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.
....
Company A adds ... feature X back to the public Linux. B will eventually pick up on it ... but A has had advance notice of and experience with the feature, and is months ahead of B in making use of it....

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.

Article really wants OS roadmap not kernel

knobunc — Thu, 09 Dec 2004 17:56:45 +0000

Let me get my dog... she is good at marking territory.

-ben

The Linux roadmap

bryce — Thu, 09 Dec 2004 17:34:18 +0000

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.

Wrong paradigm

AJWM — Thu, 09 Dec 2004 16:29:23 +0000

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.

Don't rely on vendor projections anyway

cruff — Thu, 09 Dec 2004 15:03:13 +0000

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.

Article really wants OS roadmap not kernel

maney — Thu, 09 Dec 2004 14:40:37 +0000

Roadmaps are more like territory markers than plans.

+1. Superb insight into the corporate thought processes here.

The Linux roadmap by LWN

jhenry — Thu, 09 Dec 2004 14:32:41 +0000

LWN - the next Gartner? Ick.

The Linux roadmap

dan_b — Thu, 09 Dec 2004 14:03:47 +0000

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.

Article really wants OS roadmap not kernel

kfox — Thu, 09 Dec 2004 12:40:36 +0000

The journalist is confused. Tech professionals don't
care 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
scent and changes course. Sun picks up the scent too,
but it pisses on the same tree trying to show its
territory is just as big as Microsoft's.

Wrong paradigm

nedrichards — Thu, 09 Dec 2004 12:24:27 +0000

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

zooko — Thu, 09 Dec 2004 11:40:04 +0000

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

freddyh — Thu, 09 Dec 2004 11:19:43 +0000

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,
FreddyH

Wrong paradigm

zooko — Thu, 09 Dec 2004 10:28:59 +0000

> 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.

The Linux roadmap

tomsi — Thu, 09 Dec 2004 09:13:03 +0000

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 by LWN

simon_kitching — Thu, 09 Dec 2004 08:59:48 +0000

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 :-)

Wrong paradigm

freddyh — Thu, 09 Dec 2004 08:48:03 +0000

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".
Far too often I hear the same answer to that: "if I do so, my competitor will be able to use it too". True, however they fail to see that if their competitor uses it, they can use their competitor's stuff as well...

FreddyH

The Linux roadmap

eyal — Thu, 09 Dec 2004 08:33:56 +0000

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.

The Linux roadmap

pascal.martin — Thu, 09 Dec 2004 08:00:29 +0000

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

bryce — Thu, 09 Dec 2004 07:10:35 +0000

Roadmaps are not incompatible with Open Source. I've been maintaining a
roadmap 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

Wrong paradigm

freethinker — Thu, 09 Dec 2004 05:26:17 +0000

...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...