Enabling Collaboration: A Wiki Success Story

How did a single team’s documentation wiki grow into an essential piece of the organization? By carefully crafting a reliable and flexible tool, everyone learned the benefits of shared knowledge. While our specific situation refers to a MediaWiki implementation within our organization in the year 2011, the concepts outlined could likely extend to any collaboration tool now and in the future.

A Netted Garden

Before the adoption of the current organization wiki, a previous iteration of a web-based wiki existed for a single team. The old wiki was riddled with access control lists and restrictions. To even start viewing it, you needed to be manually added as a user. Hardly simple or friendly.

When the new system was pitched, it was decreed that the information would be opened organization wide. No restrictions anywhere. Why hide system administration details from the developers or vice versa? Even if a member decided to vandalize other groups documentation (purposefully or accidentally), all changes are audited along with built-in versioning for easy rollbacks.

We offered open guidelines for creating useful and consistent information architecture, but did not slap on restrictions except for obvious cases (not posting passwords, etc.) for security. The system now thrives on this flexibility. All members of the organization have become content curators. Iteratively, the service becomes more valuable to everyone.

How Did It Grow?

Easier to say than achieve, we gathered people on a common language built around simple, easy to access information. In our case, a web based wiki provides a common denominator of no proprietary software restrictions and global access. When a product can stay out of the way to let people get done what they need to get done (in this case documentation) it becomes synonymous with the workflow.

We created a community where it allowed the collaboration tool to become popular, naturally. Strong-handedly forcing adoption of tools leads to skeptics and outliers. If it’s worth its weight to the organization, they will flock. Flock they did. You know you’ve made it when your product becomes subconscious to those involved, like how many people will go straight to specific friends or websites to find what they need without giving a second thought.

Blurring the Lines

Allowing the wiki to grow naturally gave credence to the idea that centralized, yet open documentation is useful to the organization. With more eyes on the documentation, now anyone can see how other groups operate and improve any service by offering suggestions or prototyping. We’ve seen many cases where developers from one group will comment and help others. Physical location no longer applies. This leads to blurring the notion of organizational silos.

Creating Value for Everyone

It was very simple just to offer the service internally to just our department as a single instance, but why stop there? We opted for a modular design where new wikis (for other departments or very specific needs such as a wiki for a class) can be added simply. This modular design benefits with automated maintenance tools (backups, upgrades, etc.) and shared blocks of configuration (authentication, extensions, etc.) developed to simplify and solidify the environment’s operation.

Stand By Your Product and Depend On It

Our wiki has become a central documentation tool for everything from information about applications and services to disaster planning. Now think about that last one for a second. When disaster strikes and knocks out the wiki, how will everyone get their documents? It is about preparation for all scenarios.

  • A localized, server confined disaster where the system crashes or data on it becomes corrupt
  • A localized, external disaster where there are issues with the hosts, storage, network, cooling, or power within a rack or the whole data center
  • A regional, external disaster affecting multiple (or maybe all local) sites

Let us get technical with our MediaWiki implementation and disaster mitigation. While the standard product does not offer any built-in options for high availability out of the box, we architected multiple recovery schemes for the above situations.

  • Standard daily off-server system backups to disk and tape
  • Application layer backups (MediaWiki XML)
  • Database layer backups (MySQL dumps)
  • Database layer replication (MySQL)
  • File layer replication (rsync)
  • Message with recovery instructions for administrators logging into the system directly

Most importantly, the powerful combination of replications allows us to simultaneously run warm spare server(s) in other data centers on or offsite for a really quick return to operation time. The last item is for the panic moment of failing over the system if necessary (to enable write access, read access is available on standby systems at all times). Having the instructions outlined provides a sense of relief in the face of a larger crisis.

Parting Thoughts

No product should be developed by one person or small, exclusive group. Customers can be your best developers, even if they are not touching the actual code or configuration. Listen. React. Be proactive for demands they don’t know they have yet. Grab enthusiasts and hack away at new models. For experimenting with the new, release early in development and iterate away. Sometimes your final product will look nothing like it started. This is always for the better.

The continuing success of our wiki environment is because of the collaborative nature of the tool itself. When colleagues are discussing the documentation available on there, it has migrated from “your” information to “our” information. There is immense power in that statement. Empowered people will add their creative and experiential input. We all win.

Key Insights from the 2011 Wharton Web Workshop

