I just returned from the Eclipse Members’ meeting near Chicago, and there was some discussion about just what it means to contribute to Eclipse. This question has come up periodically, and seems to be more popular when projects are in planning mode (and hence trying to figure out what to do and who will do it). It certainly has been a recent topic of discussion in the DTP community, and I had more than one conversation at the Members’ reception around it as well. So, what does it mean to “contribute” to Eclipse?
There are many ways to make contributions, and we probably could debate a list for a long time without getting to a consensus. Luckily, the key point of my argument below doesn’t depend on a definitive list, so we can just make an estimate. Broadly speaking, we could classify contributions into three categories: definition, implementation, and use. By “definition” I mean things like use case and requirements gathering, design and architecture specification and so on. Clearly there are a number of ways to contribute to definition in Eclipse projects. Next, “implementation” is pretty obvious: mainly we’re talking about providing code (including unit tests, samples, etc.). Finally, “use” would cover contributions resulting from using the software. The most obvious candidate for this category is bug reports, but I’d also include efforts to drive adoption and help users/extenders succeed. Note that these are not strict categories and the process is interleaved. For example, during usage enhancement requests (definition) appear, or during implementation, certainly bug reports from usage are made.
Like I said, nothing really hangs directly on the exact list, though I think that most would agree with the rough boundaries suggested. Now, let’s get on the main point of this post: which contributions are most important (valuable, welcomed….)? Two types of answers immediately come to mind: I could give a feel-good “every contribution is valuable!” answer, but that’s just not my way. :-) Or I could propose a ranking, which would end causing more controversy than even the list of contribution types. From this controversy, and – no doubt – the lack of consensus about any one ranking, I would begin to suspect something. Next, I observe the feeling that ranking contribution types in a strict order somehow seems inflexible. Lack of agreement about ranking and inflexibility at even the thought of ranking tells me that something else is going on.
I propose that various types of contributions to Eclipse projects do have relative importance rankings but that these rankings change over time. I also claim that this is the case, regardless of what your list of contribution types is. Finally, the importance of particular contributions at a particular time varies depending on the “level” of your view. For example, DTP Ganymede as a whole might have one set of rankings, whereas specific components in DTP Ganymede would have others.
If we accept that contribution types vary in importance over time and level of granularity, then I think we can begin to understand some patterns depending on where a particular project (component, plug-in, etc.) is at a given time. For example, components undergoing substantial growth (including being born), such as the DTP Ganymede Visual SQL Query Builder, put an emphasis on implementation contributions over other types. Mature components, such as DTP ODA, might value usage contributions to refine example, API definitions and so on.
So, yes, all contributions are valued and welcomed. But certain types are more valuable and welcomed, depending on conditions at the given moment.
Finally, let’s explore an interesting implication of this idea. I think it’s fair to say that implementation contributions are generally perceived as being more valuable by project members. The appeal is that those producing the code seem to be doing – in some way – the crucial work. And – of course – if there is no implementation, then the definition was all talk, and usage is precluded. Following this, we tend to measure contributions to project based on commit event (or lines of code) to CVS. Those most active in this area (and by extension, their organizations) are contributing more to given project.
But the emphasis at Eclipse has been on ecosystem development: just slinging out code is not the goal. I think Bjorn in particular has mentioned this several times. So, turning the code-slinging logic on its head, I’d say that if your major effort in an Eclipse project is to push code out, you’re not contributing.
Before you flame me, realize that the preceeding statement was made simply to draw a sharp contrast to the code-king attitude discussed above. I know it seems ridiculous to say that only coding is not contributing to Eclipse, but you could also argue that code contributions as the main metric of overall contributions is equally wrong.
