Community
Participate
Working Groups
This bug is to discuss the proposed Custom Delivery Installer Program. This progam is outlined here: http://www.eclipse.org/membership/special_programs/custom-delivery-installer-program.php Please attach comments to the bug. Also note that it is the height of summer holidays, so expect delays in the conversation (from me at least :) - Don
This seems like a great initiative!
Overall this initiative seems like a nice enhancement for the Eclipse user community to help them more easily access the entire ecosystem of Eclipse-based software. However, restricting participation to only strategic members seems like a sudden and arbitrary change in policy when currently all members can participate in the "Member Distros" program at Eclipse (http://www.eclipse.org/downloads/distros.php) . The Eclipse ecosystem currently provides the Eclipse user community 9 unique options and only a few of those are from strategic members. As an elected representative of the Solutions Member community I'd strongly prefer to leave participation open to all members of the Eclipse ecosystem so we can ensure we maximize participation in this program. Only through openness will we be able to ensure the Eclipse user community has access to as many distribution options as possible and are not arbitrarily restricted to just what a few large companies want them to see. Eclipse users: Would you like as many options as possible so you can choose what works best for you? Solutions Members: Would you like to be able to participate as well?
This is much-needed and should very much improve the end-user experience with our site.
Brilliant! I just came across Bjorn's blog post about this on Planet Eclipse and have to say that this is a very nice way of showing real tangible value of membership for Strategic Members. If this takes off, I can also see a benefit of putting a facility into Eclipse similar to what Firefox has that allows users to discover and install new plugins. There too, you can think of ways to tie listing to membership level.
Todd raises a good point though. For which type of member does this provide value? Strategic? Solution? Committer? And what's the return on investment for each type of member? In terms of users, I imagine that the less restricted the more value. But of course users don't necessarily contribute anything in return for what they get.
(In reply to comment #5) Ed, I'm not following your question: > For which type of member does this provide value? The program is (explicitly) an effort to implement the Board's directive to "increase the value of strategic membership". The Board's vote on that directive was unanimous. > In terms of users, I imagine that the less restricted the more value. Not necessarily; consider the case where every Eclipse member was part of the wizard. Then the final page would have hundreds and hundreds of options to the point where it would basically be useless to the users. On the other hand, having just a single member participating would also not provide users with a good experience (too few choices). Eclipse has has 21 strategic members so if we expect about half of them to participate, users will then have a little less than a dozen options: a good number to provide additional benefit to the users without the overwhelming complexity of too many choices. Of course, nothing about this wizard restricts anybody from installing Eclipse features from any other source, e.g., from the members distros, from EPIC, from the normal download pages, from commercial products, etc. This is not a replacement for any of those and we intend to continue all those channels as well. This is simply a way to go forward with the three stated goals: provide another download channel for users, increase the visibility of some Eclipse projects (except other 'increase visibility' efforts over the next year), and provide more value for the strategic members (those companies who finance a majority of Eclipse).
As a point of reference, the "Featured Member Logos" and "Strategic Member Ads" on eclipse.org and eclipse.org/downloads are exclusively for Strategic Members. This was done at the request of the Advertising working group at the request of the board to create programs that were of particularly high value to Strategic Members to increase the value proposition for Organizations to become strategic members. - Don
Bjorn, You followed my question exactly. It was simply a rephrasing of the issue Todd raised. It's been made clear now that this program, which looks like it would be valuable to users, is primarily focused on providing value to strategic members with the benefit to users being important but secondary. Probably it doesn't sound so nice worded that way. :-P I make that comment simply because it's clear that the content from which users can choose will be filtered not with a focus on what's most needed by the users---who knows how we would decide that anyway---but rather on what's made available by strategics. Of course there will be a focus on usability, so I'm not implying we won't produce something valuable for the users, just that this alone isn't the central focus. All that is fine. In fact, I can see that this is indeed something that will provide value to strategics by making what they supply more readily accessible and hence this will act as an incentive to become a strategic member. Maybe Todd will even decide to become a strategic member as a result. That would certainly prove the point. :-P
I've already stated my position in comment #2 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=243523#c2) so I'll simply be responding to statements others have made below. >From Bjorn (https://bugs.eclipse.org/bugs/show_bug.cgi?id=243523#c6): >The program is (explicitly) an effort to implement the >Board's directive to "increase the value of strategic membership". >The Board's vote on that directive was unanimous. That is correct; the board did vote unanimously on this topic. I'm actually on the board and participated in this vote. Obviously then the presence of this vote cannot be used to justify the implementation of this specific program when one of the people that voted for "increasing the value of strategic membership" is disagreeing to one of the specific points of the implementation. Therefore, citing a "unanimous board vote" is an invalid defense point for this proposed program. >From Bjorn (https://bugs.eclipse.org/bugs/show_bug.cgi?id=243523#c6): >Not necessarily; consider the case where every Eclipse member >was part of the wizard. Then the final page would have >hundreds and hundreds of options... This is a transparent attempt at a "reductio ad absurdum" argument. To demonstrate how ludicrous this statement is I'll simply point out (as I did in my original comment) that participation in the "Member Distros" program at Eclipse is open to all members and has been for over two years. It has precisely 9 participants from the entire Eclipse ecosystem. And, that program is arguably easier to participate in than this proposed one will be since it requires less development and integration. So, spreading fear about the possibilities of "hundreds and hundreds of options" is also an invalid defense point for this proposed program. >From Bjorn (https://bugs.eclipse.org/bugs/show_bug.cgi?id=243523#c6): > ...the three stated goals: provide another download channel for users, Excellent. I'm sure Eclipse users would appreciate several options so they can determine for themselves what works best for them. This is exactly why I favor open participation in the proposed program rather than arbitrarily limiting it. >...increase the visibility of some Eclipse projects >(except other 'increase visibility' efforts over the next year), I can see how this will be beneficial. Eclipse has a lot of great projects in so many areas that it's hard to keep up. If this helps publicize them better, then I'm all for it. >and provide more value for the strategic members >(those companies who finance a majority of Eclipse) I also want to provide more value to strategic members at Eclipse. That's specifically why I volunteered my time to work on the board committee that created the recommendations on how to do exactly that and which Donald references here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=243523#c7 And, as Donald correctly stated, the "Featured Member Logos" and "Strategic Member Ads" were two of the policy changes our committee recommended. However, this proposed policy was not part of our recommendations and is simply something the Foundation employees created on their own and without our committee's input. Therefore, citing our committee's work on this topic is an invalid defense point for this proposed program. But there is a valid and important point here. The Foundation does need to increase value to those members that "finance a majority of Eclipse", as they've been called. And those companies are the large ones that contribute at (or very near) the yearly cap of $250K for their Eclipse membership. You can look at the Board of Directors list and see that they are specifically: IBM, Borland, CA, Intel, SAP, Nokia, Oracle, Sybase, and Motorola (if I accidentally left anyone out I apologize). Those are the companies from which the Eclipse Foundation gets the majority of its annual funding. We should all be thankful that they choose to renew their commitment to Eclipse year after year. Unfortunately, "trying to add value" for someone isn't the same as actually "adding value" for them since "value" is based on the receiver's perception, not the giver's. And, since this specific attempt at adding value does have some negative implications for everyone except strategic members, I think we really need to hear from some of these specific strategic representatives on this topic. For example: Does this proposed program enhance the value of Eclipse membership for their organizations? Does it make their annual financial commitment to Eclipse easier to justify? And finally, does limiting participation to "strategics only" create significantly more value for them than if the program were open? The purpose of this bug report is to engender discussion on changes to this proposed policy by those that will be affected by it. In legal circles that's called "standing" ( http://en.wikipedia.org/wiki/Standing_(law) ). Those with "standing" in this discussion are: the Eclipse user community, the Strategic Members of the Eclipse Foundation, and the non-strategic members of the Eclipse Foundation. Let's be sure we hear from all these parties so we can create a program that maximizes benefit for the entire Eclipse community.
(In reply to comment #8) > ... primarily focused on ... That's not the way I read it, but maybe I was wrong. I thought it read as if it had three fairly equal goals with maybe the focus on the 'users' being more than on 'member value' being more than on 'project visibility'. (In reply to comment #9) > I'm actually on the board ... > this proposed policy was not part of our recommendations ... I'm sorry, but I'm not on the Board and I'm not privy to the conversations that happen at the Board. All we receive are the directives to be implemented e.g. http://dev.eclipse.org/mhonarc/lists/eclipse.org-project-leadership/msg00011.html We (Foundation staff) are always working hard to try to implement the directions the Board provides. If we have misunderstood the Board's directions, we will certainly ask for clarification and then work to correct our errors. > This is a transparent attempt at a "reductio ad absurdum" argument. No, sorry Todd, it's not a transparent or ridiculous or reductio ad absurdum argument. It's actually a reasonable argument about user interface design. Now one could, and you do, make the counter argument that the magic "best" number of participants is larger than we could expect by limiting the wizard to Strategic Members. That's a reasonable argument, but it does not eliminate the "potential for too many participants" argument. Consider EPIC (http://www.eclipseplugincentral.com/): in my opinion, EPIC is mostly useless precisely because it has too much disorganized stuff. When I want to find a plug-in, I (personally), don't use EPIC. That's the situation I (personally) don't want to see vis a vis the wizard. That's my argument. > ... this specific attempt at adding value does have > some negative implications for everyone except strategic members, ... That (negative implications for others) wasn't the intent (at least I don't think it was). Please explain how it provides negative value to the users, committers, and the rest of the Eclipse members?
In response to comment #9: >If we have misunderstood the Board's directions, >we will certainly ask for clarification and then >work to correct our errors. Excellent. I suggest you begin that process. >That's a reasonable argument, but it does not eliminate the >"potential for too many participants" argument There will always be a "potential for too many participants" no matter what is done. My point is that this is highly unlikely since the current policy with Member Distros has been open for over 2 years and has nine participants. Likening that to EPIC is not a valid analogy since anyone in the world may create an Eclipse plugin and post it on EPIC. The number of possible participants in this proposed program will be exactly the same as it is for the Member Distros program which has so far garnered 9 participants. I think anyone can see that this is a much more valid comparison. >Please explain how it provides negative value to the users, >committers, and the rest of the Eclipse members? Certainly. By limiting participation to only strategic members you will reduce the number of Eclipse member companies participating in the program (which you've already stated is the goal) and that will decrease the range of selection that end users have when determining how they'd like their Eclipse software augmented, packaged, and distributed to them. Limiting a user's selection is certainly a negative. As for committers, I believe it's effectively neutral for them, as far as I can tell, except that they are also Eclipse users as well so the reduced selection argument also applies. Negative value to the non-strategic members is created simply because they are barred from participating in a program that some of them might find beneficial. For example, in the Member Distros program most of the participants are not strategic members of the Foundation. It's reasonable to assume that these same companies might find this new program interesting as well.
Here's my two cents. I've been playing around w/ the Pulse product a bit and find it an interesting, but somewhat flawed approach, these thoughts are partially based on that and could apply almost equally well to where I'd like to see them go with it.. If there was a download mechanism somewhat as described I think that would be great, but I'd suggest the following changes: 1) strategic members can put together 'profiles' and add their own branding etc... 2) anyone can contribute plugins - it would be great if this was somehow tied in or through EPIC, e.g. make the developer add in enough meta-information to allow the installer to pick it up. Then you could have two (non-exclusive) 'modes' of operation: a) go in and grab stuff from the prepackaged profiles or b) go into a 'details' / customization wizard/area and pull in any of the various other plugins you want. These are just my thoughts, but as long time user of Eclipse, I'd hate to see something as potentially powerful as the suggested mechanism be so limited that power users of eclipse (and really how many non-power users of an IDE are there) simply don't use the proposed mechanism, in which case the value to strategic members would be greatly decreased.
(In reply to comment #11) > I suggest you begin that process. I understand from Mike that you intend to trigger a conversation at the next Board meeting. I will await the outcome of that discussion. > By limiting participation to only strategic members you will reduce [the] > selection that end users Yes, it could be less than if "anyone at all" could participate. In fact, using your argument, we should allow any company to participate whether or not they are an Eclipse member, right? Either way, this wizard will increase the current number of options for users from Y to Y+Q so it's a good thing, not a bad thing. I think that your argument isn't that Y+Q is bad, but that Y+Q+R would be better. So your argument is not that this is a negative for users but that it could be better for users. > Negative value to the non-strategic members is created simply > because they are barred from participating in a program that > some of them might find beneficial. The Foundation is currently providing value X to non-strategic members; if we implement this wizard, then you are saying that all the non-strategic members will have value X-N. I'm curious how many of the 100+ non-strategics feel that way. Using your discussion about participation in the Member's Distro program (comment #9), only three of the non-strategics participate and you've said that the Member's Distro's program is easier than the Download Wizard, so perhaps even fewer of the non-strategics are even interested in participating? So perhaps this isn't really a negative to the (set of all) non-strategic members? Perhaps, in fact, that greater adoption of Eclipse by more users will create more of an ecosystem for all Eclipse members, strategic and non-strategic? Perhaps that would be a net positive for the non-strategics (X+P)? (In reply to comment #12) > I've been playing around w/ the Pulse product Please note that this proposal is not an attempt to replace Pulse or Yoxos or any other Eclipse members' products. Those products provide valuable services for the Eclipse ecosystem that the Eclipse Foundation could never hope to provide, and has no interest in providing and, because we are limiting to distributing EPL code, cannot provide. > 1) strategic members can put > together 'profiles' and add their own branding etc... That's an interesting ideas - could you expand on that a little? We had thought that it would be better to have this less commercial and more aimed at the Eclipse open source projects with sort of a final "..and if you want more, go here" afterthought. I think you're saying that it should be more commercial, aimed at the strategic member's products from the start? > 2) anyone can contribute > plugins - it would be great if this was somehow tied in or through EPIC, While I don't make the decisions in this place (that's Mike's role), I can state that I really doubt we're going to do that. For one, this kind of wizard exposes us to legal issues that we feel confident the strategic members understand and will respect. We do not have that same confidence of "anyone at all". The EPIC model works because we, the Foundation, do not distribute (by the legal definition of distribute) any of those plug-ins. > a) go in and grab stuff from the prepackaged profiles > or b) go into a 'details' / customization wizard/area Our thought was to do a little of both: first you start with a pre-defined Eclipse package, then you can add other (or no) Eclipse plug-ins, then you can add other (or no) strategic member plug-ins. > so limited that power users of eclipse ... > simply don't use the proposed mechanism, I don't understand this final comment and I really want to because I agree with you: if you and I don't want to use this wizard, then it has failed. But I read and re-read your comment and I don't see where you talk about the proposed wizard's limitations. Are you saying that if there isn't a way for strategic members to add their branded packages, then it's too limited? Or if there isn't a way to add all the EPIC plug-ins, then it's too limited? Because if it's the latter, I understand that some of the strategic members plan to provide relatively complete catalogs of non-Foundation plug-ins from across the internet as choices in their wizard pages. Would that solve your concerns about limitations?
From Comment #13 >In fact, using your argument, we should >allow any company to participate whether or not they >are an Eclipse member, right? No, that's not my argument at all. I have one concern with this proposed program and that is that it participation is not permitted by Solutions Members of Eclipse. I stated that clearly in comment #2. The above is your third use of "reductio ad absurdum" reasoning to defend your position. It's illogical, invalid, and ineffective. From Comment #13 >Yes, it could be less than if "anyone at all" could participate. That make that your fourth use. For anyone interested here's a weblink that explains "reductio ad adsurdum" logical arguments in detail: http://en.wikipedia.org/wiki/Reductio_ad_absurdum I'm done discussing the parade of "Bjorn's Hypotheticals" as it is pointless and doesn't have anything to do with the actual proposed program. >The Foundation is currently providing value X to non-strategic members; >if we implement this wizard, then you are saying that all > the non-strategic members will have value X-N Again, an incorrect restatement of my point. It's simply that the Solutions Members do not get to participate in the increased value this program would provide. Maybe that's equitable and maybe it's not. I wanted to hear other points of view and that's why I raised this specific point for discussion. Bjorn, nothing is gained from the two of us going back and forth. I've articulated my sole concern with this program: it bars Solutions Members from participating in it. I was elected by the Solutions Member community to represent their interests and that's what I'm doing by raising this concern. I then asked for other points of view from people that this proposed policy would affect. You've given your opinion, I've given mine, and it's safe to say we disagree. Let's step back and let others have the opportunity to provide some additional perspectives.
I noticed the deployment plan states "The Eclipse Foundation plans to start with a beta test of this service in September." As soon as something even remotely usable is ready, I'd like to run it so I can get a feel for how many server resources I'll need to host this.
Bjorn, I am a little worried that having such a system while providing good options to users might decrease the value of the entire ecosystem. This is mainly because such a system can be fodder for some to say that you can essentially 'buy placement of commercial tools' and therefore the Eclipse foundation is not really independent but is beholden to corporate interests. Instead two commonly provided tools are for buying ad space and having higher ranking for strategic members have rationalizations that both make sense and have been used in other places before and therefore might make more sense to be used. Perhaps a good solution would be to have a list that all members can contribute to, and if it starts to get large then have a special list or two of features by strategic members and perhaps top downloaded features. Vineet
(In reply to comment #14) > No, that's not my argument at all. I have one concern with this proposed > program and that is that it participation is not permitted by Solutions Members > of Eclipse[...snip...]The above is your third use of "reductio ad absurdum" > reasoning to defend your position. It's illogical, invalid, and ineffective. I've been trying to follow this thread for my own understanding and interest. I didn't intend to enter the argument because I don't think my opinion carries much weight. But I still have a question that isn't clear to me, and probably isn't clear to anyone else in the community who might like to contribute to the discussion--other members for example: in all the back and forth I have not yet seen an explanation of why you think expanding the program to Strategic and Solutions Members is good, but imply that you don't care what happens beyond that. If you argue that Strategic membership only is too limited, why limit the scope to include only two classes of members? We have 4. Then there is the rest of the community... This is not a reductio ad absurbum argument, it's a valid question. Other than personal interest I don't see what your argument is. Personally I see a lot of technical problems with a large subset of providers since the strategy requires a hand-off of the user to a third party. Reliability? Trustworthiness? Resources?
(In reply to comment #14) > I was elected by the Solutions Member community to > represent their interests and that's what I'm doing by raising this concern. I understand that you are concerned; I look forward to the evidence that a significant percentage of the Solutions Members are also concerned. I also look forward to the Board's clarification of their position on the relative values of the different classes of membership. (In reply to comment #16) > the Eclipse foundation is not really independent but is > beholden to corporate interests. The Eclipse Foundation is not really independent in the sense that our funding comes entirely from our members and, even further, almost entirely from the Strategic Members. The funding to run the servers, pay for bandwidth, vet the IP, etc. as well as each and every one of the 500+ active committers all comes from the Members with an overwhelming percentage coming from the Strategic Members. It's a tricky balancing act, but it's also reality.
(In reply to comment #17) > (In reply to comment #14) <stuff deleted> > discussion--other members for example: in all the back and forth I have not > yet seen an explanation of why you think expanding the program to Strategic and > Solutions Members is good, but imply that you don't care what happens beyond > that. If you argue that Strategic membership only is too limited, why limit > the scope to include only two classes of members? We have 4. Then there is > the rest of the community... This is not a reductio ad absurbum argument, it's > a valid question. Other than personal interest I don't see what your argument > is. As a relatively disinterested party, I would like to take a shot at this. Todd, Bjorn...please forgive me. First, some assumptions: 1) The Foundation's ability to make distribution of Eclipse features/plugins 'easier' (through a proposal/technology like this) is an extremely important function...to any plugin developer...because easier distribution means more distribution, which means more promotion, and usage, which frequently translates into more revenue (through licensing or support or whatever). Even if it doesn't translate into revenue (e.g. for an EF project like ECF) distribution/usage/adoption still translates into greater 'project health'...e.g. greater ability to attract new committers, more contributions, more ideas, more visibility, etc. So the upshot being that most projects AND products want greater distribution, without greater distribution costs. 2) The Foundation is in the driver's seat WRT distribution and marketing of Eclipse. That is, most people go to www.eclipse.org when they want to get Eclipse, or ECF, or DSDP, or CTP, WTP, or etc. Most people download what the Foundation web site 'makes easy' to access (EPP packages, SDK, Ganymede, whatever). 3) The commercial members compete with one another. Anything that helps promote and distribute new plugins without costing them greater resources (for marketing/promotion, or distribution, etc) is good if it's for exclusively for them, or not so good if it's exclusively for their competitors. Even if they didn't compete with one another, getting greater/better distribution for no additional cost is in their interests (because of 1). So I think it's easy to see why Todd says in comment #14: >I was elected by the Solutions Member community to >represent their interests and that's what I'm doing by raising this concern ...because that community (Solutions members) do have an interest in making distribution of their products as effective as possible. So it seems to me that the main issue is one of fairness in allocating an EF-controlled scarce-but-important resource (distribution/promotion) equitably across the membership. As Vineet's comment #16 implies, the EF has to treat its membership equitably or risk being perceived as controlled by corporate interests: >...This is >mainly because such a system can be fodder for some to say that you can >essentially 'buy placement of commercial tools' and therefore the Eclipse >foundation is not really independent but is beholden to corporate interests. I agree that this would be bad for the whole ecosystem, if it is happening/were to happen. Seems to me this implies that a program like this should be applied equally to all commercial members...or none of them. Although 'strategics only' might be valid in terms of EF income, I think the EF would be hard pressed to make the argument that it's 'fair' to 'favor' the distribution of strategic member's products (over solution provider's)...simply because the strategics have higher 'tax rates' (as they also have disproportionately more resources...and receive greater membership benefits as well). My $0.02: I would be inclined to only include Eclipse projects with this program, and not include strategic or solution-providers. In addition to being more equitable vis-a-vis commercial members, maybe this would encourage both the strategics and the solution providers to more cooperatively support/use/contribute to EF projects.
(In reply to comment #19) > My $0.02: I would be inclined to only include Eclipse projects with this > program, and not include strategic or solution-providers. In addition to being > more equitable vis-a-vis commercial members, maybe this would encourage both > the strategics and the solution providers to more cooperatively > support/use/contribute to EF projects. I actually believe this isn't a bad start. Noone should disagree to this approach in the beginning. This also allows us to test out the technology before we add more projects. So, I'm heavily in favor in what Scott suggested. For those who question the Foundation's interests, let me reiterate that the REALITY is the majority of the Foundation funding comes from the strategic members. Some committer representatives have been doing things slowly to make this less of a reality, but it takes time as the funding model of the Foundation is setup to heavily depend on strategics. Extra value that we can provide for strategics is nice as long as it doesn't have a negative impact. So, for a start, how about we just do EF projects and than I can bring this topic up at the next board meeting. This is somewhat a similar problem to the advertising on the Eclipse.org home page in my mind :) I want to make sure that we can get custom delivery installer moving as it will provide high value to users in my opinion. We shouldn't deprive our user base of something like this while we argue out the details of what should be displayed outside of EF projects.
(In reply to comment #20) > I want to make sure that we can get custom delivery installer moving as it will > provide high value to users in my opinion. We shouldn't deprive our user base > of something like this while we argue out the details of what should be > displayed outside of EF projects. Definitely a good idea... (this might otherwise have too many competing interests to reach a conclusion).
I have no standing in this discussion but what about a solution like: strategic members get listed for 'free' (included in that level of membership) and solutions members can pay some sum of money to get listed? That's an in-between solution. It's a benefit to strategic members but lowers the bar a bit for inclusion by solutions members. They can then choose on an individual basis whether or not this is important to them. I don't think this is a Solomon solution, I think it benefits everyone.
(In reply to comment #20) > So, for a start, how about we just do EF projects In the end, Mike and the Board will make decisions and the rest of the Foundation staff will implement them. Having said that, my *personal* opinion is that just having the EF projects is actually not that much of a win for the users. The problem is that most users, myself included, want to use a larger set of features than are just provided by the EF projects. (In fact, if that were not true, the whole Eclipse ecosystem would collapse and none of us would have anything.) Hence the real value to me, as a user, is the ability to create a download that includes features from the commercial and larger open source ecosystem, not just the EF projects.
(In reply to comment #23) > (In reply to comment #20) > > So, for a start, how about we just do EF projects > > In the end, Mike and the Board will make decisions and the rest of the > Foundation staff will implement them. Having said that, my *personal* opinion > is that just having the EF projects is actually not that much of a win for the > users. The problem is that most users, myself included, want to use a larger > set of features than are just provided by the EF projects. (In fact, if that > were not true, the whole Eclipse ecosystem would collapse and none of us would > have anything.) Hence the real value to me, as a user, is the ability to create > a download that includes features from the commercial and larger open source > ecosystem, not just the EF projects. I disagree that there's no value in just having EF projects... to be honest, there are so many projects at EF that it's really hard to know what's available without being "in the know." From personal experience, I know quite a few people that were amazed to see ECF at Eclipse.org and were dismayed when I told them it's been at Eclipse.org for awhile, it just got showcased a bit by the Ganymede release site. Of course we can have a lot more value if we link the commercial and other open-source projects out there, but there's some contention right now and I still think we can provide value if we keep things moving while we deal with the contention. I think the EF staff can implement something that leaves the ability to plug-in other projects when we will need to. I just don't want the effort to be blocked while we bitch about who should be included in the wizard.
(In reply to comment #24) > I just don't want the effort to be blocked > while we bitch about who should be included in the wizard. We're not going to let that argument block us. As you can see in the proposal, we're going to build the alpha/beta test for Friends of Eclipse with no strategic member advertising page first then, once we have enough participating members, we'll add that page.
I really agree with the recent posts. IMHO, Whether the wizard is a good thing for the community/ecosystem and how the foundation constructs the membership program are two separate issues that are best considered separately. On the first point (is this good for the ecosystem?), everyone seems to agree, and I agree with everyone. The wizard could be a very good thing. As I understand the wizard (and we're committing to the effort), it's about reducing friction between consumers of features found at eclipse.org--end-users, add-in providers, service-providers, whoever--and the Eclipse projects that produce those features. I see it as a kind of open distribution point between the Eclipse release-train and the community. So making sure that the wizard is *open* to everyone--meaning its output should be consumable by *anyone* in the ecosystem--is critical, and that's the way it has been/is being designed. The point I understand Donald was making earlier is that the foundation has membership programs; some of the benefits of those programs are different levels of exposure on Eclipse web pages, download sites, etc.; and the foundation see this wizard potentially as an extension of those sites. That's an important discussion, but I think it can go on a completely separate track. The wizard is a *good thing* for the ecosystem/community whether or not it's part of a membership program. So I agree with Chris, Scott, Ed et al that there's no reason to tangle up work on something everyone wants in a discussion of an issue from which it can just as easily be decoupled. By the way, we're strategic members, so I guess we'd benefit from the program Mike proposes. But...believe it or not...we're committing because of all of the other reasons I mentioned above. Basically, it will contribute strongly to the common good, we're part of the commons and it's a domain where we think we can contribute. So thanks to recent posters for pushing this discussion in a strategic direction.
While speaking with Mike Taylor yesterday, I came to a further clarification about this proposed program. Basically, this proposed program has two parts: 1. A "choose your own features to download and install" wizard 2. "Banner" ads on the wizard final page for strategic members (a la the square ads on the home page for strategic members) The banner ads are sort of "super ads" because in addition to just passing along a click we also pass along a useful clickstream-like data payload (what the user has chosen in the wizard). The intent is that the strategic member receiving the ad click continues the wizard experience, but there is no requirement that they do so: perhaps the company puts up a page that says "you want Eclipse features X, Y, and Z, why not consider our super P distro that includes all those and more?" Hope this helps.
All this talk about strategic members vs. not and who gets content in the downloader, has, unfortunately distracted everyone from the very important point that: THIS IS SO FREEKIN' COOL!!! :)
(In reply to comment #28) > THIS IS SO FREEKIN' COOL!!! :) +1!
I agree with Todd. We are an add-in provider member and we would definitly want to be included in the wizard. So i guess we would change the list at http://www.eclipse.org/membership/special_programs/custom-delivery-installer-program.php and add 4. Increase the value of other eclipse memberships EPIC is structured in a relatively small number of categories. See the list at http://www.eclipseplugincentral.com/ Assuming that every add-in provider has added their tools to the list there are only 1063 "plugins" in about 30 categories. Now this thread is very much about who can join but is it also ok to discuss some wizard functionallity? The wizard could be extended by asking "please enter the domain name of your supplier" and then query that address for the wizard extension. The user then still would have to do some digging for "non strategic" plugins but would at least have the option to include it in the wizard. I would also opt that the user could save the selection (xml) so that it could be imported later. This also allows add-in providers (and others) to publish an xml file with the most optimal set of plugins that could be used to populate the wizard. The other option that is maybe a little tougher to complete is to extend the wizard to resemble adding gadgets in google, firefox. Type in a few keywords and then add the prompted plugins.
(In reply to comment #30) > I agree with Todd. We are an add-in provider member and we would definitly want > to be included in the wizard. So i guess we would change the list at > http://www.eclipse.org/membership/special_programs/custom-delivery-installer-program.php > and add Hi Wim, Are you aware of this program: http://www.eclipse.org/membership/special_programs/member-downloads-program.php If you would see value in the program proposed in this bug, I would expect you would want to be involved in the already-running member distros program too. - Don
Hmmm, if you were following the EPP mailing list during the past few weeks you would have seen that there is progress, but let's see if I can start the discussions again by adding a link to this here: http://build.eclipse.org/eppwizard/go Of course, you need a Friends-of-Eclipse login... It is up and running and if you are interested in the internals and in the technical background, look at this page that links to some important documents: http://wiki.eclipse.org/EPP/Wizard
(In reply to comment #32) > Hmmm, if you were following the EPP mailing list during the past few weeks you > would have seen that there is progress, but let's see if I can start the > discussions again by adding a link to this here: > > http://build.eclipse.org/eppwizard/go > > Of course, you need a Friends-of-Eclipse login... When is this planned to be open to "non-friends," such as Strategic members of the Foundation? ;)
(In reply to comment #33) > (In reply to comment #32) > > Hmmm, if you were following the EPP mailing list during the past few weeks you > > would have seen that there is progress, but let's see if I can start the > > discussions again by adding a link to this here: > > > > http://build.eclipse.org/eppwizard/go > > > > Of course, you need a Friends-of-Eclipse login... > > When is this planned to be open to "non-friends," such as Strategic members of > the Foundation? ;) > I am just quoting from http://www.eclipse.org/membership/special_programs/custom-delivery-installer-program.php: "After verifying that the wizard works (server load, bandwidth load, handoffs to secondary wizards, good user experience, etc), we will enable to wizard for a larger beta test (anyone with a bugzilla account). We anticipate this second larger beta in October. The third step is to enable the wizard without restriction. We anticipate this "go live" in November. It is important for the Eclipse Foundation IT staff to have the deployment completed as soon as possible so that we can detect and repair any scaling or user interface issues long before the "busy season" begins (it begins late in the calendar year and then scales rapidly from there through M4, M5, EclipseCon, the RCs, and the annual release)."
> Hmmm, if you were following the EPP mailing list during the past few weeks you > would have seen that there is progress, but let's see if I can start the > discussions again by adding a link to this here: Can progress / design discussion be moved from the EPP mailing list to this bug? This would make easier for the strategic members who are interested in participating in the program to monitor and stay involved. It's hard to monitor yet another mailing list. :)
(In reply to comment #35) > Can progress / design discussion be moved from the EPP mailing list to this > bug? This would make easier for the strategic members who are interested in > participating in the program to monitor and stay involved. It's hard to monitor > yet another mailing list. :) Yes, I fully agree... AND I think that the discussion about progress / design etc. is not part of this bug, therefore I created bug #249393 to collect and discuss any feedback. There are other open bugs that may be interesting, e.g. look for EPP / Dynamic Package Delivery component.
Markus, if this technology is using p2, then this bug should be marked as depending on bug 239668. We need a mechanism to accurately track download requests.
I don't think the custom delivery installer needs a p2 solution for tracing since through the wizards it has enough meaningful data for stats.
This initiative was shelved some time ago. Suggest closing WONTFIX.
Closing as per previous comments.