The Experience

I had the pleasure of participating in this year’s Wharton Web Workshop (OPIM654), led by Professor Karl Ulrich, out in San Francisco. For the third year in a row, this workshop offered an unique experience where Wharton Executive MBAs, Wharton full-time MBAs, and Wharton Computing developers could combine talent and energy into creating web-based businesses within a 4 day period. The workshop has garnered attention from the public media in the past and this year was prepped to be no different.

Using methods derived from Professor Ulrich’s real world experience with web startups as well as backed research featured in his book, Innovation Tournaments, students and staff were able to share knowledge and pitch ideas in an open forum filled with motivation. Guest speakers for the workshop included venture capitalist, Rob Coneybeer (blog), as well as the CEO and founder of milo.com, Jack Abraham, who both offered their stories and graciously fielded questions.

With roughly 45 participants armed with ideas at the onset (web-based business proposals needed to be ready before the workshop began), the first, 60 second idea pitches brought a whirlwind variety of topics. Voting was as intense, only to get more excruciating as the pool was cut down to 24, 12, and then the final 7 teams.Each level increased the pitch time and material, requiring longer nights as the week progressed towards a partially designed mockup design (via Balsamiq Mockups and other tools) and the finish line, an online, prototype website for the proposal. Many teams were working early into the final morning, touching up the user interface and experience for the prototype websites. Participants then were asked to send messages to family, friends, and colleagues to drive traffic to the splash page with links to the final team websites. In less than 6 hours, more than 1,000 unique visitors toured the website according to Google Analytics tracking and left feedback for all the teams.

The final topics required a breadth of talent and knowledge from the students as well as the developers. Ideas from iPhone applications to faceted searching to real-time social media data were modeled using a wide variety of web technologies including HTML5, CSS3, vendor website APIs (such as the Yelp API and Twitter API), jQuery, Ruby on Rails, and Heroku. Participants learned important concepts such as information architecture, user interface design, and technical development hurtles that would be present in any real world startup. All in all, the workshop provided a fun environment for talented individuals to collaborate and experience the web-based business world in a new light.

Key Insights

Before the end of the workshop, Professor Ulrich solicited feedback from the participants which included:

  • You don’t have to be the first to market for an idea, if your experience provides many more benefits.
  • Fundamentally, it takes more than just ideas to get a web-based business prosperous. It’s the combination of ideas, execution, and the “weather.”
  • Start simple and iterate.
  • Keep your pitch or idea simple.
  • Choosing the proper technical team is key.
  • Creating lists of needs versus wants.
  • Understanding the value of deliverables within resource constrictions.
  • Utilizing parallel effort of all team members.
  • Always sell, to anyone and everyone.

Concluding Thoughts

Personally, some of the key takeaways resonate with my developer/system administrator background and within the environment of Wharton Computing. Start simple and iterate reflects the methodology of agile software development. Creating prioritized lists of needs versus wants suits well with resource management and the Getting Things Done methodology. Utilizing parallel effort would include being open with ideas and product development, both in a planning and execution sense (think open knowledge, Wikinomics).

All in all, it was a great experience that I would do again or recommend to any aspiring web entrepreneur in a heartbeat.

When You’re The Bottleneck

It’s a precarious situation when a project or task is being held up on effort by you. Who likes being under the gun with your boss or coworkers standing over your shoulder? While it may seem all negative, there is a silver lining of realizing the potential for growth and organizational respect. Never forget you have many options at your disposal, any of which may change the outcome positively.

Why is this waiting on me?

Seriously take a second and think about this question. Is this an error in the process? Can someone else do this better? Is this something that someone else should be able to do themselves? Am I doing something manual that could be automated? These are all items which are correctable on your part and very rewarding if completed. If you need to put out a fire, put it out, but don’t forget to leave fire extinguishers or hose for the next time. Let’s briefly look at these questions in more detail.

Is this an error in the process?

The process error in this case can be organizational or personal. If projects and tasks always funnel towards you, you should be streamlined to handle them. There are plenty of methods for improving personal processes, whether it be checklists (read: Checklist Manifesto), the Inbox Zero mantra, Getting Things Done applications, the Pomodoro Technique, etc. Find what best fits for your work ethic. Otherwise, focus on allocating more resources or collaborating the issue openly to figure out internal and external alternate solutions when necessary. Along the same lines…

Can someone else do this better?

