ArsDigita Archives

ArsDigita Mission Statement

Why we exist

Why do we exist as a company instead of as individuals? Each of us certainly should be good enough to make $1000/day or more as an individual consultant. We have banded together so that

  • we can build the world's best toolkit for building Web-based collaboration systems (useful for education, working together, and commerce)
  • we can apply this toolkit to the development and operation of some of the world's most interesting Web services, ones that often change users' ideas of what the Internet can do (see for an example)
  • we can distribute our toolkit as revolutionary open-source free software
  • we can operate the world's best mass-customized application service provider. It is client projects that fuel our toolkit development with ideas and money. To do these projects it is important that
    • we can share the responsibility for maintaining servers and RDBMS installations
    • we can convince people to hire us for larger jobs and hosting; customers have to know that a member of the Boston Team can cover for a member of the San Francisco Team who is on vacation
    • we support each other with complementary expertise
    • any of us can go on vacation for a few weeks without a customer being adversely affected

    (remember that most of our customers are venture capital-backed startup companies that live or die by the Web service that we've built for them OR Fortune 500 companies without much tolerance for downtime or failure)

Technical Goals

An ArsDigita-built site should be

  • responsive to users
  • easy to navigate
  • clean
  • a useful service
  • personalizable

What control do we have over these items when we're building a site for a customer? Mostly we have to exercise this control going in. We should turn down simple advertising splash sites that don't perform some useful service for the general public. We should also try to avoid simple e-commerce sites unless they go far beyond the simple catalog sales sites that we were building back in 1995. We should avoid intranet sites unless it is something that will be of use to many similar companies and we retain all rights to the source code and can give it away. Otherwise, the intranet site will be visible to only a handful of people and will not serve as an advertisement for ArsDigita. These kinds of sites will increase our sales and marketing expenses (currently very low because we've done so many high-profile public sites whose excellence and complexity is apparent to potential customers).

Bottom line? If ten years from now you ask a user to name ten sites that changed his or her idea of what the Internet can do, we should have built three of them. If ten years from now you run into a programmer on the street, half the time that person should say "I've learned a lot from your [site, book, source code]."


We do not expect to grow to the size of the world's largest technology companies, e.g., HP, IBM, Microsoft, Oracle. Yet we want to have a larger positive impact on the world than any of these companies. The only way that we can achieve this is by educating other people. Part of our mission at ArsDigita must therefore be to

  • educate people by building great sites; someone who has used the Q&A forum at would probably end up building better discussion software even if he or she never downloaded our source code. This is another argument in favor of building high-volume sites. Vastly more people will experience than will visit the average ecommerce site.
  • educate people by distributing knowledge and ideas in the form of books, e.g., Philip and Alex's Guide to Web Publishing should be merely the second of many interesting book-length technical documents
  • educate people by preparing courses that we can give face-to-face, at MIT and Caltech and on the road; make the materials for these courses available on the Web for free so that other people can use them to teach face-to-face classes or learn on their own
  • educate people by distributing open-source software that will help them build whatever Web services they wish
  • make our community toolkit ever more useful for educationally-flavored communities (which is where it started after all); this way our software will have a positive impact in educating high school kids about science, Harvard and MIT students about various subjects, people worldwide about photography, etc.

We don't have to be 100% altruistic. If a Fortune 500 company wants to sponsor one of our classes and cover the costs, we take the money. But we don't have to be 100% greedy either. If a girl in India wishes to learn what we know, we don't charge her. We do a reasonable amount of work to support her effort, e.g., by making sure that our public Web material is current and complete.

Corporate Culture

Our first principle is that we do not lie to customers. If a service goes down because of something we did wrong and should have known not to do, we tell the customer exactly what we did wrong in as clear language as possible. Even if the customer might not know that this was a stupid thing to do under Unix or Oracle, we explicitly tell them "this was a stupid thing to do." If we slacked off and partied all weekend and didn't finish some work that we promised, we admit it rather than conjuring up mythical technical dragons to slay. We do not take advantage of customer ignorance to hide our mistakes, a practice that is depressingly widespread in our industry.

The above principle is non-negotiable and we must not ever get away from it. If it means we sometimes have to eat a month's hosting fee (our standard means of self-flagellation), I think that in the long run we might actually save money from adhering to a strict no-lying policy. For example, if we were to develop a broad set of corporate lies, we wouldn't be able to let new hires talk on the phone with customers until we had spent a few days training them in the official lies.

Beyond that, we don't worry about corporate culture. We have a certain set of customers. We have a certain set of people. We have a certain set of tools. Discussions or theories won't change any of those things. If any ArsDigita member wants to change ArsDigita, he or she need only add to the customers, add to the people, or add to the tools.

Compensation Principle

We do not skim money from each other. People should get paid according to their contributions to projects and the company. Here are the elements of a typical ArsDigita project:

  • landing the contract
  • hosting the site (requires buying hardware, negotiating and paying for colocation space, negotiating and paying for RDBMS licenses and support)
  • training any new programmers who've been brought into the company to handle this project
  • custom development and extensions to the toolkit
  • managing the customer, e.g., helping the customer evaluate alternative design and service ideas
  • more senior ArsDigita members will do code review, pitch in when the customer calls and the main developers are on vacation, help out when the developers get stuck
  • working the generically useful portions of the new software into the toolkit
  • documentation, documentation, documentation, both for the customer who paid for the project and to go out with the toolkit

All of these activities are compensable.

Goal for each Member

Each member of ArsDigita is eventually expected to become an internationally famous Web developer capable of managing an entire project from start to finish. That doesn't mean that each person needs to acquire all the skills necessary for a site, but he or she has to understand what skills are necessary and where to get them within ArsDigita.

Obligations to other Members

We live or die by customer satisfaction. It is safe to assume that the customers' priorities are (1) getting down services back up, and (2) getting new services developed on time.

From these priorities, we can infer that the first and primary obligation of an ArsDigita member is to preserve the reputation of ArsDigita by pitching in to get a down service back up. It doesn't matter whether this is a service that Member X has worked on or whether it is even our fault (e.g., it might be a hardware problem and the action that Member X has to take is calling 1-800-USA-4SUN to get the Sun Microsystems guys over).

The second obligation is to help other ArsDigita members look good on development projects. So, for example, the senior nerds must help the junior nerds tune their SQL and clean up a page by using an outer JOIN.