This one should be really short, because it's more of an open ended question and some food for thought than a long exploration of a tangly topic. That question is: are we doing enough to ensure that projects that start to wobble a bit don't fall off the rails, crash and burn on us?
Every so often someone approaches me (or, more rarely, I approach them) to let me know that their project is in trouble in some way. Since this is a recurring issue for KDE (and other F/OSS projects, too), we can expect it to continue (and in larger numbers as our product count grows). It seems we most often just fail to identify the problem spots until it's gone a bit too far. The price we pay is great applications will stall even start to "bitrot" without achieving their full potential. There is no time like the present, however, so this made my list of Key Quests for 2010.
What's at the root of projects wobbling to their own demise? There are two issues that most often arise, and in both cases they seem to present an "unsolvable" roadblock to further development. This happens due to either technical issues such as an upstream project causing problems, or due to social issues such as one or more of the key developers no longer having the time or ability to work on the project, though on rare occasions it's due to disagreements between active contributors (though I can count the number of times that's been a real problem since I've been around KDE on my hands :).
We have a couple projects that are flagging right now and which I'm a bit concerned about. You may also be aware of some. I don't think that the sky is falling or anything; most of our projects are really rather healthy, but we can do better here, especially for the projects that are experiencing some downtime. How can we help them out?
One solution to the social issue of people dropping off due to life changes is to ensure that no one person is absolutely critical to the project in such a way that their leaving would kill the project. A constant stream of new developers is needed, and that's something we can all help with. We do a pretty good job of it already, with a pretty impressive rate of new commit accounts being generated. Can we more effectively direct some of these new hands to old projects that need them? Would it make sense in some cases for a few of us to descend upon a particular application and help get it moving again with a few months of involvement and a good jolt of energy?
The "nasty arguments" social situation is thankfully far rarer. A good, positive, supportive community really helps there, and our terrific Community Working Group fills in so many of the remaining gaps. They really are unsung heroes in the project at times. :)
For the technical issues, it is often a matter of getting the "right" people talking with each other and encouraging some creative thinking. That means that many technical issues can find solutions with some social work. Sometimes a face-to-face meeting is the best answer, and that's something that KDE e.V. can help with if there is one of us working out the logistics. This isn't rocket science, so can we get more developer sprints going where they are needed?
I enjoy helping with these things as I can, especially when it helps bring smiles back to the faces of the people I care about (read: everyone in KDE) and the code rolling in svn again. There are a few people in KDE who do this kind of work, but having more people involved in doing some health monitoring and even some nursing as necessary would be great.
I also wonder what other things we could be doing to help keep projects on their feet?
(This article is part of the "Key Quests for KDE in 2010" series)
Subscribe to:
Post Comments (Atom)
10 comments:
This https://bugs.kde.org/show_bug.cgi?id=162485 (KDE 4 SSL Certificate support incomplete) is software in need for more attention. It's the 3rd most hated bug, and if you read the bug report you see that no progress made on :(
A browser / desktop without SSL support is unthinkable nowadays, I would say...
[quote]Can we more effectively direct some of these new hands to old projects that need them?[/quote]
Only the projects in question know whether new hands would be a help, but I'd like to make a suggestion. We could have an easily accessible page, (techbase?) where any project that hasn't taken in new blood in, say, 12 months, could advertise that it needs new contributors. The control stays with the project, but it gives is somewhere to direct potential new contributors.
@openid: the state of SSL is pretty bad (and a statement on the level of use and attention konqueror as a web browser is getting these days), but KDE does have basic SSL support and konq can do https, though not as full featured as it should be.
@AnneW: "Only the projects in question know whether new hands would be a help"
i'm not so sure about that. with a bit of investigation it can of become pretty apparent when a project is experiencing some issues. at the very least we can identify projects that are in need and approach them tactfully to see how things are going.
"where any project that hasn't taken in new blood in, say, 12 months, could advertise that it needs new contributors"
i think the biggest challenges to this sort of approach is that
a) it requires the projects to be proactive themselves; if that was the case, we wouldn't have projects that quietly spiral down, they'd already be saying something
b) it still requires that the rest of us are paying attention and using that list to direct people in the right direction
i do think that having a "standardized" way for projects to wave a red flag of warning would be good, but we need to ensure flags get waved and then get acted upon. which seems to be the two bits we usually miss.
"The control stays with the project, but it gives is somewhere to direct potential new contributors"
i don't see the connection between "getting new contributors", "identifying projects that are having trouble" and "control". is there a single project out there that wouldn't want some additional contribution?
I’d be interested in hearing which projects you think are in need Aaron?
One which quickly comes to my mind is KitchenSync. It seems to be caused – http://forum.kde.org/viewtopic.php?f=20&t=61593 – by the delays of the upstream project it depends on, OpenSync.
Possibly another project is Kile – http://kile.sourceforge.net/ – even though it is making slow progress, the fact that a KDE 4 version still hasn’t been released now that we’re close to KDE SC 4.4 leads me to believe they have a shortage of developers.
I agree with openid that Konqueror is in trouble, and because it’s a web browser it’s inadequacies (no disrespect to the Konqueror devs here) are a serious disadvantage for KDE. Fortunately that will be/is solved by rekonq – http://rekonq.sourceforge.net/ – soon/now.
Aaron... I agree with your response to AnneW. It /is/ possible to identify projects in trouble, simply from doing analysis of the VCS logs. Probably even before the developers involved fully-appreciate the risks.
On a small scale I have done this in the passed when I have flagged-up unusual results in my previous analyses. I will be doing a lot more of this type of work for KDE in 2010.
If you look at the transitional period from KDE3 to KDE4, there were some key apps or features that fell off the radar during that time, and one or two that still haven't made it back. Key, that is, to the assumed majority of regular KDE users. An example would be K3B, which many users might regard as something of an essential 'cornerstone' KDE application, and would be perplexed to see suddenly disappear.
Perhaps some committee could flesh out what apps and technologies are necessary to form a cohesive basic KDE desktop experience, when compared against the default install of the competition (i.e. Windows, Mac, etc.). Which features should the 'standard' KDE desktop not be allowed to do without (unless an end user specifically chooses to not include such a feature)? This is of course difficult to agree on and be objective about. Such a committee could be assembled during the Akademy or Camp KDE events, be open to all interested parties and could reconvene once per annum (since what is regarded as relevant or essential today may not be so tomorrow).
Once this list of core features is established, KDE e.V. could monitor these projects and try to pump in and allocate additional resources as and when required. Not so much financially, just in terms of arranging meetings and suchlike to keep the relevant developers and other parties talking to each other and prevent the projects from going dry. One potential drawback would be that persons involved in projects known to be on such a list might sit back in the expectation of additional resources being granted (though I doubt that to be the attitude of the typical KDE developer!). Any fears about the joint efforts of the community to pull together rather than be 'managed' or 'directed' by higher powers should be quelled by the understanding that the idea is more to give projects a nudge or a helping hand, rather than anybody trying to step in and steer things with an assumption of holding any greater power.
There should be nobody being told what they should be working on (unless they're being paid to take such a position), but rather just being kept in the loop as to what current projects could do with a push and where efforts might be best appreciated. For what it's worth, I'm just a regular user, so these views might be a bit idealistic. I don't know the ins and outs of the developer community.
Getting more new hands on old project really need a culture setup in existing developers. It is similar in a company: if someone is unwilling/ignore to share or help new people, and boss doesn't take it seriously, no one will want to spend their time on such things.
We don't necessarily need such a boss, but we do need a common sense to agree that sharing and to be helpful is critical to the projects.
A few things could be done in future to reduce workloads of smaller projects.
Take GIT and Linux kernel development. It has allowed drivers to know what does not work. Yet it not helpful to correcting api changes issues.
http://coccinelle.lip6.fr/ Provides a way to create like macros to do API changes. Ok the produced programs from it are like beta/alpha quality due to possible unknown effects.
Lot of old KDE programs are kinda in a wobble due to api differences between QT3 and QT4.
Changing api's takes lots of resources small projects with few and many submits apart don't have the resource for.
So no we are not doing enough to ensure that project don't start to wobble in the first place due to lack of resources caused by technical changes. But the big important thing is items like Coccinelle are fairly new as well. So the tools to make small project life simple at API migration did not exist. Times have changed lets move with them.
The same cannot migrate between API's causes lot of duplication in Linux installs.
Items like K3B is resources issue. We have to accept that we will never have enough resources to maintain everything. Yet the more scripted so developers can maintain and update more quickly the better.
K3B interface has been a manual rewrite there are no assistance transformation scripts from QT3 to QT4.
It is not just that a project crushed and burned either. I like to call dead open source projects as being in the open source scrapyard. An interested enough developer can sometimes recover a project from there. Again how recoverable a project is lines up directly to how much work a developer has to do so it works again.
In my eyes we need a project who job is to provide resources to assist API migrations and scripts for patching code that will not build with current day compilers due to syntax items not function. This will one prevent projects dieing. Number two if they do give a better chance of them coming back.
@oiaohm: "there are no assistance transformation scripts from QT3 to QT4."
there are see http://qt.nokia.com/doc/4.0/porting4.html (using the 4.0 docs to show it's always been there). there are also scripts that help go from KDE3 to KDE4 in kdesdk.
they are not perfect, and there are some areas they really can't do a lot to help with, but they do take out a lot of the drudgework.
there is still the need for a LOT of work in such porting efforts, this is true, but there isn't a lack of scripts as you assert.
"Again how recoverable a project is lines up directly to how much work a developer has to do so it works again."
agreed; there are a few things that can be done to ensure that's how things go. one is to write maintainable code in the first place, but a very important (and more relevant to your comment) one is to AVOID changes in the core APIs.
the next versions of Qt's and KDE's libraries are both set to be evolutionary in their API rather than the "break it all!" approach that Qt 4.0 brought with it. this is not accidental, but rather something that Qt developers learned the hard way with Qt 4 :)
Analysis of VCS commits and statistics could also be helpful to identify language translation projects that need help (either in need of more manpower or even having an inactive maintainer).
Aaron, thanks for this wonderful post that I've kept thinking about for the last days and will continue to.
Post a Comment