| [News.eclipse.foundation] Re: E4 / SWT 4.0 |
|
Mauro, Comments below. Mauro Molinari wrote: Hello to all.Personally I think Eclipse is still in great shape and that Web 2.0 thing is yet another over-hyped trend that's likely to turn out much different than might appear on the surface. I definitely agree that in general we ought to fix our problems before we move on to create new ones with new features. I would have said I agree 100%, and those aren't idle words, but rather ones I personally back up with actions. That being said though, I think Boris makes a strong argument that also bears consideration. If you look at the huge list of bugzillas, you do get a sense of diminishing returns on the bug fixing theme. Folks could be busy for a long time just polishing Eclipse without doing anything truly innovative or exciting. Will a big community form to help with the polishing effort? I kind of doubt that since it hasn't so far. Can the polishing effort go on forever without more community involvement? I kind of doubt that too. How polished is polished enough? When can the folks who innovated to created Eclipse do something truly innovative and new again? I find it frustrating the way many groups handle their bugzillas. How a project handles newsgroup questions and bugzilla reports is a true reflection of their attitude to the community. No other words will speak louder than the actions taken on these two things. Sure people might actually have an attitude much different than what appears, but the community can, will, and ought to judge based on actions. I think the JDT folks are generally doing the best they can with the resource available... Such speedy service! :-P I've often noticed that if I deal with something in a speedy way, that the speed in and of itself will be judged as either good or bad depending on whether the person liked what I did. If they don't like it, they consider the speed to make the bad result even more offensive; if they did like it, they consider the speed to make the good result even better. So ask yourself, would you have felt better if it took and hour, a day or a week? If not, then it's not the ten minutes that bothered you but the wontfix. Lets consider this whole issue in the context of the JDT bugzilla backlog https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&am p;chfieldvalue=&product=JDT&component=UI&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&newqueryname=&order=Reuse%252Bsame%252Bsort%252Bas%252Blast%252BtimeScanning through it, this one caught my attention, being bold and in bright red https://bugs.eclipse.org/bugs/show_bug.cgi?id=235799I though, let me try what they describe. It worked fine. Then I looked more closely at the stack trace and figured, I wonder what I'd need to do to have a class file that doesn't end in .class? That seems unrelated to the scenario described. It makes we wonder why this bugzilla is still open. The fact that there are more than 1200 and that to revisit each one for even just a minute would take 20 hours makes the reason a little more clear. Of course each user just figures their bug report is a small thing and expects it to be treated that way, but let's be realistic and consider all the human beings involved. If the JDT project is unlikely ever to have resource to build a new properties editor with cool new features, isn't it reasonable that they make that clear by returning the request? I suppose leaving it open and marking it as something that won't happen without a contribution is more user friendly. Personally I tend to return things only if I'd actually not consider it a good thing even if someone else contributed it and supported it. An ever growing list is also in and of itself something that takes a quite a lot of time and effort to manage. Consider how long it would take to eliminate everything in the above list! After complaining, I got it to be reopened, but I was left with very scarce hope...Ah, those ever useful complaints. :-P I'm not saying this in you case, but some folks figure the more bitterly they complain the more likely someone will work hard to silence them. Don't take that comment personally, since I think in your case that really doesn't apply. In fact, I'm impressed that you took the time to write such a carefully considered response. I wonder if at the time you wrote your report if you had a good sense of exactly how big the wish list already was? I know how frustrating it is to watch a wish list grow faster than one can ever hope to shrink it... I think you interpret the rejection of your wish list item as a value judgment on you personally. A friend at university has a line at the bottom of each note that said "Never attribute to malice that which is adequately explained by stupidity." I'm not saying anyone did anything stupid. The more important thing is to be careful about attributing motivations to actions, especially negative ones... Probably by the time you take the union of the ones that various different people consider important, you'd end up with the conclusion that the vast majority must be done. Many people will complain that Eclipse is too complex. The solution is always to simplify it by adding more features and capabilities. But of course having more ways to do something, also generates even more complexity... Perhaps a major aspect of the problem with huge web application development is the underlying framework, JEE; it's difficult to make a silk purse out of this sow's ear. OSGi is certainly a far simpler container model. I manage a workspace that normally consists of almost 200 projects with many millions of lines of code. OSGi's classpath management makes classpath setup a non-issue and the applications always just run... That's just 3.5 or 3.6. It's relative small incremental improvements on what we have today. The 3.x effort will continue and if the community gets involved with that as well, we should expect to see a solid and improved 3.x stream as well as an exciting innovative 4.x stream to lead us into a long and bright future. Instead, I read something about the idea to push towards the direction of making e4 usable in a web browser... this sounds dreadful to me, honestly. Unless you plan to release e4 within some (many?) YEARS and with a LOT of care...Personally I wish the web thing was not so over hyped. Far too many people look at e4 and think, it's primarily about getting onto the web. That's only one aspect and as far as I could tell from the summit, that's not the primary aspect nor the central theme. We must be doing something wrong if folks mostly think it's just a web thing... Absolutely. You can't have too much of this. It's also the kind of thing that the community itself can help produce. Imagine if each developer who took the painful steps to get started helped add a little more information to the wiki to help out the next person. That would really help stimulate the community. The project leaders need to lead the way, but the community needs to take actions as well. For instance, in my specific case, my main difficulty to start contributing would be about the fact that I don't know SWT. So, maybe a "learning path" to follow would be very precious.Eclipse is so very big and so daunting when getting started. I'm not sure one could reasonably expect to contribute to a JDT UI tool without a lot of background. There are whole books on the subject of SWT, so just that is a big investment. It seems to me that no matter what we do, it will never be easy for folks to contribute to JDT. Only the dedicated will succeed. But also some high-level technical documents to make new developers understand how the all thing works: those things you should (must?) understand before diving into the detail of the code you want to fix or enhance...When I consider this issue closer to home, I stop and think about how many times folks have complained about the need for more and better documentation about EMF. I end up listening until I get frustrated but being ultra diplomatic and wanting to avoid controversy I keep silent. Oh wait, that's an idealized version of me! :-P I point out somewhat bitterly that I have a tiny team of people who just can't keep up. No matter what we do, someone will complain it's not enough. If I have my two developers spending 3 person years working on a book, you can be guaranteed that I'm taking documentation seriously, and that it's happening at the expense of development work. Of course I fully expect to get complaints that the book costs money and what horrible exploiters of open source we are to dare to charge money for a book that ought to be free. And that's on top of complaints that the wish list isn't all getting done. Oh well, if folks aren't complaining about your project then either your work is be done or more likely your work is irrelevant, because relevant work is never done. So absolutely we need better documentation. We need better getting started information and better website organization to make it easier to find. We need a constant stream of more and better. But please consider the extent to which the community itself can help with these. Repeating the same message over and over will not help. I can't stand to hear complaints about EMF documentation anymore, so folks might not like my reaction, but let them walk in our shoes for a few miles... To me, this is the fundamental problem that needs to be fixed as much as the very real barriers to entry. The barriers all have obvious solutions and it's just a matter of taking action. But the free riders in the world (not you, but your organization that profits and benefits while giving nothing in return, even to the point of prevent you) will be the death knell of open source... So, I try to give help by contributing through newsgroups and bugzilla, sharing my own experience, so maybe some good ideas for Eclipse could be taken (or at least evaluated) from people like Eric and me (and many others). I know it's very hard to find valuable ideas among hundreds of wish-lists (often written without too much thinking), but I believe this should be part of the game.I often tell people, we don't have a shortage of good ideas, we have a shortage of people who can turn the good ideas into actions and results. It's incredibly frustrating when good ideas can't be turned into actions. The more good ideas there are, the more frustrating it is. So yes, we appreciate your good ideas and we are frustrated by them. We even have our own good ideas that frustrate us... It was a good one. I hope nothing I've said makes you feel bad. I know from the tone of your note that you have nothing but the best of intentions and of course community values good intentions. To me I read all this stuff and think to myself, the solutions are so obvious. We all know what needs to happen. So why doesn't it just happen? Because there aren't enough people to make it all actually happen. Good people like you are not just hampered by lack of getting-started information but also by barriers in your own organization... Imagine how happy the JDT folks would be if they had twice as many people working on JDT. Imagine how much value the rest of the world would derive from that effort. I'm absolutely sure that an hour invested in JDT pays for itself in improved productivity a hundred fold or more. But how do we convince people to invest in JDT when they can't measure their return on investment in hard currency? How do we convince them they should even bother rather than hope someone else will do it for free? These are the truly difficult problems that I don't know how to solve. They won't be solved, I believe, simply by lowering barriers to entry on our side...
|