Tags: OpenJDK
Many thoughts bubbled up from listening to
FLOSS Weekly 11: Guido van Rossum ... so here's a couple.
First, they discussed the major complaint against Python, a complaint that has kept me from learning the language lo these many years since I first heard of it way back in the early 90's. Namely, it seems broken for a language to use white space as anything important like delineating "blocks". Yeah, this is a widely shared complaint, and at the same time it's interesting how many large projects get written in Python.
What struck me was Guido's answer: Programmers already use white space to delineate blocks. Programs are ugly when you don't indent your blocks, right? So why not enforce that in the language?
Hmmm... that's enough of a good point to make me reconsider.
Anyway .. the more important thought that bubbled up was the style of how Guido talked of his "management" of Python. His style seemed very friendly, embracing, and especially nurturing of the community around the Python project.
It's the community aspect that's most appealing about open source projects. An open source project is often secondarily about the technology, and often mostly about the community that's built to handle the technology. I think it comes from the origins of the Python project and how it began. And it's interesting to contrast that sort of beginning with how Java SE is going to move into being open source.
As I've been sitting with this process of open sourcing Java SE I'm remembering my own history in computing. I started in the 70's hanging out in a computer lab in my high school in Herndon VA. We had access to an HP3000 owned by the Fairfax County education department, and "access" meant a teletype ... And we had a community of pseudo-hackers hanging out in the lab, using snarfed passwords to access various accounts, etc. In the 80's I found my way to Usenet and the Internet ... "found my way" meant that I was the one responsible at my University for first discovering that Usenet existed, then being the one responsible for working out how to get connected to Usenet, and then working out the approval for actually getting our university connected to Usenet. I think I was still (technically) a Freshman. Freshman year was the best five years of my life.
In all those places, that high school lab, among my C.S. buddies at school, on Usenet, and on the Internet ... sharing and community were just what we did. The sharing and community we had on Usenet and the various mailing lists led to the open source movement and led to the ability for the Web to take off like it has.
My personal example of something I shared is ... along about 1986 the C.S. department chairman was rather upset about the $500 per month being spent on telephone bills to get Usenet content into our university. So as the guy responsible for bring Usenet to the university, they looked to me to justify it. I might have been a sophomore by then. So I scratched my head and realized, hmm, there's people reading these newsgroups, and they're leaving trails of data in their .newsrc files about what newsgroups they're reading. So I wrote a script to gather the .newsrc files and crunch out some statistics of which groups were being read. That was enough data to keep the department chairman happy, and I posted the script to news.admin.xyz ...
Then, Brian Reid saw that script and got inspired to tweak it to make a global version of the same statistics gathering. That was the Usenet Arbitron service which collected global usage statistics on Usenet newsgroup popularity. Okay, it had some questionable data gathering assumptions, but it did show some interesting results.
The most important lesson for me is .. by sharing, others can stand on your shoulders and see farther.
But, let's steer back to the idea I started with ...
It seems to me the origins of a project affect the style of the commmunity that results. It seems to me that a project which starts small and grows organically .. e.g. Python .. has a different style of community than one which starts out as a commercial project that is then open sourced. e.g. Java SE. It seems to me this is inescapable because of the people-process that's gone through to nurture a shared project, versus the people-process that goes into making a product that you're providing to customers.
That difference shows in the way you describe them ...
- Some projects the maintainers nurture and grow a shared community
- Other projects are a product that's supplied to customers
I don't have any great conclusion here .. just an observation and a bit of reminiscing.
UPDATE: Um, I don't mean this to be a prediction or reflection on anything I see in the process of open sourcing Java SE. I think we (Java SE) know that to be successful with open sourcing Java SE, we need to learn how to nuture and grow community. I'm just reflecting on how the skill set for delivering a product differs from the skill set for growing a community.
Source:
weblogs.java.net
