Thinking out loud on a new vision for Commons…. (aka.. this is the lightning talk I should have given if I’d have thought the thoughts more clearly 48 hours earlier).
Originally Commons was a place for Jakarta projects to come together. It worked somewhat, but then built its own commit base rather than being a place for people to come together. The use cases that drove the code was more often outside of the AS, in day jobs, than at the ASF. At least for the enhancements and bugfixes to a library. This is a good thing, but the first aim is not being met.
Somewhere in the conversations between Commons people that we’ve had at ApacheCon (just mumblings and grumblings oh people who were not here) there is an underlying ‘truth’ - which is more than just an open source project that has been surprisingly successful in its own quiet way. It’s something to do with the bazaar atmosphere, with the high level of equality (everyone’s a benevolent dictator of some component or other), with the notion of delimited and overlapping community that allows for high amounts of individuality without a high bus count, and, yes, with the pain that a strong focus of stability has given us all in the general lack of aggressive JDK 1.5+ libraries. There’s something different about the project which is an idea worth taking further. I don’t pretend to understand it completely.
The failure of the initial aim to bring projects to share is, I believe, strongly in the notion that people are committers of a project. Or two. Each new project you commit to is a context switch and a responsibility load to add. You can’t keep up. Many who join Commons end up focusing on Commons more than their original project, while others pass through doing good and then going back home for good. There’s not a feeling that you can join in every now and then. It’s a new entity - not a true commons.
It always was in some way… when you left the house in the village to head out to the common, you were on different behaviour, playing a different role. The difference was that it was well understood that you were going back home again, and you’d be back out again tomorrow, or the day after, or some time soon.
One thing we’ve had over the years are projects and people who took their toys away again and went to sit in their house where the code worked happily inside their project and was no longer easy to find. My assumption here is that this is because when you’re on the common there are standard rules to adhere to - don’t let your dog crap on the grass, don’t play golf, don’t drive your car. Some don’t like this. In Commons’ case it’s a standard release process, and parent pom which leads to the same build/website approach. It becomes a case of fully committing to the tribe, or staying home.
Thus we get to the title of this ramble. There needs to be a middle ground and I have two snippets of thought to propose as a starter for that new land.
Firstly… the open Commons. While the Apache structure means it can’t be open for anyone off the street (and I spend enough time with lawyers to know I want that) - I think we need to reach a point where Apache committers feel no obligation to take on Commons as a new home. Show up - work on your piece - go home. We need to find a technical solution here -giving everyone commit access will likely be chaotic, despite my desire to try such a thing. Maybe the solution is to provide a branch space for any committer to work on something and integration comes via the regular maintainers. Anyway - problem 1 to solve - let people know it’s easy to walk in, help out, and head home again.
Secondly - there needs to be a solution to taking toys home and having them be hidden. I call it ‘taking the toy home and putting it in the window’. Or more positively - ‘putting the toy in the window to see if anyone wants you to come play’. Let’s use a concrete example. The Droids Incubator project has a component called NoRobots. It’s a simple robots.txt parser that has had a migratory life (from my osjava to Commons suggestion to HttpComponents to Droids). The Droids project should flag it as beloning to the federated Commons, Commons themselves will link over to it and life can continue. It’s a a Commons-like component, just not actually developed in Commons.
What would being a part of the federated Commons mean? Here’s some thoughts:
* Website stays in the window. It puts on a federated-Commons logo (”Part of the Greater Commons”?).
* Name becomes Commons Xxx (I’m 50/50 on this one… it’s bold yet potentially confusing).
* The Commons website links to the window. It is also the obvious location for more discovery mechanisms such as a page that explains the types of components available etc. Tempted to write a focused bit of tech that reuses the existing DOAP xmls.
* Uses a Commons (Java)-namespace/maven ids (again a 50/50).
* Upholds a lightweight set of release quality goals that probably match 100% to ASF goals.
If development activity starts to spread to other projects - then it can move more squarely into the Commons as a middle ground.
There’s a third item I want to mumble about. The stagnation of stability. Focus on not screwing users leads to stagnation. Axis made a healthy choice (for themselves) to screw their users and move to Axis2. They’re in a better place now. Log4j made a healthy choice (for their users) and focused on stability. They’re in a worse place now but offered better value to the users. Both are a sign of choosing a polar extreme. Much of Commons suffers from the Log4j path… except for CLI which has the Axis approach (but worse in that the new development lost direction but robbed the old development of life).
What am I rambling about now eh? I’m going to call it the unhealthy competition between maintainer and creator. The battle between the goal creator and the water carrier (c’est vrai mon petite sardines?). The failed balance between the draining of 1.x, and the rejuvenation of 2.0. We need to be more concious of the creation process. Here’s my versioning manifesto of bleeding obvious statements:
* New versions are always done in a branch, with a sandbox mentality. The website and the public material remains 1.x focused until 2.0 is ready; not to say that it can’t link to the ‘coming soon’, but it should uphold 1.x until the time is right. No more CLI screwups.
* New major revisions can do whatever they bleeding well want to with backwards compatibility. If that means changing package names to avoid the problem of transitive dependencies or runtime stupidity, then so be it. Change away. Even change product name, there is no reason why BeanUtils couldn’t be replaced by ‘Reflector’ - it’s only a brand and it means the approach can be wholly new.
That’s all I have. I’m pretty sure I used up my 5 minutes. Go home - put something in the window. Maybe the federated Commons will even stretch to the next town (JODA Time anyone?).
