>So, it seems the intentionally provocative title of my last post re-started some discussion. Boris is correct, we need to “Step-up or Shut-up”. Boris and Pascal (here, and here) have both taken good looks at their diversification and have provided sound reasoning for their stance. Boris goes on to expound the virtues of the “eclipse way”. Which I agree is a good process, until the project reaches a certain size, and then some ugly slow points start to creep in (i.e. how much more often is a build red than it is green?) I’ve blogged about ways to tweak the “eclipse way” that I think can address some of these pain points.
However, in all of this, I think one response has hit the true heart of the matter. That is Doug Schaefer’s. In “Diversification is not the only answer“, he correctly points out how diversified (i.e. how many different companies or individuals are working on a project) is not the sole or most important aspect. How Open a project is, is probably the most important aspect. Ultimately he goes on to say that it’s a cultural change that has to occur. He is correct.
In my opinion, once you start an open source project and are engaging with it, you MUST be willing to let go of control to some extent of that project and the overall direction. You need to make a concentrated effort to engage with that community. It means no more private email discussions about project plans and directions. It means posting meeting minutes. It means engaging all project contributions and committers even if they are a competitor.
As Doug said, I’ve seen features show up in eclipse projects that had very little to no announcement that they were even being worked on. No bug entry, and no discussion. I’ve seen projects announced that only have one company as the committer. I’ve seen new projects not go through Incubation, but directly to full fledged projects. We’ve all seen varying degrees of this, and it doesn’t necessarily encourage the openness I think some in the community would like to see.
Now the openness aspect like the diversity aspect varies between projects, some are good…others really could use improvement. Opinions will vary on how open a particular project or sub-project is.
I personally believe that working on an open-source project takes a different attitude and different mind set than working on a commercial product. The former needs to really engage with the user community, encourage the elimination of knowledge silos, and lower the barriers to entry so that the project can thrive. Don’t get me wrong, the commercial product still needs to engage it’s community, but it does so on a much smaller scale and not as open a manner as I think open source projects need to have.
I’ve personally tried to do this with my work on helping to form an active and vibrant XML Community around the WTP Source Editing project’s SSE editor. To a small extent I’m starting to see this effort take fruit. In the WTP Incubator we have the following XML projects slowly cooking:
- VEX – The Visual Editor for XML – originally a sourceforge.net project that has migrated to Eclipse. Since it’s migration it has started to see an increase in interest, and should soon get a new committer to help move it along.
- XML Security Tools – an under promoted piece of tooling that can help with the testing and implementation of XML Security and Digital Signature. If you are doing some advanced XML Encryption with Web Services or REST you may want to look into this.
- XQuery Development Tools – This started as a Google Summer of Code project, but since then the main code has been replaced by another SourceForge hosted application XQDT. The goal is to provide first rate XQuery support for eclipse.
- RelaxNG Tools – provides grammar, content assistance, and other editing functionality.
Not to mention that the XSL Tools component was the first project to start in the WTP Incubator, and the first to graduate to the WTP Source Editing project. XSL Tools itself is something I’m proud of because it was not created by commercial supporters of eclipse (in fact it competes with some adopters existing functionality), it was created by the will of three community members to get the effort done. David Williams and Chris Aniszczyk both helped get the ball rolling on the project. However, the work couldn’t continue with out the effort of myself, Doug Satchwell, and Jesper Moeller. Along the way, we have picked up another individual Mukul Gandhi an Apache Xerces-J committer. Mukul has been using the PsychoPath XPath 2.0 Processor to add XML Schemas 1.1 Assertion support to Xerces-J. (One of the few instances I think were an eclipse project is being used outside of an OSGI runtime system besides some SWT applications). PsychoPath itself is another community contribution by an individual, Andres Bittau the original author who had the code on Sourceforge.
Most of these guys would not have brought or thought they could bring their projects to eclipse or even considered working as committers. Why? Nobody had asked them before. Sometimes it only takes a moment to ask. I’ve found that most people working in open source (paid or not paid) like to be acknowledged and encouraged. A kind word, a helping hand, and more importantly, a quick and timely response will go a long way to encourage somebody to keep contributing. If a bug takes 6 months to have a response…more than likely the person has moved on already to something else. For every day of delay, you start to loose that person’s interest.
Working on an open source project and really making it thrive takes effort. It means putting in hours in your spare time. It’s not just an 8 hour a day job. Even if you are working part-time, it takes up a good portion of your free time. I post my concerns, because I see areas where eclipse related projects need improvement. Where they need to learn from the mistakes of projects like Xalan-J from Apache (for all intents an purposes a dead project that it is difficult for outside community members to take over AT Apache). Sure we can fork the code, but the thing is…you still have the same issues of building that community and keeping it going. There is plenty of things that eclipse does right…and however slowly at times, the foundation does respond to address some of the issues the community has raised. The foundation is only one piece of the puzzle though.
Ultimately, the community as a whole needs to step up and help. There is more than just contributing code that you can do.
- See missing documentation or non-existent tutorials? There is a Wiki for That.
- Help create Babel translations for your favorite project.
- Is the documentation on the wiki only in English? How about a translation for your particular language?
- Don’t forget the Forums, there are plenty of people needing help there, take a few minutes to answer forum posts.
We as committers can try to fight it and keep control ourselves, but change happens. It is like death and taxes. Inevitable.