Welcome to me - VP of Apache Attic despite my spending a year scuffing my feet and hoping someone else would want to wear the hat.
What is Apache Attic going to be? It’s a consultancy project to provide janitorial services to zombies.
Just a note that one of my favourite authors died last week: Hugh Cook 9/8/56 - 8/11/08, in case anyone else was a fan. He’s somewhat unknown in the US, but his books used to fill the shelves back home at WHSmith when I were a lad, and until he took ill with a relapse a year back, his blog was my favourite spot on the net. He brought sanity into an insane world.
I also noticed the other day that another author whom I like (David Gemmell) had died a few years previously. Publishing lead times are such that books keep getting published and you don’t notice such things - his last full book isn’t out in paperback yet and his wife will be finishing the unfinished book (or has already).
That event (or 2 year later noticing of such an event) led me to realize the basic difference between my book collection and my fathers. I used to think that I was into a different genre than he, or some other classification or codification to explain the difference. Now I think it’s just that his authors were dead while mine were alive. Now that’s increasingly changing and I find I’m digging into the ‘classics’ more to finish the education (as such) started in his bookshelf.
I got ‘We‘ the other day for my birthday, so will be reading that soon. Right now I’m reading the Watchmen graphic novel which rather bizarrely is in Time’s 100 books since 1923 (presumably that’s the year 0 in copyright law).
Hmmm… I like that idea. A new epoch determined as the retromodified moment by the giant copyright holding entities. It’s now 85 AMM (after-micky-mouse…. though that was 1928 so bah).
Spent much time drinking here: Halfway house - from the poor review it sounds like it’s not changed much.
(I think it meant halfway from London to somewhere… not that it was a place for kids with disorders. Then again….)
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?).
On Brian’s request (with a super rapid 8 month delivery) - a CSV view for JIRA’s Find Issues page:
While doing some Commons Lang work I realized I needed a new feature from the contribution report as it’s the only way in JIRA to get a list of attachments (aka patches most of the time). Namely adding an option to only see unresolved contributions so I can see which issues have patches that need resolving. Also threw in totals as that was an enhancement idea from back in Feb and voila:
Has been recommended to me by quite a few people, so when my wife suggested I take it on the trip with me I figured why not. Reading the early chapters about the US dependence on Corn, I’m reminded of Asimov’s Foundation books. In these he had societies dependent on food grown in massive yeast vats. I always felt that was great predictive sci-fi and the side of me that is in favour of gm food and further man-made control of our food tree was based on the need for us to be scaling to support our population with such a direct food production system. I thought it was some long off day.
Reading about the domination of corn in the supermarket, I realize that day is here. Makes up for missing microcomputers I guess 
Now to be on the look out for someone discussing psychohistory.
Hearing Jukka talking about git; which I’ve largely not really dug into yet as projects I use/work on haven’t moved to it. I now have a feature request for that for Mike, Ben, Jonathan et al.
Put a github inside each JIRA project. I should be able to commit my patches into a JIRA space. Obviously you guys have to allow for plugability of the other distributed SCMs, but that’s why you guys get paid and I just meddle. Effectively I want a version of the Attachment concept which is a git target.
Feel free to continue to enjoy your time until Christmas, I won’t get my hopes up ’til Easter ‘09.
Thankyou.
And a quick Release Plugin release from my JIRA Outlet project. Which also has a Bamboo build now. Just the one bugfix. It’s been an irritation for a while, but for some reason I hadn’t clicked as to where it was coming from. Anyway - bug be gone.
Did a bit of hackathon work. Discussed a retirement plan for Apache projects, and made some commits to Jakarta Taglibs Standard (aka JSTL) and Commons Collections to get them closer to release status.
Very nice Jambalaya at the members reception - thanks to Spring Source for that. A free dinner is always appreciated.
Missing the family, enjoying the conversations.
