O'Reilly Digital Media

Related link: http://www.artima.com/intv/metadata.html

Related link: http://www.xiph.org/press/2003/nonprofitspeex1/

Today the Xiph Foundation announced
that they have completed their application for their 501(c)3 tax exempt status and are now fully recognized as non profit and tax exempt by the IRS. The creation of a non-profit corporation and the immense amount of paperwork required to file for the tax exempt status are a significant investment of time and money — the Xiph folks should be commended for their efforts.

As far as creating a legal shelter and a business entity for an open source venture is concerned, there is no better match. As Open source projects get larger the developers tend to expose themselves to greater liabilites and should seriously consider some form of legal shelter for their project. Normal for-profit businesses are easy to setup (at least here in the U.S.) but often are not a good match for the projects they house. The open source community tends to be mistrusting of for profit companies and would rather support a business that is more closely aligned with the underlying philisophies of open source.

The philosophies of most open source projects are not about making money, but about providing a product or service to the public, which matches the IRS’ description of a tax exempt venture perfectly. However, non profit does not mean not earning money — on the contrary. Non profits are free to earn money as a regular businesses do and to use the proceeds from this business support the people who work for the company. Non profits do not have shareholders and thus cannot pay dividends and therefore any excess money generated must be plowed back into the company or donated to other non profits.

Unfortunately, in order to qualify for tax exempt status an ungodly number of confusing and contradicting requirements need to be met. The public support test for qualifying for a Public Charity (which is what open source projects would want to do) are confusing and in most cases hiring a lawyer is advisable.

Despite the hassles and costs of creating a tax exempt non-profit corporation, the number of open source non profits is on the rise. The Xiph Foundation is probably one of the most prominent recent creations that fits into this category. The FreeNode folks have also taken this route to provide IRC services to open source community. Brandon Wiley’s Foundation for Decentralization Research is another good example.

Personally, I think that the trend towards non-profit corporations in the open source world is a positive sign that the open source movement is evolving to the next step. And evolving into the antithesis of everything the .com world stood for cannot be a bad thing. :-)

Are you thinking of creating a non-profit? What have you learned so far?

Related link: http://www.atnewyork.com/news/article.php/2107891

In recent weeks after the MusicBrainz launch I’ve been talking a lot about the project and answering questions. One of the frequent questions I have to answer is about the possibility of me selling out the project and taking my wad of cash and moving on to the Bahamas. After CDDB turned from an open source project into a fiercly protected closed enterprise this is a valid question for people to ask.

Joi Ito recently asked me the same question and I rattled off my typical answers of mirroring the data far and wide and designing the system so that in case I (or someone else in my team) decides to sell out that the system could route around the problematic nodes in the system.

We then proceeded to talk about using Emergent Democracy techniques for electing a new leader in case the current leader sells out. The key here is that the community of MusicBrainz users is more important than the technology that powers the project. So, in order to have a truly effective defense against the leader selling out, the project must ensure that the community would not blindly follow the compromised node as it happened with CDDB.

Source code escrow projects like O-STEP that encourage companies to place source code to into escrow for release in 2-3 years later are a great start. However, O-STEP will not be able to help with placing a whole community into escrow. What needs to happen is that projects that rely on their communities need to be able to place domain names and private user data (passwords, email addresses, etc.) into escrow.

When a project leader sells out, the rest of the project members can turn to the escrow agent to release the domain name and the private data to the new leader so that the project can continue. The domain name gets routed to the newly elected hosts and the private user data gets loaded into the newly elected leader node and life continues as if nothing ever happend. If this sytem is swift and effective the community may not even notice that something went horribly wrong with the open project.

I see the need for these services arising as more community sites emerge. But, who will provide such services? Who do we trust enough for us to assign control over our domains? And more important still, who do we trust enough to escrow private user data? The FSF? Creative Commons? The EFF?

Who will be the guardian/watchdog of open communities?

Related link: http://www.artima.com/intv/fixit.html

Artima.com has published an interview in which Pragmatic Programmers Andy Hunt and Dave Thomas talk about software craftsmanship and the importance of fixing the small problems in your code, the “broken windows,” so they don’t grow into large problems.

Here’s an excerpt:

Dave Thomas: It comes down to showing that you care. Take for example some code that is kind of shared among the team, but primarily is mine. There’s some code in there that is obviously bad, but it doesn’t look like I care about it. I’m just leaving it bad. Anybody else coming into that module might say, “Well, Dave doesn’t care about it. It’s his module. Why should I care about it?” In fact, if you come into my module and do something else that’s bad, you can say, “Well, Dave doesn’t care. Why should I care?” That kind of decay happens to modules as well as apartment buildings.

On the other hand, suppose I notice an edge condition that doesn’t work in my code. I know it’s a bug, but the bug is not critical to the application today and I don’t have time to fix it. I could at least put a comment in there. Or, even better, I could put assertion in there, so that if the edge condition ever hits, something’s going to happen that shows I’m on top of it. By doing that, first of all I make it easier to identify the problem. But I also show other people that I care about that enough that they will fix problems too when they encounter them.

Andy Hunt: If you walk into a project that’s in shambles — with bugs all over, a build that doesn’t quite work — you’re not going to have incentive to do your best work. But, if you go onto a project where everything is pristine, do you want to be the first one to make a bug?

Related link: http://www.artima.com/commentary/langtool.html

Artima.com has published a short article suggests that not only can systems and scripting languages co-exist in the enterprise, they can co-exist to great advantage in individual developers as well.

Here’s an excerpt:

