facts to date (many of them obvious):
- we won't sacrifice the code base's integrity in the process
- we're hoping for more contributors by reaching out to new pools of people
- we're hoping to take the issues of open interoperability to the people and hopefully open up groupware, office document formats, etc a bit more
open issues/questions:
- if we do get an influx of developers who really know little to nothing about our culture and community, how do we effectively triage them into the project? or do we just try and keep them developing applications and separated from the project?
- if we do get an influx of users, how do we deal with them and what influence are we willing to let them have over our priorities?
- what are the marketing positions we will take?
- what level of quality and what breadth of features will we commit to on these other platforms?
- given that market share equals market clout, how do we avoid giving microsoft yet more leverage in industry by helping keep people on their platform as they continue to engage in their efforts against free software (think: hardware vendor relations (and not just kernel drivers), file format hijinks, single-platform / lock-in developer strategies)?
i think each of the above is solvable. i also think that we need to have answers put into words for the above so we can both work together and know we actually have answers rather than trusting quietly that we do even if we don't.
reasons the open issues are worth discussing
- these are big opportunities that come with reasonable but significant risks ..
- we need to have a coordinated idea of where the heck we're going with all these new platforms so we can get the most out of them and not (even unintentionally) work against ourselves
- our project dynamics (community, culture, etc) are valuable and worth ensuring the longevity of
reasons i'm not suggesting too many answers up front but instead asking all sorts of questions and generally poking people think:
- i probably don't have all the answers (no suprise to anyone, i'm sure ;)
- i'm not involved with the windows and mac ports and so don't feel like i am the best one to make up these answers, even if i am directly affected by these answers
- we need consensus.
- it'll be difficult to coordinate our efforts if the people involved with windows/mac ports are not in the game, too
- when i'm not poking and prodding the conversation doesn't seem to happen. i don't like that, but that's the way it is.
i don't think this needs to happen on blogs, either, but we lack a mailing list for this topic and even the planned win32 developers sprint won't bring together all the people necessary for this conversation (it will lack many from the other platforms). so i'm at a loss as to where this conversation will reach the audience necessary and not be off-topic.
13 comments:
Since I inadvertently set off this whole discussion, I figure I had better, at least try to, come up with an answer for at least a some of the open issues. (somehow I have a feeling this is what Aaron has been wanting from me since his initial reply... .-) )
"if we do get an influx of developers who really know little to nothing about our culture and community, how do we effectively triage them into the project?"
Slowly!
Slowly and not too many at a time. Really, this might sound obvious, but I think these are the two most critical points. I think the biggest danger with a possible rapid influx of new devs is that the project structure falls apart. Growth needs to be managed.
Get them involved in something productive that does not radically change the direction of the project. Bug fixing, etc, and make it very clear that features that are unique to the proprietary platforms or that requires substantial sacrifices in functionality on the free ones will not be accepted.
hopefully, this will give the new developers time to learn at least a little about our culture and think about if it is really something they wish to contribute wholeheartedly to. And if we gain just a few of those, then I think it is a very good start.
"if we do get an influx of users, how do we deal with them and what influence are we willing to let them have over our priorities?"
Same as with users today. At least in the Amarok project, we filter user request fairly heavy handedly, as many of them would pull the project in too many different directions at once. In Denmark at least we actually DO have an old saying that goes something like: "If you try to be friends with everybody, then you are nobodys friend".
Of course we do listen to the users and implement requested features, but at the end of the day, the vision of where the project should go rests with the developers.
- Nikolaj
re: porting to windows. I understand your position and while I share your concern, i do not fully agree with it.
*) New developers and their introduction to KDE community and culture: This is the case with EVERY developer, they start of knowing nothing or "everything" about KDE and interact, and get along (or not) according to their personality
*) influx of users: every user will get along (or not) with the KDE community according to their personality, no matter what their computing skills and needs. How does KDE deal with new users NOW and in general? does this need to be changed?
*) marketing position: why any need for change? KDE has a strategy and goal. and if it needs to be updated by porting to one OS platform, perhaps the vision needs to be redressed anyways.
*) Level and breadth of features: This is already happening for every *nix variation (solaris,*bsd, linux). The quality is based on what trolltech is willing to do and what each KDE developer's personal level of quality is -- and it is very high.
*) If marketshare is market clout, is KDE not gaining clout?
some of your concern is with managing growth. This needs to be looked at whether KDE is ported to windows or if 4.x is successful beyond anyone's imagination: growth always needs to accounted for and, where possible, effectively managed.
One thing you mentioned is a previous blog: "though too often that new thing is a diminishment of the old". Another perspective -- Children never diminish their parents; tiny streams build mighty rivers
@nicolaj: i agree with the slowly and carefully parts. however, the issue becomes if the volume of new comers reaches new heights. do our current processes scale?
we've been through a few periods of new levels of growth in kde and each time it required some adjustments in our processes to deal with greater numbers. and we're not doing the best job possible with the numbers we have to deal with right now, to be honest.
@anonymous:
"This is the case with EVERY developer"
our current developers come with at least a basic understanding of who we (kde) are and of the concepts of free software.
dealing with those in the windows world it's a far more basic set of concepts that need to be taught.
we have 350+ active source code commiters in kde's svn right now; let's say that the win/mac community results in 100 new active contributors. that would make some 20-25% of our commiters people who are not familiar with the community, its ethics and its background.
should such an influx happen in a short period of time and we're not prepped for it, the disruption will likely be considerable.
"How does KDE deal with new users NOW and in general? does this need to be changed? "
i don't think it scales particularly well, no. think of bug reporting or user support, things we already struggle with given our current #s
"marketing position: why any need for change? KDE has a strategy and goal."
because we don't really have a strategy for win32/mac. we have a kde strategy which includes our core technologies and identity and ties with other free software. our message is very much oriented towards those who might already know something about free software; we've started to adjust that but i don't see an explicit coherent game plan for this.
"The quality is based on what trolltech is willing to do and what each KDE developer's personal level of quality is "
the platform related quality is generally based upon the project's priorities. the software quality itself is, as you noted, a product of the developers themselves.
but at what point are we going to be ready to say, "the windows port is good enough now to be marketed to <market segment>" that implies having quality markers and is important so as to make a good first impression.
there's also the question of what level of integration with the kde desktop environment are we willing to make and/or sacrifice for cross platform consistency?
how do we manage packaging and support for operating systems where there is little or no support from the OSV? this is a luxury we have with the Linux/UNIXes.
these are unanswered quality-related questions.
"If marketshare is market clout, is KDE not gaining clout?"
not in areas where the source of control is the platform itself. compared to linux/unix, kde is not a platform, but a toolkit, on win32 and macos. phonon, solid, etc will almost certainly use native facilities for their backends, which once again leaves issues of device integration in the hands of microsoft and apple.
the game really changes when you don't mange the platform and when you have competing interests with the OS developers.
"growth always needs to accounted for and, where possible, effectively managed."
something we agree on! =) this is indeed a large part of my concern; the other part of it is ensuring a technology environment that remains hospitable to open source development. it seems a lot of people are giving microsoft way too little (or too much?) credit on that last point.
all the same, i don't see much care, thought or planning happening right now on the issues of growth. if things do take off in the next couple of years and we're not ready for it, it could result in very unfortunate consequences.
kde is not a simple project with just one or two main products and manageable group of contributors. we're over a thousand contributors working on hundreds of projects in an already loose knit community that manages direction through shared understanding and culture.
"Children never diminish their parents; tiny streams build mighty rivers"
we're not talking about children here, unless we cut the win/mac communities out of the core kde community. as long as the participants and users are part of a larger kde community, it is a matter of growing a single culture and community, not producing offspring.
I'm very much in favour of this porting effort mostly because I see it as an opportunity to create more business around KDE.
If a successfull company can make money selling Kollab / Kontact and can hire 10 KDE hackers, it will be beneficial for us even if most of their client are still using Windows.
KDE needs more professionnal developers. The distribution business (Suse, Mandriva) which is employing most of our professional developers is very shaky. Desktop Linux is growing very slowly. Having some cross-platform comprehensive products will create business oportunities.
We nurture developers when they are students but we must foster career paths where they will still be able to contribute to KDE.
Finally, I doubt that porting parts of KDE to Windows is going to create cultural problems. The Linux geek culture is so much stronger than the Windows one even if we are a tiny minority.
cmiramon
I think it is important to make it clear to all devs that (as nikolaj mentioned): features that are unique to the proprietary platforms or that requires sacrifices in functionality on the free ones will not be accepted.
Once in a while when I come across a firefox extension that doesn't work on Linux, it seems that the Mozilla project has its priorities wrong. Mozilla unfortunately lists Linux with a lower priority than proprietary platforms
on its roadmap. This is something I would not like to see happening with the KDE project ever.
I think the most important thing is to actually think about it before a possible crisis happens. What are the likely results of a user/developer spike from alternate platforms? How do we handle each of the possible results?
The actual choices the project makes are a significant degree less important than the conversation that will help everyone in the community understand where we've decided to go.
Ideally we don't want to be in a situation where "RTFM" is the natural answer to a poor uniformed user communication.
Thanks, Aaron for pushing for the conversation.
@Matthew: "The actual choices the project makes are a significant degree less important than the conversation:
bingo.
In KOffice one strategy we decided upon is to have loads of plugin opportunities. Which means that we hope for 3rd party development to take off after the 2.0 release. We based this hope on the Windows release and the larger userbase that that brings us.
At the same time my personal hope is that if we can push great free and open source software to a huge group of people it becomes a lot more easy to overcome the fear and uncertainty that lives with people on Windows about systems like Linux. Being able to say "its from the makers of Amarok, KOffice etc." will most likely be a great way to get people to not dismiss Linux out of hand. I think should be a consideration for the marketing team.
I'm quite unsure how to handle the new userbase. Happy users will become our greatest asset if we involve them and make sure that their opinions are respected. Things that most companies fail to do. But at this point we already are low on people correctly handling bugreports. Where just closing a bugreport without having at least a little conversation with the reporter tends to be quite a putt-off.
ThomasZ
@aseigo
"we have 350+ active source code commiters in kde's svn right now; let's say that the win/mac community results in 100 new active contributors. that would make some 20-25% of our commiters people who are not familiar with the community, its ethics and its background."
Couldn't your fears look superficial to me? Maybe let's back to the discussion after months. I've been involved in groups where e.g. translation or fixing the code (oo.org) was the main task and the fact that people use one shell or another (window or gnome or kde) is not as important as they technical competence. That said I've seen UNIX folks that would put many Motif-like GUI designs into KDE just because they do not care eg about usability. Same applies to Mac people - they are used to other paradigms (e.g. bundles and specific GUI ideas) than UNIX folks.
As a note: I do know a number of people that 1) use win32 and linux in parallel; 2) in the end they treat linux as 'freeware' in the morning and they act as zealots in the evening, if you propose them something nonfree-as-in-beer (e.g. as commercial Qt).
This reason alone gives a hope that people coming from !unix environments will increase number of people accustomed with vital market rules like this one: "if you do not want to give me your time, pay me for features I don't (and virtually nobody) care about".
I tend only to categorize people just to proffesionals an not-proffesionals. Just let them to use esources like Techbase, provided to them to ease diving into the multilayer project, that is KDE itself.
I also feel that too many blog entries suggest that "porting" means "rewriting" and then someone wastes too much if his time.
One of the reasons I think that KDE should embrace other platforms is the fact that it is inevitable to have KDE on others systems like Windows or Mac OS: KDE is way too good, and people _want_ to use KDE on those OS's... Now, what harms KDE there is that there are really no "official efforts" on those platforms. To give you an example, my girlfriend has Mac OS but is completely in love with KDE and specially two KDE apps: Amarok and Kontact. She got Amarok to run well on Mac OS, but doesn't find a way of getting Kontact running there. The problem gets bigger if you take into consideration that, instead of an official "KDE for Mac OS", there are two different "KDE for Mac"s: fink's and macport's. And who's the community behind it? How can she use the trace kontact leaves for fixing her problem _and_ helping the community? It's hard - she'll probably find a way but - it's way too hard.
If there are efforts like this, it is because users need KDE on those Operating Systems. Why not giving it to them? The right way?
I see people mentioning bug reports - imho the bug reporting website is a big scary monster still. in fact, I tend to put off bug reports because of it. what are the chances of *that* getting some love before the mad rush of windows users shows up?
oh, and people who don't think porting to windows will make a difference in culture must never have heard of the September that never ended :)
I worry that providing software for Windows will validate it as a platform. However, I don't think that's too much of a problem - most people don't realize how bad Windows is.
What I hope to see coming from a win32 port, is a proliferation of open formats. Providing KOffice will allow more people to switch from MS Word. Providing Amarok allows people to escape iTunes and Window Media Player. And hopefully Kopete can kill the evil that is MSN.
I'm already excited about recommending KOffice and Amarok to my Windows using friends.
stephan: I don't think anything will kill MSN until windows itself dies. there are too many garish bells & whistles that no open source client will ever be capable of, and too many people love those ugly things.
I think they're the same people who send me email in neon pink.
I wish kmail could deal with html the way kopete deals with rich text: make it readable, but let me strip out the obnoxious painful bits.
anyways, when it comes to apps on windows, this is how I think of it:
koffice is good because it promotes ODF, thus reducing MS Office lock-in.
kmail and konqueror are good so that people can get used to them instead of ff and thunderbird if they're trying to make the switch one app at a time.
everything else seems unimportant to me.
Post a Comment