> I can argue that the existence of Samba can > be seen as promoting those proprietary technologies
the samba team isn't sitting on an ECMA or ECMA-like committee. that's the source of all this bruhaha.
> is not attacking them for doing something which is emphatically a good thing,
i totally agree people shouldn't be attacking them. i disagree that it's an emphatically good thing (there are other ways of achieving what they need to, btw, that don't come with the baggage).
i also think that it's a self-evident fact that they are playing the communications game very poorly right now. this article and many others just like it are the proof. =/
> but rather just get the truth out and not let FUD like this spread.
what, exactly, is evil about a dual licensed toolkit?
(especially when money earned goes into paying for the development of more free software...)
i mean, you're free to feel however you wish about things, but making a statement about principles and evilness would do well with some actual substance behind it.
"I don't see anyone (wrongly) trashing Samba as a project, and yet its existence and the effort to implement OOXML support is virtually identical in terms of free software."
the difference is that the samba project is not taking a position that can be perceived as promoting those technologies as a formal international standard. and that is why, in a nutshell, there isn't the bruhaha over samba, but there is over this OOXML stuff.
it's unfortunate and not representative of the motivations of the people involved (as you note) but it is a completely predictable reaction given the political issues here. i personally don't believe the GNOME foundation is actually trying to attack freedom in general or ODF in specific through their OOXML position, but intentions alone are not always enough. in this case i fear some political naivety is resulting in a series of unfortunate public missteps. =/
given that KOffice uses ODF natively, providing good evidence that ODF is not simply a one-project/company proprietary format being dressed up as a standard, yes it is important. it's a very compelling argument in favour of ODF that has been used quite a bit in the push towards ODF standardization; it's not uncommon to see ODF stalls at tech events showing OpenOffice one one computer and KOffice on another displaying the same document. more examples of ODF usage are appearing every day now, of course =)
and yes, a good number of people do use KOffice. certainly not as many people as use OpenOffice, but to the users of KOffice knowing that they are working with apps that use an interoperable format is indeed pretty important to them.
"I'm sure it's great being homeless with a clean conscience."
that is a false dichotomy. many people make a fine living while standing up for what we believe in. it's not magic, it's just conviction and the willingness to live in accordance with your beliefs as much as is humanly possible. we all fail at that from time to time, of course, but when not living in accordance with your beliefs becomes the prevailing pattern in one's behaviour there is a problem: either you are betraying your own self or you don't actually believe what you say you do.
making these (at times not easy) decisions does not need to, at least in the "first" world, come at the expense of an income. granted, you might make less money (though not necessarily) but you'll certainly live more fulfilled.
of course, most people using OpenSUSE actually use KDE as has been shown by surveys of their own user base. you can see the results for yourself right here.
i'd also not turn my nose up at successes like the EEE PC which ships with KDE software by default and is well on its way to making the sales targets of 3-5 million units in its first year.
it's also great to see gnome centric companies, such as Canonical, Red Hat, or even smaller ones like Userful, have so much commercial success with KDE. Userful is interesting: they had their booth with GNOME desktops, but the big vertical banner showing their highlight installation was KDE (on SUSE =). it's also substantial new installations, such as the French parliament or the school districts in the country of Georgia or....
trying to measure market viability and realities via distrowatch is a lot like trying to predict the weather by consulting the water in your bathtub.
yes, KDE purposefully linked GPL licensed code to QPLv1 code. however, it was THEIR code which means that they were fully within their rights to do so. anyone building apps on top of those libs implicitly agreed as well.
linking someone else's code would be an issue, and in the 2 cases where that happened it was rectified as soon as it was brought up; it's also useful to note that those 2 cases were small code fragments, not significant bodies of work, and as such certainly not evidence of a willfull plot or some such thing. they were oversights, and corrected in a timely manner without fuss.
and this was what, getting to be 10 years ago now? today we have nice clean GPL'd (or "better") code on every platform we support. let's find some new issues to grind over. =)
> but not immediately before a major release when the rest of the desktop is pretty much > finished and not if you can't finish it on time.
so, we didn't do what you shouldn't do... good.
> when people point out it's broken and want it back the way it was. There > really isn't anything more to elucidate on when you tell somebody that > they just fucked everything up and you want it back the way it was.
hm. see, here's the issue. you think nobody was aware of the regressions at any given point in time? so to have people annoyed, in your face and even asking the same questions several times a day with no real constructive input when there is complete awareness of the situation is not only galling, it's a waste of time. thanks for playing, but unless you have something useful to add to a conversation... go find someone who isn't me to have it with.
i know how counter that is to the way those raised on slashdot have come to think about interacting with others online. it's also common sense.
the worst part was that at every stage as we added things that needed to be there... approximately zero people who were the endless whingers about that specific thing would take any note. they'd just settle into the improvements silently at best and whinge about the next most obvious thing (often which we were already working on) at worst. criticism is fine; heck, one could view every patch that changes something fundamental in your code as a "criticism" of the existing code if one was petty enough. what makes criticism bad is when it is empty of content that moves the process towards the goal lines.
dealing with the skewed mindset of many of the users of free software is probably the most horrific thing about working on something in the open. it's amazing to me how so many people see it as some sort of right to be able to make developing in the open as difficult, demoralizing and time consuming as possible.
so i finally just said, "i've had enough, you people start showing some basic responsibility as participants in this process, communication being part of that process. otherwise, you can go somewhere else because i'm not going to take part in that abuse of the process."
i wish more developers would do the same. maybe then the fanboi whingers (on all sides, around all projects) would start to smarten up just a wee bit and we could get on with a much happier development cycle.
urg, first, please just...aaron. not "mr." i hate that.
however, you missed the point of why i said what i did. it was, quite specifically, to not reward negative community behaviour. if i was a "take my ball and go home" sort of guy, i would've been gone with a lot more than a menu a long time ago.
i'm sorry you (or the grandparent poster) don't like how plasma has come around. i wish it could've gone a different way. perhaps when you try to do something really interesting that's a non-trivial amount of work that tends to push at pretty much every boundary in the frameworks (from x on up) we can have some fun story swapping sessions. until then...
By "extension to" the poster probably means "in addition to the ODF spec" not "getting it into the ODF spec". Sun can not do anything about that (for obvious reasons if you think about it for a few seconds). Even then, your characterization is unfair. The KOffice developers embraced ODF and have been an active part of helping shape the specifications. Sun doesn't pay a single one of them and there are things that KOffice apps support that OO.o didn't/doesn't that are in ODF. Frames in word processing documents comes to mind, for instance. David Faure is a voting member on the ODF OASIS technical committee and there are a few regular participants in the ODF process from the KOffice team. Which is to say, reality turns your assertion on its head.
> but we have to support them both *anyways*, so its not like its a big deal.
Holy mackerel.
First: I really don't care to get into a pissing match about the deficiencies of OOXML as a possible standard (they are legion and often fundamental; and whether or not you understand that and/or choose to minimize the severity of these things changes nothing). I will say that I'm very happy to finally see at least *some* open documentation for the new Microsoft Office format; that has to make things easier for the people implementing filters. As such I am completely unsurprised that those people are happier than they were a couple years ago. In fact, I'd be surprised if they weren't. That part is probably something you and I agree on =)
However the quote above is utterly shocking. Let me explain what I mean:
You are right that we have to support both OOXML and ODF out of practicality. But you know what? That sucks. It would be best for everyone if there was only one format to support. Nobody would lose in that scenario, except perhaps the owners of companies with business models that depend on format variance to sell their product.
In the case of document format storage, a standard is truly important because formats (poor or not) that eventually lose implementations over time carve out blank spaces in our history once we can't read them properly. These same formats are also the source of certain information inequalities in society (e.g. those who can't obtain an implementation for financial, social or political reasons). This may not matter so much for Acme Inc's quarterly reports but it sure does for government, health and other socially vital information. Remember when some hurricane Katrina victims couldn't use the FEMA website because they had slightly older computers? This isn't a made up boogyman, this is stuff that bites us as a society fairly regularly. Now imagine a hundred years from now when we can still read the constitutions of our countries, research papers, poetry and other examples of human kind's great literary works that are hundreds or even thousands of years old... but can't read the documents we're creating at the start of the 21st century. How will we learn from our history if we can't study it fully?
Getting proprietary formats out of the way as soon as possible so that we do not extend this mess any further than necessary is absolutely the responsible thing to do in light of our (hopeful) future.
By allowing OOXML to pass from "specification" to "international standard" would be doing exactly that: extending the problem as it will give years if not decades more life to the format. If OOXML was rationally implementable and properly documented, it wouldn't be as big of an issue. It would be, as you put it, simply suboptimal. The fact of the matter is that OOXML is not rationally implementable and not properly documented. That's why it lost the recent vote; it wasn't because of lobbying (and trying to imply that when Microsoft got its hand caught in the cookie jar is pretty ballsy, by the way). Are some interests acting out of concerns for their business models or pet projects when they rally for ODF and against OOXML? I'm sure they are; but that alone isn't reason to dismiss the fact that OOXML is problematic and that we don't need two standards (any more than it is to dismiss OOXML just because it comes from Microsoft).
So please, admire OOXML for what it is: a step forward in documenting what historically has been one of the more pernicious sets of file formats we've had to deal with; but don't mistake that for being a reason to make it an international standard which will only prolong the issues that are part and parcel of the Microsoft Office formats, even in this current version of the specification.
I know that having a bunch of people shit on you in public sucks major donkey nuts and certainly would put most rational people into a rather ungracious mood, but please think above that noise and consider with your intell
yeah, it was pretty funny. a few of us went for an unscheduled swim in loch laramond, with the "unscheduled" bit resulting in us stripping down to our briefs. frigging cold water but very refreshing. since we also had these two nice fires, i figured i'd dry out my gear rather than let it sit soggy in the scottish drizzle.
i dunno, i think it's important not to take one's self overly seriously. creating technology should fun have as an element, and it's hard to have fun when you're serious all the time.
that said, when time comes i get pretty serious. there are pictures of that on the net too, but they are less enjoyable to look at;)
i suppose i could be a bit more helpful and comment on this as well..
> Webkit is going to be adopted in KDE as a Kpart,
what's happened is that the Qt rendering layer has been added to the main webkit repository and several people at Trolltech and from the KDE community are working on webkit and the Qt based rendering in that repository.
this opens the way for webkit to show up in kde, including the kpart.
hopefully more of the khtml forks will follow suit and join mainline dev, but this certainly does start to bring together two of the bigger and more knowledgeable teams when it comes to khtml/webkit.
> features in KHTML that > aren't in Webkit are being added to Webkit
i think a more accurate term is "everybody wins". the code bases have evolved and it has come time to bring the best of all worlds together. the path chosen to get there is interesting, but not a matter of winners and losers.
> Much as some folks are always worried about KDE being beholden to TrollTech
we solved this issue literally years ago with the FreeQt foundation and the contract that group has with Trolltech that ensures Qt will always be open sourced. would be nice to see more companies offer such guarantees around their free software contributions.
perhaps you've never used KDE or never noticed the Printing configuration dialog, but KDE users configure CUPS all the time without ever seeing a web page or setting anything up. it's just as easy, and in some cases even easier, than the process on other operating systems.
like the identity management software they recently GPL'd after buying it? or how about GFS after buying systina (sp?)? or all the stuff that red hat employees have written in house (which is non-negligable)?
no, Red Hat has a -policy- stating they release everything they do as free software.
afaik, they'd have to be new plugins (the current ones have been shipped as part of Qt) and be a separate product altogether.
and it's not like having a GPL version of their code has hurt them, which is the base premise of your supposition. i believe it's actually -helped- their sales.
if that were to happen, the Free Qt Foundation's agreement with Trolltech will kick in and Qt will be released under the BSD. that's a worst case and rather unlikely scenario, however.
it assumes that having Qt under the GPL is a bad thing for Trolltech. i really have to wonder how well known and popular Qt would be today if it hadn't been released as permissively as it have.
there have also been a -lot- of benefits to Trolltech with having Qt GPL'd including having a full desktop platform on UNIX and Linux that "Qt-friendly", the immense amount of testing and real-world feedback they get via the usage of the GPL versions, etc.
there are a lot of companies out there, several of whom are also public, that have released their primary software assets under a Free software license such as the GPL. so there's precedence for this in any case.
Slashdot Mirror
> I can argue that the existence of Samba can
> be seen as promoting those proprietary technologies
the samba team isn't sitting on an ECMA or ECMA-like committee. that's the source of all this bruhaha.
> is not attacking them for doing something which is emphatically a good thing,
i totally agree people shouldn't be attacking them. i disagree that it's an emphatically good thing (there are other ways of achieving what they need to, btw, that don't come with the baggage).
i also think that it's a self-evident fact that they are playing the communications game very poorly right now. this article and many others just like it are the proof. =/
> but rather just get the truth out and not let FUD like this spread.
agreed.
what, exactly, is evil about a dual licensed toolkit?
...)
(especially when money earned goes into paying for the development of more free software
i mean, you're free to feel however you wish about things, but making a statement about principles and evilness would do well with some actual substance behind it.
"I don't see anyone (wrongly) trashing Samba as a project, and yet its existence and the effort to implement OOXML support is virtually identical in terms of free software."
the difference is that the samba project is not taking a position that can be perceived as promoting those technologies as a formal international standard. and that is why, in a nutshell, there isn't the bruhaha over samba, but there is over this OOXML stuff.
it's unfortunate and not representative of the motivations of the people involved (as you note) but it is a completely predictable reaction given the political issues here. i personally don't believe the GNOME foundation is actually trying to attack freedom in general or ODF in specific through their OOXML position, but intentions alone are not always enough. in this case i fear some political naivety is resulting in a series of unfortunate public missteps. =/
given that KOffice uses ODF natively, providing good evidence that ODF is not simply a one-project/company proprietary format being dressed up as a standard, yes it is important. it's a very compelling argument in favour of ODF that has been used quite a bit in the push towards ODF standardization; it's not uncommon to see ODF stalls at tech events showing OpenOffice one one computer and KOffice on another displaying the same document. more examples of ODF usage are appearing every day now, of course =)
and yes, a good number of people do use KOffice. certainly not as many people as use OpenOffice, but to the users of KOffice knowing that they are working with apps that use an interoperable format is indeed pretty important to them.
"I'm sure it's great being homeless with a clean conscience."
that is a false dichotomy. many people make a fine living while standing up for what we believe in. it's not magic, it's just conviction and the willingness to live in accordance with your beliefs as much as is humanly possible. we all fail at that from time to time, of course, but when not living in accordance with your beliefs becomes the prevailing pattern in one's behaviour there is a problem: either you are betraying your own self or you don't actually believe what you say you do.
making these (at times not easy) decisions does not need to, at least in the "first" world, come at the expense of an income. granted, you might make less money (though not necessarily) but you'll certainly live more fulfilled.
of course, most people using OpenSUSE actually use KDE as has been shown by surveys of their own user base. you can see the results for yourself right here.
i'd also not turn my nose up at successes like the EEE PC which ships with KDE software by default and is well on its way to making the sales targets of 3-5 million units in its first year.
it's also great to see gnome centric companies, such as Canonical, Red Hat, or even smaller ones like Userful, have so much commercial success with KDE. Userful is interesting: they had their booth with GNOME desktops, but the big vertical banner showing their highlight installation was KDE (on SUSE =). it's also substantial new installations, such as the French parliament or the school districts in the country of Georgia or....
trying to measure market viability and realities via distrowatch is a lot like trying to predict the weather by consulting the water in your bathtub.
yes, KDE purposefully linked GPL licensed code to QPLv1 code. however, it was THEIR code which means that they were fully within their rights to do so. anyone building apps on top of those libs implicitly agreed as well.
linking someone else's code would be an issue, and in the 2 cases where that happened it was rectified as soon as it was brought up; it's also useful to note that those 2 cases were small code fragments, not significant bodies of work, and as such certainly not evidence of a willfull plot or some such thing. they were oversights, and corrected in a timely manner without fuss.
and this was what, getting to be 10 years ago now? today we have nice clean GPL'd (or "better") code on every platform we support. let's find some new issues to grind over. =)
that's a fraction of the changes, though some of the more controversial ones.
you do know you have been able to do that with kicker (multiple taskbars, different configs, as you noted) for ... years?
but ... it has only 5 fingers on both hands.
(i love that movie)
> but not immediately before a major release when the rest of the desktop is pretty much
... good.
... go find someone who isn't me to have it with.
... approximately zero people who were the endless whingers about that specific thing would take any note. they'd just settle into the improvements silently at best and whinge about the next most obvious thing (often which we were already working on) at worst. criticism is fine; heck, one could view every patch that changes something fundamental in your code as a "criticism" of the existing code if one was petty enough. what makes criticism bad is when it is empty of content that moves the process towards the goal lines.
> finished and not if you can't finish it on time.
so, we didn't do what you shouldn't do
> when people point out it's broken and want it back the way it was. There
> really isn't anything more to elucidate on when you tell somebody that
> they just fucked everything up and you want it back the way it was.
hm. see, here's the issue. you think nobody was aware of the regressions at any given point in time? so to have people annoyed, in your face and even asking the same questions several times a day with no real constructive input when there is complete awareness of the situation is not only galling, it's a waste of time. thanks for playing, but unless you have something useful to add to a conversation
i know how counter that is to the way those raised on slashdot have come to think about interacting with others online. it's also common sense.
the worst part was that at every stage as we added things that needed to be there
dealing with the skewed mindset of many of the users of free software is probably the most horrific thing about working on something in the open. it's amazing to me how so many people see it as some sort of right to be able to make developing in the open as difficult, demoralizing and time consuming as possible.
so i finally just said, "i've had enough, you people start showing some basic responsibility as participants in this process, communication being part of that process. otherwise, you can go somewhere else because i'm not going to take part in that abuse of the process."
i wish more developers would do the same. maybe then the fanboi whingers (on all sides, around all projects) would start to smarten up just a wee bit and we could get on with a much happier development cycle.
urg, first, please just .. .aaron. not "mr." i hate that.
...
however, you missed the point of why i said what i did. it was, quite specifically, to not reward negative community behaviour. if i was a "take my ball and go home" sort of guy, i would've been gone with a lot more than a menu a long time ago.
i'm sorry you (or the grandparent poster) don't like how plasma has come around. i wish it could've gone a different way. perhaps when you try to do something really interesting that's a non-trivial amount of work that tends to push at pretty much every boundary in the frameworks (from x on up) we can have some fun story swapping sessions. until then
By "extension to" the poster probably means "in addition to the ODF spec" not "getting it into the ODF spec". Sun can not do anything about that (for obvious reasons if you think about it for a few seconds). Even then, your characterization is unfair. The KOffice developers embraced ODF and have been an active part of helping shape the specifications. Sun doesn't pay a single one of them and there are things that KOffice apps support that OO.o didn't/doesn't that are in ODF. Frames in word processing documents comes to mind, for instance. David Faure is a voting member on the ODF OASIS technical committee and there are a few regular participants in the ODF process from the KOffice team. Which is to say, reality turns your assertion on its head.
> but we have to support them both *anyways*, so its not like its a big deal.
... but can't read the documents we're creating at the start of the 21st century. How will we learn from our history if we can't study it fully?
Holy mackerel.
First: I really don't care to get into a pissing match about the deficiencies of OOXML as a possible standard (they are legion and often fundamental; and whether or not you understand that and/or choose to minimize the severity of these things changes nothing). I will say that I'm very happy to finally see at least *some* open documentation for the new Microsoft Office format; that has to make things easier for the people implementing filters. As such I am completely unsurprised that those people are happier than they were a couple years ago. In fact, I'd be surprised if they weren't. That part is probably something you and I agree on =)
However the quote above is utterly shocking. Let me explain what I mean:
You are right that we have to support both OOXML and ODF out of practicality. But you know what? That sucks. It would be best for everyone if there was only one format to support. Nobody would lose in that scenario, except perhaps the owners of companies with business models that depend on format variance to sell their product.
In the case of document format storage, a standard is truly important because formats (poor or not) that eventually lose implementations over time carve out blank spaces in our history once we can't read them properly. These same formats are also the source of certain information inequalities in society (e.g. those who can't obtain an implementation for financial, social or political reasons). This may not matter so much for Acme Inc's quarterly reports but it sure does for government, health and other socially vital information. Remember when some hurricane Katrina victims couldn't use the FEMA website because they had slightly older computers? This isn't a made up boogyman, this is stuff that bites us as a society fairly regularly. Now imagine a hundred years from now when we can still read the constitutions of our countries, research papers, poetry and other examples of human kind's great literary works that are hundreds or even thousands of years old
Getting proprietary formats out of the way as soon as possible so that we do not extend this mess any further than necessary is absolutely the responsible thing to do in light of our (hopeful) future.
By allowing OOXML to pass from "specification" to "international standard" would be doing exactly that: extending the problem as it will give years if not decades more life to the format. If OOXML was rationally implementable and properly documented, it wouldn't be as big of an issue. It would be, as you put it, simply suboptimal. The fact of the matter is that OOXML is not rationally implementable and not properly documented. That's why it lost the recent vote; it wasn't because of lobbying (and trying to imply that when Microsoft got its hand caught in the cookie jar is pretty ballsy, by the way). Are some interests acting out of concerns for their business models or pet projects when they rally for ODF and against OOXML? I'm sure they are; but that alone isn't reason to dismiss the fact that OOXML is problematic and that we don't need two standards (any more than it is to dismiss OOXML just because it comes from Microsoft).
So please, admire OOXML for what it is: a step forward in documenting what historically has been one of the more pernicious sets of file formats we've had to deal with; but don't mistake that for being a reason to make it an international standard which will only prolong the issues that are part and parcel of the Microsoft Office formats, even in this current version of the specification.
I know that having a bunch of people shit on you in public sucks major donkey nuts and certainly would put most rational people into a rather ungracious mood, but please think above that noise and consider with your intell
add Adobe with Air to that picture, and there are Others(tm) lurking with webkit trees.
yeah, it was pretty funny. a few of us went for an unscheduled swim in loch laramond, with the "unscheduled" bit resulting in us stripping down to our briefs. frigging cold water but very refreshing. since we also had these two nice fires, i figured i'd dry out my gear rather than let it sit soggy in the scottish drizzle.
;)
i dunno, i think it's important not to take one's self overly seriously. creating technology should fun have as an element, and it's hard to have fun when you're serious all the time.
that said, when time comes i get pretty serious. there are pictures of that on the net too, but they are less enjoyable to look at
> what 'coming together' means
i suppose i could be a bit more helpful and comment on this as well..
> Webkit is going to be adopted in KDE as a Kpart,
what's happened is that the Qt rendering layer has been added to the main webkit repository and several people at Trolltech and from the KDE community are working on webkit and the Qt based rendering in that repository.
this opens the way for webkit to show up in kde, including the kpart.
hopefully more of the khtml forks will follow suit and join mainline dev, but this certainly does start to bring together two of the bigger and more knowledgeable teams when it comes to khtml/webkit.
> features in KHTML that
> aren't in Webkit are being added to Webkit
as many as possible, yes.
i think a more accurate term is "everybody wins". the code bases have evolved and it has come time to bring the best of all worlds together. the path chosen to get there is interesting, but not a matter of winners and losers.
> Much as some folks are always worried about KDE being beholden to TrollTech
we solved this issue literally years ago with the FreeQt foundation and the contract that group has with Trolltech that ensures Qt will always be open sourced. would be nice to see more companies offer such guarantees around their free software contributions.
> And if open source devs could never do that
perhaps you've never used KDE or never noticed the Printing configuration dialog, but KDE users configure CUPS all the time without ever seeing a web page or setting anything up. it's just as easy, and in some cases even easier, than the process on other operating systems.
he didn't.
like the identity management software they recently GPL'd after buying it? or how about GFS after buying systina (sp?)? or all the stuff that red hat employees have written in house (which is non-negligable)?
no, Red Hat has a -policy- stating they release everything they do as free software.
afaik, they'd have to be new plugins (the current ones have been shipped as part of Qt) and be a separate product altogether.
and it's not like having a GPL version of their code has hurt them, which is the base premise of your supposition. i believe it's actually -helped- their sales.
if that were to happen, the Free Qt Foundation's agreement with Trolltech will kick in and Qt will be released under the BSD. that's a worst case and rather unlikely scenario, however.
it assumes that having Qt under the GPL is a bad thing for Trolltech. i really have to wonder how well known and popular Qt would be today if it hadn't been released as permissively as it have.
there have also been a -lot- of benefits to Trolltech with having Qt GPL'd including having a full desktop platform on UNIX and Linux that "Qt-friendly", the immense amount of testing and real-world feedback they get via the usage of the GPL versions, etc.
there are a lot of companies out there, several of whom are also public, that have released their primary software assets under a Free software license such as the GPL. so there's precedence for this in any case.
ah nipples. a nice topic!
but no, it's not just the location. it's also "latching", the process of getting the suction bit working, that is taught.
about the only thing a baby knows is how to suck and that it's hungry.
which is much like many engineering projects: sucking comes naturally, but doing anything productive takes effort and education.