Socialtext

User Centricity in Socialtext-Hosted Software

Socialtext hosts a number of wikis, a number of which I've participated in over the years. One thing I've noticed is that I only have one login for all those wikis, and thats something I really like. In the identity community, that sort of thing we call "user-centric identity" because it acknowledges that the interests of users in maintaining their online identity should be an important factor in designing systems.

Details

Socialtext offers software (currently a wiki, but soon many other components) as a service. Socialtext customers either pay for a hosted wiki (on socialtext hardware at a colocation facility) or a appliance running the wiki that physically lives on the customer's network.

In the case of the hosted service, account management is user-centric (at least partially) because the user has one identity across all wikis, no matter who the customer is that is paying for each wiki. Consider a traditional multi-tenant architecture, where the user records, along with all other records, would be kept separately for all instances of the software. As a user of such a sytem, I would have to "create a new account" for each software instance hosted in a separate partition. Thats almost user abuse! And Socialtext shows that you can do better.

Having this sort of user-centricity has other upsides beyond user convenience:

• A customer (the organization paying for the wiki) need not require users to create Yet Another Username and Password (YUAP). As long as a user (end user) has previously been a member of a Socialtext-hosted wiki before, they can simply click on an accept link (in an invitation email) or otherwise go to a wiki they are newly invited to.
• Socialtext hosted appliances can easily be OpenID Relying parties -- users wouldn't even have to create Socialtext accounts at all.
• Customers don't have to deal with the support costs of user confusion from having multiple logins for different wikis.
• Socialtext has the ability to give a user an overall unified view of their participation in Socialtext-hosted wikis. This will likely soon extend to social activities other events in an around Socialtext products.

I'd note that this "unified identity" across a hosted platform is similar in spirit to the Facebook platform that provides a single identity for its users across applications (namely, the FBID). While that identity system is "Facebook-centric", it is evidence that "ownership of identity" by applications is being seen as a cost that can and should be shifted elsewhere. And we're also getting to a place where users will have power to make decisions about how they identify themselves wherever they go. Its not just about social networking sites anymore...

More coming from Socialtext on this soon!

• Permalink  |
• Comment here

Socialtext has always been a perl shop. Traditionally, all the developers do perl, and the entire product has been built in perl (and HTML/Javascript/CSS in the browser, of course).

Thats changing with Socialtext People - a component written in Python. A project was undertaken to prototype the project in Python, and recently the question has arisen within the developer ranks: if almost all of the developers in the company are perlheads, and few have significant Python experience, shouldn't we just port the Python work back into Perl in the long term?

Here's several reasons why not:

1. The python is perfectly functional and there's no functional reason to reimplement it
2. Python itself is a terribly easy language to pick up, especially if you have previous programming experience.
3. The Python ecosystem is much more active than that of Perl these days, at least from what I've seen. It seems to me that there are a lot more of Python application developers in the market. I'd feel more comfortable as a hiring manager looking for application developers who have experience in Python than looking for developers who have Perl app dev experience.
4. A benefit of building with two dynamic languages is that it forces Socialtext developers to live in the chaotic world of heterogeneity and understand the enterprise customer's IT pain. The challenges with LDAP integration are a good toe-dip into this morass, but forcing adherence to (REST) interfaces by virtue of different language environments (including AJAX widgets) is a huge win on this angle.
5. The integration (both physical and logical) of the python and perl components is surfacing some architectural issues and providing motivation for some decomposition of the NLW Perl code. There seems to be universal agreement that the nlw blob is simply too big and impenetrable -- hopefully with external components that can't simply integrate via code hooks, there'll be more motivation to tease out some of the functionality even within the Perl codebase itself (handling of people profile data is a good example). Its very hard in an agile, incremental product development environment to take on architectural refactoring tasks - my hope is that the python work forces some of this work to happen.

Gabe, what are some of the reasons we would want to re-implement it in perl?

I think your point #3 is promoting more myth than fact. Perl jobs and perl developers are very numerous, and the perl community is tremendously active - CPAN is more active than ever.

I don't know where I stand on this particular issue for the Socialtext People module - I probably will go along with the status quo until something changes. I agree that all of our developers can likely hack on the people python code. My only concern is with the code duplication and deployment complexity.

contributed by Luke Closs on Jun 16 11:34am

Luke- I had the most hesitation in writing #3 because it was sure to engender this response, whether I was right or wrong.

I really wanted to avoid a language war post - the main point was that diversity in environments actually has its pluses. It helps to force open APIS and data formats over code. Contracts/agreement and documentation over "just read the source", etc... its more how the real world works.

contributed by Gabe Wachob on Jun 16 1:04pm

We're currently using ~100MB per pre-forked Apache process to run mod_perl+perl-code+data and another ~100MB on top of that to run mod_wsgi+python+data. From an "interpreter memory overhead" standpoint, it makes sense to have just one interpreter.

Maybe we can compile both to parrot, CIL or JVM-bytecode ;)

contributed by Jeremy Stashewsky on Jun 17 9:14am

• Permalink  |
• Comment here