Be humble and know your abilities. Personal exploration is great and everyone should be encouraged for knowledge growth, but this shouldn’t hold up efforts by others. Delegate if necessary to an expert, whether internal or external. This ensures the quality of the product/service and saves your human capital for your strengths.

Is this something that someone else should be able to do themselves?

When others are technically competent, what good is holding back key information about the task or project at hand that they may be able to handle themselves? Information is power! Providing documentation about how to configure this or process that not only makes your life easier, but also for everyone involved. Now you can take away mental processes from remembering how to repeat an action. Someone else can now easily learn it. Both of which might lead to the added benefit of you or someone realizing a better way to accomplish the same task (or something similar) when it’s all written out. You or someone might even be able to figure out how to skip the manual steps, which leads to the next question…

Am I doing something manual that could be automated?

Spend your time innovating a new product/service or enhancing current offerings rather than the mundane. I’m not going to spend the extra words to reiterate the importance of automation. There are many advocates out there including Wharton Computing’s own Dave Konopka (see: this blog post) and forefront author Dan Pink (read: this book).  Let machines waste time on the boring problems and processes.


Get out there and improve your processes (organizational or personal), delegate to an expert when necessary, document, and automate.

Setting up Gmail as Sendmail Relay

If you’re like me and run servers at home, setting up outbound mail can be kind of tricky. Most likely you’ll want to use your ISP’s SMTP relay server (since some providers like Verizon FiOS block outbound port 25) or use a trusted mailer such as Gmail to forward mail. The steps below outline the second case, where your server will email from a known Gmail address of yours. This gives you all the added benefits of their infrastructure and security implementations (SPF, DomainKeys, etc) which provide a lower spam score.
I’m sure there’s more succinct configurations for Sendmail to provide the same functionality, please comment with better suggestions if you know any.
# On Ubuntu 10.04 in a root shell or preceded by sudo each command...
# install sendmail MSP/MTA and mail utilities goodness
apt-get install sendmail mailutils

# setup local self-signed SSL certificate
mkdir /etc/mail/certs
chmod 700 /etc/mail/certs
cd /etc/mail/certs
openssl dsaparam 1024 -out dsa1024 -out dsa1024.pem
openssl req -x509 -nodes -days 3650 -newkey dsa:dsa1024.pem -out /etc/mail/certs/mycert.pem -keyout /etc/mail/certs/mykey.pem
openssl req -x509 -new -days 3650 -key /etc/mail/certs/mykey.pem -out /etc/mail/certs/mycert.pem
ln -s /etc/mail/certs/mycert.pem /etc/mail/certs/CAcert.pem
chmod 600 /etc/mail/certs/*
cd ..

# configure smtp authentication information
vi /etc/mail/authinfo
AuthInfo:smtp.gmail.com "U:root" "I:USERNAME@gmail.com" "P:PASSWORD"
AuthInfo: "U:root" "I:USERNAME@gmail.com" "P:PASSWORD"
makemap hash -o /etc/mail/authinfo > /etc/mail/authinfo

# add the configurations at the bottom
vi /etc/mail/sendmail.mc
dnl #
dnl # SSL Settings
define(`CERT_DIR', `MAIL_SETTINGS_DIR`'certs')
define(`confCACERT_PATH', `CERT_DIR')
define(`confCACERT', `CERT_DIR/CAcert.pem')
define(`confSERVER_CERT', `CERT_DIR/mycert.pem')
define(`confSERVER_KEY', `CERT_DIR/mykey.pem')
define(`confCLIENT_CERT', `CERT_DIR/mycert.pem')
define(`confCLIENT_KEY', `CERT_DIR/mykey.pem')
dnl #
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl
define(`ESMTP_MAILER_ARGS', `TCP $h 587')dnl
define(`confAUTH_OPTIONS', `A p')dnl
FEATURE(`authinfo',`hash -o /etc/mail/authinfo.db')dnl

# rebuild sendmail config and fire it up!
make -C /etc/mail
service sendmail restart

# test it!
mail -s "Testing new Gmail Forwarding" SOMEUSER@gmail.com
Blah Blah Blah
Please note: you can update the “name” in the address that recipients will see by updating the user’s GECOS…
usermod -c "My Pretty Name" username
Have you setup other MTAs (Postfix, qmail, etc) for Gmail or Sendmail for other mail services (Yahoo, etc)? Please post them in the comments!