What are the implications of "getting it out there"? It means that the KOffice team will now have "release often" on their mind, it means early adopting testers can more easily grab KOffice 2 for their operating system of choice and start testing it and it means that people who are interested in getting involved with KOffice as contributors can now feel confident that they are getting involved with something that isn't a vapour(ware) trail but something real that does real, actual releases.
This is not unlike the KDE 4.0 release, actually. I hope everyone has learned enough about "getting it out there" platform releases to make this first set of steps work well for KOffice 2 and the people behind it. That means not rushing to make it the default in operating system releases, testing it with the realization that there are many cracks left to be plastered over, etc.
The image Cyrile used on his blog entry announcing KOffice 2.0.0 sums it up visually just perfectly:
Together, including those of us who don't contribute to KOffice directly, we can make this a great success. I'm really happy for and proud of the KOffice team, and I hope you can be as well.
Kexi and Krita are my personal faves, but the entire suite holds immense promise.
You can read more about the release by visiting KOffice 2.0.0 article on TheDot or visting the release announcement from the KOffice project itself.
6 comments:
This is a request of a FLOSS user to all Distributions:
PLEASE do not make this release default KOffice version in your distribution. Make it default in betas, factory versions, etc. Do not make it default now and wait for 2.1 or 2.2 instead.
Distributions should make wise choices for the end user. And users using stable distributions want stable software. Using linux i do not want to fell like beta tester all the time. So wait this 6 months and i will have less pain in my live.
thanks in advance
regards
It's nice to see KOffice coming along, and it just shows you what can be done with limited resources and manpower if you have a sensible environment that surrounds developers and helps them.
The only minus against KOffice is that is isn't going to be able to handle Microsoft Office documents well and that pulls back all the great work that has been done. Sad, but true. That can't be done by the KOffice people as they have enough to do. Personally, I'd like to see some investment in a set of Qt classes to handle Office formats, a set of Qt classes to handle ODF and a programmable means of converting Office formats to ODF. Not only would it be a boon to KOffice and open source applications but it would make a hell of a lot more people use Qt, want to pay for it and have other spin-off benefits for Nokia as well.
I wouldn't count on that, kakos.
While I'm happy for all KOffice devs and users that the 2.x series is finally shaping up, I really wish the KDE community as a whole would rethink its habit of releasing revisions never intended for productive use as point-0s, no matter how big the "might blow up" disclaimers are - software users in general and (apparently) the Fedora maintainers in particular expect a somewhat usable product from a .0 and I'm positive that releasing KDE 4.0 as 3.9 and Amarok 2.0 as 1.9 would have shielded these projects from a lot of (maybe undue) criticism while giving devs and early adopters a lot of cool stuff to play with.
@Cyrus XIII:
"never intended for productive use as point-0s,"
for production use, not productive use. the difference is important: the software is useful, but it's not ready to be pressed into critical usage scenarios like corporate or educational deployments.
you may remember, or maybe not, that this is precisely how Free software got to where it is today: release early, release often.
the irony is asking Free software to stop doing what got it this far is almost funny.
"no matter how big the "might blow up" disclaimers are - software users in general and (apparently) the Fedora maintainers in particular expect a somewhat usable product"
then the Fedora maintainers have some issues with their ability to reason things through. that's solvable, however, and i've had a number of discussions with them on these matters.
now the strategy you're suggesting of "wait till it's production ready" will lead, quite quickly, to Free software never releasing anything innovative or new. it relegates us to warmed-over versions of what we released N months ago. and while that is just great for stable lines (KDE 4.x, Amarok 2.x, etc) it's completely untenable for big steps forward like KDE 4.0, Amarok 2.0 or KOffice 2.0.
because as you wait for "good enough for production" your developer base dwindles to naught, your testing base disappears or just never shows up in the first place and the outside world keeps changing so you get stuck in a constant "now we need to change these N other things too before we can release" cycle.
so while you and the others asking for "perfect dot ohs" have all the best intentions and have obviously put some thought to it, what you're asking would, quite literally, kill Free software on the desktop in the long term since this space is still all about high innovation.
"Release early, release often" is a motto I would never call into question. My concern is that a point-0 communicates something said releases were not and KOffice 2.0 might not be either. I wouldn't expect or want these projects to linger in the pre-point-0-phase, like, for instance, certain popular open source movie players have done for the past few years.
Its not a question about whether or not to release a desktop environment with stable libs but beta quality programs and a rather unstable shell. That's actually a very good point in the development process to make a release, but at the same time, communicating the "enthusiasts only" nature of that release should have top priority, lest a lot of people feel that they somehow got suckered into using something that wasn't for them.
Granted, one could argue that the first release of the KDE4 series would not have received the same amount of feedback, had it been given an in-between number and that subsequent releases would not have turned out as nicely as they indeed have. Still, the means by which some of that feedback was acquired feels at least somewhat disingenuous, all the best intentions of the developers notwithstanding.
@Cyrus XIII: "My concern is that a point-0 communicates something said releases were not and KOffice 2.0 might not be either."
what has KOffice 2.0 communicate that it is? anyone who uses a version number (any version number), particularly for a F/OSS project, out of or without context to make a decision as to whether to push it to their production user base or not is being negligent.
"I wouldn't expect or want these projects to linger in the pre-point-0-phase, like, for instance, certain popular open source movie players have done for the past few years."
or like some window managers, or like ... it's pretty evident that projects that hesitate to make milestone releases suffer and often never make it out the door.
on the other hand, remember the first mozilla releases? horrible, even the 1.0 release. but necessary.
there was a time in F/OSS where this was _allowed_ by the user community and the downstream packagers. today it's all gotten rather distorted and making it very, very hard to get what needs done upstream.
the phrase "unintentional sabotage" and "forgetting the lessons of the past" describe it very well.
now, in the past, a lot of F/OSS desktop projects were pre-1.0, so they could linger at 0.14.5 for a long time before hitting 1.0.
but now with things much further along, what do we do? and with meanings given to the numbers due to concerns like binary compatibility in libraries? numbering is trickier today.
"lest a lot of people feel that they somehow got suckered into using something that wasn't for them."
hm. that's very loaded language full of accusatory terms, as if we were intentionally trying to trick people. personally, i resent that quite a bit; it's not like this is the first time that accusation has been made, nor the first time it's been addressed.
there was precisely one communication where there wasn't a "not for production deployment" disclaimer; unfortunately it was the announcement of the release.
but all the rest of the communication, from blogs to the release keynote to communication with downstreams, noted that it was likely to "eat your children".
there was no intent to deceive and quite a bit of frank, honest communication about it.
how many mea culpas do you want before you start looking at the whole picture of communication around 4.0, or even just move on and realize that, golly gee, we're at 4.3beta1 now?
koffice's announcement is full of "danger danger!" statements, walking on eggshells to avoid any miscommunication and what do we get? more complaining about KDE 4.0.0? how is that productive, useful, positive?
it's actually rather discouraging.
"the first release of the KDE4 series would not have received the same amount of feedback"
not only not received the same amount of feedback, but would not have been accepted as needing to stick to binary compatibility, nor reflect the work already done in many of the other applications, nor get the team focused on time-based releases again.
at some point a release had to be made, and giving it a waffling name that suggests "this is just another beta.." would not have accomplished the same and we would not be where we are now with 4.2 and soon 4.3.
_reality_ shows it's a strategy that works, the criticism that continues to get flung our direction about it doesn't change that but it does create a pretty unenjoyable environment to interact in.
i wish i could believe that describing the situation one more time would actually allow us to get past this nearly 1.5 years later, esp now that it's evident the results it brings.
Post a Comment