So how do you tell whether a project is truly open or not? Well one way I use is to take a look at the developer mailing list for that project. The volume of traffic there is a good judge not only of the activity of the project but how well the developers communicate with the community.
Now it's much better to look at the archives. I remember signing up to the gcc developers list for a few minutes when 20 or so message jumped in and I quickly unsubscribed. gcc is a massively active project that has contributors that love to communicate. Good or bad, it is what it is, an open project.
And I guess there should be some metric you could calculate to measure the openness, something like number of mail messages versus lines of code committed. If that number is low, you have a closed project, if that number is high then it's open. Not sure if that makes the most sense but then, I wonder that about most metrics anyway.
At any rate, I decided to take a look at a number of *-dev mailing list archives at eclipse.org and see how many pages of items there were in the last year. If you get a chance go check out the archive for the cdt-dev mailing list. I'm proud to say there we're 26 pages of items in the last year. We score pretty high. Mind you being a diverse set of contributors, we have to communicate via the list. It's the only way to get the message out to everyone who needs it.
So when I talk about a project being truly open, I mean the daily business of that project is done in the open on a publicly accessible forum. And if you fill up the subscribers mailboxes with good information, even better.
I'll also mention a couple well publicized and organized face to face meetings of the CDT community each year plus regular conference calls. Anyone can attend and talk about their needs and objectives and get an open reception.
ReplyDeleteDoug, there are certainly many metrics that can be applied as measurements. Each will yield a figure that assesses one aspect of a complex multi-faceted problem.
ReplyDeleteIn general when pointing out faults in others, I like to proceed with caution based on the principle that "people who live in glass houses ought not to throw bricks." I know that my own personal faults are many and that the faults of others typically pale in comparison.
So at the risk of departing from diplomatic sensibilities, please consider this tiny pebble that might be hurled toward your glass house: How easy is it for a CDT user to find the CDT newsgroup? I've noticed that it's not as easy as it might be and I've raised that as an issue; see 206923. Many a CDT newcomer has needed help with this issue, and after almost five months, the need for a direct link to the CDT newsgroup from the CDT home page remains an issue.
It's of course a tiny issue. And as the Dutch expression goes, I ought to spend my effort removing the 2 by 4 from by own eye before focusing on the sliver in yours...
Thanks Ed. Point taken. But it's not because we're a closed community. It's because we don't have any one available to manage our web site to make it easier to find. The fact is it is there, people have found it, and it is fairly active.
ReplyDeleteNo one to manage your website? Pshaw.
ReplyDeletePort it to the wiki and let others do it for you! It worked for PDT (who despite being a web tooling project ironically don't update their website often enough) -- it can work for you.
Need to recruit people to do the updates? Drop into #eclipse and help out with CDT questions, then politely ask people to post these answers into your wiki-based FAQ.
Trust me, it works.
I did not realize that there were so many degrees of openness that could be compared and measured!
ReplyDeleteDoug, from my experiences with the cdt, I would judge the cdt as an open project but I have to agree to Ed that somtimes it is quite hard to find the information you need. In my case I missed two important source of information for a long time, the newsgroup and the bugzilla.
ReplyDeleteA total other story is when you try to get involved in the in the real work. I think there is still at least one bugreport from the time when I started working on c++ refactoring with now response at all. Probably it is normal that new guys in a community have to show its skills and commitment to the project first. But no response at all is not boosting the motivation to do more.
If lack of help makes a project closed, then the CDT is less open than others. We have a wiki. The CDT web site points there. The CDT web site also has a link to bugzilla and the newsgroups.
ReplyDeleteThere's still more looking to find information once you get there, and maybe it isn't obvious enough. But that's where some time spend on fixing up the web site is needed. But like everything else in the CDT, that needs contributions.
Doug, I think CDT is an excellent example of an open project. I don't think it would have thrived in its present form without your personal efforts to ensure that's the case.
ReplyDeleteI was commenting in a contrary way to provide a balance lest people start to think simplistically that there is one simple measure for openness. I also wanted to drive home the point of just how easily all good things can be cast into doubt. And finally, to be honest, I was being a little defensive. The EMF and EMFT mailing lists aren't much used, so I'd not be happy to see the argument that my projects are closed as a result of that measure alone. I encourage folks to make announcements and have discussions on the newsgroup as well as to blog as a way to share their exciting ideas. I think EMF is a pretty open project, and still I'm sure this can be improved.
Clearly your last comment about lack of help making something closed is exactly the predicament of the platform team. I think it will take quite a bit more than posting notes on their mailing list to put a dent in that problem. But it sure wouldn't hurt. Part of the issue is that the problem is kind of self perpetuating. As long as the people you work with sit next door or are at your finger tips on a chat window, the compelling reason to use a mailing list is simply absent.