Friday, July 03. 2009
Recommended Books: PostGIS In Action PostgreSQL 8.4 Official The SQL Language PostgreSQL 8.4 Server Administration
PostgreSQL 8.4 has come out, and while I am a bit disappointed that PostGIS 1.4 has not come out for fear that we've missed a bit of the PostgreSQL 8.4 momentum, I am happy that we are nearing closer and just maybe we'll have it out by end next week. We now have a PostGIS 1.4RC1 http://postgis.refractions.net/download/postgis-1.4.0rc1.tar.gz tar ball as well as experimental binary builds of this for windows user's running PostgreSQL 8.3 http://postgis.refractions.net/download/windows/pg83/experimental/postgis/ or PostgreSQL 8.4 http://postgis.refractions.net/download/windows/pg84/experimental/postgis/. Please give both a try.
Working in the Cathedral Really?
As Paul duly noted in his blog entry Working in the Cathedral the model for PostGIS development is morphing, but I wouldn't call this morphing process one that is entirely toward the Cathedral model. Unlike the perceived Cathedral model, I would like to think we will have more frequent releases and beta releases, perhaps parallel experimental builds and most importantly, more fun. The main idea being making it much easier for mere mortals and fake mortals to taste test the cookies in the oven while they are cooking. By fake I mean unit tests, build bots, and computer generated people where the fear of destruction is removed. I feel this is the similar model PostgreSQL goes by or is trying to achieve.
Let me just say for one that I respect Eric Raymond a great deal, but I think that while most of his observations about Cathedral and Bazaar are accurate, some of his conclusions are a bit flawed. Hopefully I won't start too many fist fights from this statement. The main distinctions I see between the two and why Bazaar seems to many more efficient has nothing to do with the model at all. Its all about the people. If you get a group of people all passionate about the work they are doing it really doesn't matter which model you are using (Cathedral or Bazaar). Most likely you will succeed. A dispassionate mess of bazaar workers working together will create dysfunctional code that no one wants to use or work on. You'd be much better with a cathedral one where there is one passionate leader. I also think the success of the Bazaar and Open Source in general is probably over exaggerated. When no one is getting directly paid, its hard to quantify a loss. If 100,000 volunteers work on a project that is free and fun, most likely they aren't keeping a timesheet of how much time they are expending. In a cathedral model a lot of your utility is driven by monetary benefit, which means your time is either over exaggerated or at the very least precise. We know we lost $1,000,000 because we paid people $1,000,000 to build this thing.
First where did this cathedral model come from? it came from engineers and scientists. While I'm not a practicing engineer and I just have a degree in mechanical engineering, I still feel very close to my engineering roots. I'm not talking about that ill-defined term pompous people throw around "I've got a BS in Software Engineering", which to me is so badly abused not to be even worth talking about. I'm talking about real engineering; things like Mechanical Engineering, Civil Engineering, and Electrical Engineering. In engineering you do a lot of planning and have stringent requirements of what is acceptable and what is not. You have very seasoned engineers and technicians in the field who have amazing powers of intuition and new engineers and technicians straight out of school who are are honored to work with these people. You have a lot of smoke tests and things of that sort that stress test a system. This is because while building a bridge or plane might be fun, you can't afford to have bridges falling or planes crashing on people. One of those scandals and you are out of business. Yes some things also are not fun but need to be done. Having rules in place and stringent guidelines on what should and how should it be built is inherently not fun.
In engineering things like building virtual models are becoming more respected and more in vogue, because it allows you to test things out without killing real people or destroying real equipment or using real material in the process. It in essense allows you to be more care-free in designing thus making a better, cheaper and more fun project to work on.
In software the cathedral model was designed to get people to work on things that aren't fun. Even with "fun projects" you have a lot of stuff people consider as not fun and this will not change. In software the cathedral is a self-fulfilling prophecy. It managed to categorize tasks and projects such as building financial packages, documentation and testing as not fun such that the people who would have enjoyed these things decided -- software is not fun but pays the bills thus creating an institution of dispassionate people interested in the industry for the perceived money and scaring off passionate people on to other fulfilling things.The bazaar model is an equally self-fulfilling prophecy. It encouraged a hacker mentality focused on only doing "fun stuff that scratches my own itch", that doesn't pay much but is fun. It too managed to give the vision of bleeding edge running code stuff is fun and documentation/testing is not important because people we care about will dig into the pie where they fit. These are the same people that whine about where did all the women go and why people aren't biting even though its free. Not to say that women are less worthy hackers, but that they are more apt to put a price on these harder to quantify things, thus making their utility function less compatible with open source or the bazaar model.
So what's my point. The point is that not only did these models define a concept of fun/not fun, they also defined the very meaning of fun not fun to people. No one wants to work on something they perceive of as not fun unless they are getting a ton of money for it. Glory is also a kind of fun because no one wants to work on something that they don't get any glory for or monetary income from. You probably don't want to fill your coffers with people just interested in the monetary value and dispassionate about your product, because they will find ways to maximize profit while minimize level of effort they need to do. In the same vein you don't want to grossly undervalue the things that are hard to quantify.
This gets to the point of a more obnoxious problem. This is the devaluation of testing and documentation. These two things are things where people agree its important, but can't put a price on. A cathedral model has an easier time putting a price on this, because part of the documenation is the specification itself that drives the model. In a bazaar we may have a "this will be a cool feature lets throw it in". The tragedy of this is that people put a price of 0 on something they can't price and don't see standing on its own in a grocery list and thus the work of testers and documenters is seemed as useless which makes the work not glamorous and no fun and in a pure volunteer model, you also get no money.
To demonstrate if you were to put a price on say introducing function X into a product - to figure out the value of it -- all you need to do is look at the price of that in a similar product. We need only look at say Oracle to figure out the value of x. However for a simple feature documentation, primarily user documentation, aside from its existence is not important to document it well and testing is a similar thing. How do you price the documentation of a complex feature X? The documentation/testing of X may be more valuable than the programming that went into X or it may not be needed at all. A pure model driven by volunteers has a bit of a harder time overcoming this problem than a paid project unless they can quantify the value of these or make the work more fun and glamorous. This means figuring out the importance of documentation on each item, glamorizing it, encouraging hackers who understand the function into documenting with cathedral like injections :).
Recommended Books: PostGIS In Action PostgreSQL 8.4 Official The SQL Language PostgreSQL 8.4 Server Administration
Display comments as (Linear | Threaded)
There are some people who do value the importance of documentation and testing, without it being glamorized. To wit, early in the Linux project people wrote How-To's to share their knowledge and allow others to participate. Did Bruce Momjiam write the first PostgreSQL book because he foresaw making a ton of money from it or because he innately enjoys teaching? On the testing front, look at the work of David Wheeler.
Open source software development has some characteristics of the "economic calculation problem" (see http://mises.org/econcalc.asp) postulated by Ludwig von Mises with regard to socialism. However, not being able to put a monetary price on an item to be produced doesn't mean it will not be produced (or will only be produced under coercion). And it's not just "glory" (or recognition) that leads humans to act (see http://mises.org/rothbard/mes/chap1b.asp#5._Further_Implications, in particular, the paragraph that starts with "All action is an attempt to exchange a less satisfactory state of affairs for a more satisfactory one.")
#1 Joe on 2009-07-04 09:51
all good points.
Regarding my comment about glory. That may be too strong of a term. My point is if you are doing a lot of work for a project and you don't get the sense that your work is being valued by the key people in a project, chances are you are going to leave and stop working for it.
In a paying project you stil care but care a little less because you are getting a monetary value from it.
Bruce documented because he knew he needed to to get buy in from people. When you think about Bruce though -- you don't think of him so much in the light of the guy who first documented how to use PostgreSQL so the common folk can use it. In fact that was probably one of his biggest contributions.
In a similar light Paul Ramsey did most of the initial documentation for PostGIS, but he is not known as the guy who first cared enough to document how to use PostGIS. That is also perhaps one of his biggest as well, because I know for one I wouldn't have started using it. I would have dismissed the project as one too early on or for reckless hackers who don't care about a user community.
I guess my point is even though some people feel these things are important and especially the people that cradle the project while its forming, its not seen as a critical component by most -- because its kind of buried down there. Its sort of a hidden line item that is needed and expected but not valued like raw features. Presumably because a feature can exist without documentation, but documentation about something that doesn't exist is not terribly useful unless it is the specification that programmers go by to build the work and specifications can be so easily flipped into user documentation because they encode in them the test cases to test the work when done :). Such a concept I don't believe exists in a pure bazaar model.
In an open source project often times, if you are not a hacker -- you are simply documenting, you are basically seen as valueless even though your value is probably more important than people coding. This drives away people who enjoy just tinkering with new tools. Sure you'll still have some of these -- but they probably have a mixed personality so are credited for their non-documenter work. You will lose all the purer breeds and that is a real shame since others who find this work less enjoyable will be forced to step up to the plate more.
Then again I would venture to bet there is no such thing as a successful pure bazaar model and even Linux has cathedral like qualities built into it at least nowadays but they are sufficiently light not to be offensive or get in the way of creativity.
#1.1 Regina on 2009-07-04 23:23
Once any enterprise (as in endeavor, not necessarily a business) reaches a certain magnitude, people tend to specialize and thus it becomes more necessary to coordinate activities (e.g., developers' meetings for planning). Thus, as you say, the bazaar model acquires cathedral-like qualities.
However, what I think still differentiates an open source project from a closed one is the freedom of the individual contributors to pursue their vision of what matters to the product. If someone at Oracle or Microsoft thinks of a cool new feature, they will not be able to add it at their discretion. They'll have to get buy-in from product management or whoever else decides what gets in the next release. And they won't be able to work on it at their leisure if they've been assigned some other priority. Maybe some enterprising souls will still work on their dream feature, but they'll lack any incentives from the company or the project manager to do so.
In an open source project, that same person can pursue development of their cool feature without worrying (as much) about project or product management (if those exist) approval. They will still have to get approval from committers and others who decide on released features, but the bar will be generally much lower.
In a sense it's analogous to traditional warfare vs. guerrilla or fourth-generation warfare. In the former, a general dictates the strategy and the tactical targets. A battalion leader may do it "his way" and even succeed but that's the exception. In 4GW the individual guerrilla units pursue the objectives they deem most desirable.
On the subject of coding vs. documenting/testing being more or less valuable, the current agile or XP approach takes a different tack. In the traditional approach, you may be required to document first (as in writing a detailed design), but in many (most?) instances people will code first (to the design in their heads) and document later (and any tests will be developed even later, maybe by a QA group). In test-driven development, the emphasis is to first write tests to document expected behavior. I don't know to what extent this practice is prevalent in open source projects or individual contributor habits, but it does change your outlook on what is more valuable.
#1.1.1 Joe on 2009-07-05 08:20
I totally agree with your above statements. Part of my argument was that while PostGIS is garnering more cathedral like qualities, that doesn't mean we've become super austere and require the level of dictatorship that a hmm Microsoft or Oracle does. We still want to maintain the spirit of freedom and allow people to work on what they want to.
Many patches we will reject because they don't jive well with the rest of our code base or require additional dependencies we don't want to introduce. Just like PostgreSQL does the same. Tom Lane is very critical of patches,and that is a good thing. It makes users confident that there is a certain level of quality/cohesiveness we demand. I would say the same for Linux -- Linux was successful early on because while there was freedom -- people knew there was a Linus Torvalds out there monitoring the patches for their suitability -- e.g. doesn't break an patent laws, doesn't have holes etc. His rejection reasons I would imagine were very well defined such that people couldn't accuse him of being unfair. So he in essence added the light handed Cathedral to the Bazaar. Also most open source projects only allow a few committers (gatekeepers) who accept patches from others.
But my more important point is that I think we are also moving toward a more bazaar model (something that was missing in Paul's blog entry). By that I mean by coming up with better ways of stress testing the system, we can be more reckless in our changes and still maintain a fairly stable code base that people won't be afraid to try. By strengthening our tests we will more likely catch a line of code that breaks 20 other areas of functionality or breaks on one OS. By making documentation of a new feature immediately available as soon as a feature is added and prominent in our documentation, we can get more people excited about testing out these new features.
Coming up with ingenious ways of testing and documenting is a very fun and fulfilling job I think and sadly that is what is missing in many open source projects when people are only respected for the amount of code/features they add to a codebase.
#220.127.116.11 Regina on 2009-07-05 22:00
Syndicate This Blog
Show tagged entries