Here is how I intend to respond to a private email that I received today, about a bug that was filed yesterday. How would you respond in a similar situation?
Hi [X],
Thank you for reporting a problem with Eclipse. But - and maybe it's just me - the private email you sent today comes across as demanding. You are asking us to help you quickly, without investing time on your side to make the problem easy to reproduce for us. I understand that it's frustrating when things don't work the way you think they should work. However, remember that Eclipse is free software, and please consider if you are not already getting a lot more than your money's worth.
So, in your own best interest, could you please use Bugzilla (that way, everybody interested in the issue can follow the discussion), and help us reproduce the problem with as little time investment as possible on our side? I have already asked twice, on the bug, but I will ask one more time: Please attach [a file that will allow us to reproduce the issue] to the bug. I would expect to be able to use [list of steps] to get the source code into my Eclipse. Before uploading the attachment, it wouldn't hurt if you tried the import operation on a fresh workspace to confirm that we will be able to just run it. By the way, the recommended way to produce the file to attach would be [list of steps].
Thanks,
Boris
Wednesday, February 03, 2010
Monday, January 18, 2010
Eclipse Labs
Mike wrote on his blog back in December that the Eclipse Foundation is "looking at creating an Eclipse Foundation affiliated forge where projects which are based on the Eclipse platform, but are not interested in hosting at eclipse.org can run their projects."
Click on the image, but it's not an official eclipse.org Eclipse Lab!
Admittedly, this announcement was a little vague, most probably because this is part of the Eclipse Foundation's program plan for 2010, and lots of details still need to be worked out. In the comment section, Mike wrote that he is "expecting to announce this at EclipseCon in March." This tells me that there are at least a few open questions that need to be answered, or negotiations that need to take place, or else this could have been announced in detail already.
As a committer representative on the Eclipse Board of Directors, I know a little bit more (but not too much) about this, but Board meetings are confidential, for good reasons - otherwise Mike wouldn't be able to openly discuss his vision and plans with the Board, which is one of the main functions of the Board of Directors.
So let me just go through what everyone does know (or can know) so far, based on what Mike has written in his blog posting and in the corresponding comment section, with a little bit of added interpretation and speculation just because it's rumour season:
Yet another non-eclipse.org Lab, click on the image!
Eventually, it will become important to handle the transition between Eclipse Labs and eclipse.org. For example, a project at Eclipse Labs may want to move to eclipse.org at a later point in time when it is more mature. Anything that can be done to ease this transition will be to the benefit of Eclipse, and it may make sense that projects make the transition in several steps. For example, an Eclipse project may want to depend on software from an Eclipse Labs project, at which point an IP review will have to be conducted on the eclipse.org side. Or a project at Eclipse Labs may want to become an incubating eclipse.org project, which would mean adopting the Eclipse processes but not necessarily a full IP review until the project makes a release at eclipse.org.
I hope this was useful information^H^H^H^H^H^H^H speculation. ;-)
P.S. I have used some words of Miles Parker's excellent blog post for the reasons why you would choose Eclipse Labs vs. eclipse.org as the place to run an open source project.
Click on the image, but it's not an official eclipse.org Eclipse Lab!
Admittedly, this announcement was a little vague, most probably because this is part of the Eclipse Foundation's program plan for 2010, and lots of details still need to be worked out. In the comment section, Mike wrote that he is "expecting to announce this at EclipseCon in March." This tells me that there are at least a few open questions that need to be answered, or negotiations that need to take place, or else this could have been announced in detail already.
As a committer representative on the Eclipse Board of Directors, I know a little bit more (but not too much) about this, but Board meetings are confidential, for good reasons - otherwise Mike wouldn't be able to openly discuss his vision and plans with the Board, which is one of the main functions of the Board of Directors.
So let me just go through what everyone does know (or can know) so far, based on what Mike has written in his blog posting and in the corresponding comment section, with a little bit of added interpretation and speculation just because it's rumour season:
- "An Eclipse Foundation affiliated forge where projects ... can [be] run" sounds to me like a concrete place for project hosting, i.e. a URL like eclipselabs.org. It turns out that this domain has been registered in December by the Eclipse Foundation. My hope is that soon, eclipselabs.org can be listed in the "Specific requirements" section of this wikipedia article on software hosting facilities, as a specialized software forge for Eclipse-related open source projects.
- This is for projects that "are not interested in hosting at eclipse.org", and "Eclipse Labs will hopefully over time form a powerful complement to the projects hosted at Eclipse.": Sounds to me like existing projects at eclipse.org will not be affected. Instead, I hope, this will be attractive by pulling together open source projects that currently would have to be started or hosted elsewhere (e.g. at Sourceforge, Github, Google Code, ...).
- "There will obviously be some constraints (e.g. only Eclipse Foundation projects can use the org.eclipse namespace, and be part of the release train)": Sounds like there will be a clear distinction between Eclipse projects on one side and Eclipse Labs projects on the other side. There are many good reasons why you may want to run a project at a less restrictive software forge, for example:
- minimal overhead to get started
- use whatever process you like for releases, adding and removing committers, adding dependencies to other software, etc
- no mandatory IP review
- benefit from the Eclipse brand and Eclipse marketing efforts
- use the same meritocratic principles and practices as every other project, making it easy to build trust across projects
- approved IP cleanliness, to ease adoption by large organizations and governments
Yet another non-eclipse.org Lab, click on the image!
Eventually, it will become important to handle the transition between Eclipse Labs and eclipse.org. For example, a project at Eclipse Labs may want to move to eclipse.org at a later point in time when it is more mature. Anything that can be done to ease this transition will be to the benefit of Eclipse, and it may make sense that projects make the transition in several steps. For example, an Eclipse project may want to depend on software from an Eclipse Labs project, at which point an IP review will have to be conducted on the eclipse.org side. Or a project at Eclipse Labs may want to become an incubating eclipse.org project, which would mean adopting the Eclipse processes but not necessarily a full IP review until the project makes a release at eclipse.org.
I hope this was useful information^H^H^H^H^H^H^H speculation. ;-)
P.S. I have used some words of Miles Parker's excellent blog post for the reasons why you would choose Eclipse Labs vs. eclipse.org as the place to run an open source project.
Monday, November 30, 2009
Step Up or Shut Up
So we're at it again, sigh...
It seems that the same people are commiserating the tragedy of the commons at Eclipse, at regular intervals, over and over again. Complaining is not a very good way to get what you want - I know one thing or the other about this as a father of three ;-). Complaining may work once or twice, but if you keep repeating the behaviour, people will stop listening to you.
Normally, I would just sit these things out but this time I feel compelled to add some oil to the fire:
Now for the definition of "help", I would recommend that you focus on a narrow enough subpart so that you can follow along for the next little while (like, for example, a year). Spend some time on the newsgroup/forum, read and understand the code, watch incoming bugs, find out who is the current maintainer, contact them and let them know you are interested in helping, and so on. This does not have to take a lot of time, but there is probably a lower limit of perhaps one or two hours per week. Convince your manager that doing this is important for the company, since they have software products that rely on the component or feature in question. You can also argue that investing a little time will help improve your skills. In fact, the latter point is a motivation that works even if you don't have an employer, if for example you are a student, or self-employed, or just not employed at the moment.
What's in it for you? Potentially fame, when your name starts appearing in Eclipse source file headers, or in IP logs (which by the way are another good way to measure project diversity). You'll learn about "the eclipse way", the development process that allows us to ship on time and with quality, every year, for the last nine years. Finally, you'll have the warm fuzzy feeling that comes with ensuring the future of a core piece of technology that is being used by millions of users. Of course, you could help an Apache project, or Linux, or Mozilla, or on SourceForge or GitHub, but chances are (if you are reading this on Planet Eclipse) that your job indirectly depends on the future of Eclipse - not Apache, Linux, or Mozilla.
(Image © Zen Sutherland, http://www.flickr.com/photos/zen/241745451/sizes/o/, licensed under Creative Commons by-nc-sa 2.0)
1 You have to read between the lines for this, not sure if newer board minutes have more detail. The June board minutes state: "In discussing the strategic goals of the Eclipse Foundation, the Board indicated that diversity on e4 was of strategic importance to the Eclipse Foundation. In addition, it was important to continue to grow a diversified revenue model. As a result of the discussion, these two concepts were introduced into the Strategic Goals of the Foundation." Since a strategic goal that focuses solely on e4 seems a little odd, this has been generalized to apply not only to e4 but to other platform-y projects at Eclipse, I believe the wording is "Ensure adequate resources are invested in the core technology platform".
It seems that the same people are commiserating the tragedy of the commons at Eclipse, at regular intervals, over and over again. Complaining is not a very good way to get what you want - I know one thing or the other about this as a father of three ;-). Complaining may work once or twice, but if you keep repeating the behaviour, people will stop listening to you.
Normally, I would just sit these things out but this time I feel compelled to add some oil to the fire:
- Diversity on e4: It is very easy to become a committer on e4 - that's one of the purposes of an incubator. Basically, all it takes is a believable email to e4-dev@eclipse.org that you would like to work on something in the context of e4, and you will be nominated as a committer. Still, IBM has most of the commits in the e4 project. Who do you think is to blame for that? IBM? Because it is investing in a project whose goal it is to bring innovation back into the Eclipse Platform?
- Diversity on the Eclipse Platform: The last example I know of where people or companies wanted to contribute to the Platform but were not received with open arms is from about two years ago, when developers from WindRiver complained that their contributions did not make it into the Debug and Resources components. Where are we today? Both these components have committers from WindRiver, and Martin Oberhuber, a WindRiver employee, is a member of the Eclipse PMC. By the way, are those new committers contributing to those Eclipse Platform components full-time? No. (Just to be clear - I don't want to pick on WindRiver at all: I think it's great that they are in fact investing in the Eclipse Platform, even if it's just a little, when many other companies that benefit from the Platform don't invest anything at all.)
So, if you'd like to contribute to the Eclipse Platform on an ongoing basis, and feel that you are not "let in", please speak up so that we can fix the problem. I am pretty sure that this problem doesn't exist, and that instead the problem is more on the side of those who decide not to contribute, than it is on the side of the existing committers. - Forking: As of lately, this is easier than ever. Eclipse projects are now mirrored as Git repositories, starting with those that are using CVS for the main development. Knock yourself out, and don't forget to make the source available if you are creating derivative works. However, I don't think this is going to be a solution to the "tragedy of the commons" problem. I do hope this will make it easier to create private branches when your development timeline does not align with the one at eclipse.org, and you need to just fix something now. I also hope it will make it easier for contributors in general to provide patches that don't go stale.
By the way, the mirroring as Git repositories happened thanks to Denis and the webmasters at Eclipse, thanks to Shawn Pearce and the EGit and JGit team, and to a small amount thanks to Mike Milinkovich, the Eclipse Board of Directors, and your committer representatives on the board. If you are interested in details, see the bug Chris Aniszczyk opened on June 17th just after Doug Gaff and I were able to convince Mike Milinkovich and the Board (minutes) that it was important to make this happen. - The Foundation is doing concrete work to help: Mike has mentioned some of the things that are planned for 2010 on his blog: "a branded Eclipse forge hosted elsewhere (e.g. IP Policy free), Git support for the whole community and major improvements in hosted build and test at eclipse.org." I believe that the Eclipse Foundation staff, and Mike Milinkovich as the executive director, are doing a pretty good job, and they are also actively trying to get more involvement by other companies and individuals for core projects at Eclipse. The board of directors even made this a strategic goal for the Eclipse Foundation this past June1.
Now for the definition of "help", I would recommend that you focus on a narrow enough subpart so that you can follow along for the next little while (like, for example, a year). Spend some time on the newsgroup/forum, read and understand the code, watch incoming bugs, find out who is the current maintainer, contact them and let them know you are interested in helping, and so on. This does not have to take a lot of time, but there is probably a lower limit of perhaps one or two hours per week. Convince your manager that doing this is important for the company, since they have software products that rely on the component or feature in question. You can also argue that investing a little time will help improve your skills. In fact, the latter point is a motivation that works even if you don't have an employer, if for example you are a student, or self-employed, or just not employed at the moment.
What's in it for you? Potentially fame, when your name starts appearing in Eclipse source file headers, or in IP logs (which by the way are another good way to measure project diversity). You'll learn about "the eclipse way", the development process that allows us to ship on time and with quality, every year, for the last nine years. Finally, you'll have the warm fuzzy feeling that comes with ensuring the future of a core piece of technology that is being used by millions of users. Of course, you could help an Apache project, or Linux, or Mozilla, or on SourceForge or GitHub, but chances are (if you are reading this on Planet Eclipse) that your job indirectly depends on the future of Eclipse - not Apache, Linux, or Mozilla.
(Image © Zen Sutherland, http://www.flickr.com/photos/zen/241745451/sizes/o/, licensed under Creative Commons by-nc-sa 2.0)
1 You have to read between the lines for this, not sure if newer board minutes have more detail. The June board minutes state: "In discussing the strategic goals of the Eclipse Foundation, the Board indicated that diversity on e4 was of strategic importance to the Eclipse Foundation. In addition, it was important to continue to grow a diversified revenue model. As a result of the discussion, these two concepts were introduced into the Strategic Goals of the Foundation." Since a strategic goal that focuses solely on e4 seems a little odd, this has been generalized to apply not only to e4 but to other platform-y projects at Eclipse, I believe the wording is "Ensure adequate resources are invested in the core technology platform".
Subscribe to:
Posts (Atom)
Posts