To me, attempting to use one language for every programming task is like attempting to use one tool for every carpentry task. You may really like screwdrivers, and your screwdriver may work great for a job like inserting screws into wood. But what if you’re handed a nail? You could conceivably use the butt of the screwdriver’s handle and pound that nail into the wood. The trouble is, a) you are likely to put an eye out, and b) you won’t be as productive pounding in that nail with a screwdriver as you would with a hammer.

Because learning a new programming language requires so much time and effort, most programmers find it impractical to learn many languages well. But I think most programmers could learn two languages well. If you program primarily in a systems language, find a scripting language that suits you and learn it well enough to use it regularly. I have found that having both a systems and a scripting language in the toolbox is a powerful combination. You can apply the most appropriate tool to the programming job at hand.

Related link: http://www.artima.com/webservices/articles/whysoap.html

Artima.com has published an article that compares SOAP and application-specific XML for web services interaction, and suggests that for many web services SOAP is overkill.

Here’s an excerpt:

For many Web services, you need only a combination of XML, HTTP, and an application-specific message protocol. To be sure, SOAP has its uses. But, in my opinion, SOAP’s role is overstated in the early stages of a Web service’s development. Using SOAP for the wrong tasks can easily hijack a Web service development project, because SOAP introduces a large set of problems that are orthogonal to the challenges of building a Web service. SOAP-related issues tend to consume the majority of the development effort.

The most common purpose of Web services today is to exchange XML data. For instance, more than 200 Web services listed on XMethods share that purpose. The classic examples of a stock quote service, weather service, or postal code lookup service are all about sending an XML query message, and receiving an XML reply. That pattern dominates more complex Web services as well: the UDDI registry service or the Liberty Alliance single sign-on and identity federation Web services are all defined in terms of XML-based query-response message exchanges.

At best, SOAP introduces a level of indirection to such XML message exchanges by embedding an XML message in a SOAP envelope. Since the SOAP envelope can carry metadata about the original XML message, such as processing instructions, the envelope can aid a Web service in processing that message. At worst, SOAP makes it difficult, if not impossible, to verify the validity of an XML message traversing between two Web services.

Related link: http://www.gonze.com

MusicBrainz uses audio fingerprints as primary keys to link metadata from different rips of the same song. To do this it uses a toolkit called TRM from a company called Relatable. TRM ids have severe drawbacks.

One, TRM generates way too many false negatives. In my testing I found that it was barely better at finding duplicate files than a byte hash like sha1. Two, it is closed source and probably encumbered by patents, so it can’t become an open standard for audio fingerprints, and it can’t be tweaked to support the needs of third party applications.

It’s extremely clueful for MusicBrainz to use audio fingerprints for primary keys, a genuine innovation even. But MB is a metadata project, not a fingerprinter, and they couldn’t use an better fingerprinter because one doesn’t exist.

Details on my weblog.

Related link: http://www.artima.com/intv/fixit.html

Artima.com has published an interview in which Pragmatic Programmers Andy Hunt and Dave Thomas talk about software craftsmanship and the importance of fixing the small problems in your code, the “broken windows,” so they don’t grow into large problems.

Here’s an excerpt:

Dave Thomas: It comes down to showing that you care. Take for example some code that is kind of shared among the team, but primarily is mine. There’s some code in there that is obviously bad, but it doesn’t look like I care about it. I’m just leaving it bad. Anybody else coming into that module might say, “Well, Dave doesn’t care about it. It’s his module. Why should I care about it?” In fact, if you come into my module and do something else that’s bad, you can say, “Well, Dave doesn’t care. Why should I care?” That kind of decay happens to modules as well as apartment buildings.

On the other hand, suppose I notice an edge condition that doesn’t work in my code. I know it’s a bug, but the bug is not critical to the application today and I don’t have time to fix it. I could at least put a comment in there. Or, even better, I could put assertion in there, so that if the edge condition ever hits, something’s going to happen that shows I’m on top of it. By doing that, first of all I make it easier to identify the problem. But I also show other people that I care about that enough that they will fix problems too when they encounter them.

Andy Hunt: If you walk into a project that’s in shambles — with bugs all over, a build that doesn’t quite work — you’re not going to have incentive to do your best work. But, if you go onto a project where everything is pristine, do you want to be the first one to make a bug?

Related link: http://www.artima.com/commentary/langtool.html

Artima.com has published a short article that suggests that not only can systems and scripting languages co-exist in the enterprise, they can co-exist to great advantage in individual developers as well.

Here’s an excerpt:

To me, attempting to use one language for every programming task is like attempting to use one tool for every carpentry task. You may really like screwdrivers, and your screwdriver may work great for a job like inserting screws into wood. But what if you’re handed a nail? You could conceivably use the butt of the screwdriver’s handle and pound that nail into the wood. The trouble is, a) you are likely to put an eye out, and b) you won’t be as productive pounding in that nail with a screwdriver as you would with a hammer.

Because learning a new programming language requires so much time and effort, most programmers find it impractical to learn many languages well. But I think most programmers could learn two languages well. If you program primarily in a systems language, find a scripting language that suits you and learn it well enough to use it regularly. I have found that having both a systems and a scripting language in the toolbox is a powerful combination. You can apply the most appropriate tool to the programming job at hand.

I just received a press release from Robin Gross of IPJustice that Jon Johansen is being retried in Norway. Prosecutors appealed his acquital by a lower court, and the appeals court found problems with the application of the law and presentation of evidence. The new trial starts this summer.

In her press release, Gross notes: “Brought under Norwegian criminal code section 145.2, which outlaws bypassing technological controls to access data one is not entitled to access, the charge carries a penalty of two years in prison. This case marks the first time this law is used to prosecute a person for accessing his own property. In the past, this data theft law outlawed accessing another person’s bank or phone records, or other data that one has no lawful right to access.”