Forum OpenACS Q&A: Best Practical - A Successful Open Source Company Inspires

Yesterday me and Lars listened to a speech given by Jesse Vincent on Open Source and his company Best Practical and its product the Request Tracker (Ticket Tracker), written in Perl, used by the Perl project and by numerous major corporations, see the Praise Page.

Jesse is running Best Practical as a true networked company, has no office, resides in Sommerville (Boston) and uses 7 experienced contractors (Perl hackers) on a project basis across the globe.

What are some of the lessons to take away from the Request Tracker for OpenACS? Here are some ideas:

  • Problem and feature focus. ArsDigita and the ACS have been trying to solve too many problems with limited resources and the result is mediocre, or possibly high quality but unfinished results in many different areas (ecommerce, cms, collaboration etc. etc.).
  • Application and end-user focus. Eventhough Jesse is a technical guru he knows to value the end users and to cater to their needs. It's not which programming language you use that will influence your success most (Java, .NET, Tcl, Perl, Python etc. can all get the job done) - it's the end user experience.
  • Instant gratification. The system should be easy to install and give you something useful out of the box. The product should be accompanied by professional user and admin documentation by a tech writer.
  • Open Source software can beat the commercial market in the end-user application domain and it only takes one good and dedicated person to make it happen.

On a side note, the RT praise page has reminded me that we really need to get our case study / testimonial page up for OpenACS soon. It think it would help sell OpenACS a lot. All we really need to start the page off IMHO is a little blurb (a paragraph) and a screen shot per case.

One more thing before I forget - Jesse mentioned two interesting ideas to preserve upgradability: overlaying template files, and pre and post procedure callbacks (ability to execute code before and after a kernel proc is invoked without touching the kernel code). Something to think about for us perhaps.

Hey Peter!
great info, thanks. Will be nice the next time that you know or someone else in the community about an online event that is worth to hear, to announce in the forums or in the news.

I'm complete agree with that thoughts, is better to grow a company in the way of having a good amount of external consultants (this will make openacs community stronger, and that also makes your own business stronger) nowadays the internet enable it, you get great thoughts (because they are not fully related to your business), high motivation, and is a better business model for small companies.

About the comment on end-user & application is true. You can sale rocks!, but for a long term relation with clients first you need to care about the relationship, have a great customer service that is related in how much you really care about them, and this is where the final user don't care about programming languages or good design thing, they care of having something that they like (an here really influence an attractive UI) and gets the job done. As a company you really care for doing the things good (just makes your life easier).

Finally, there is no better way to make someone (your client) to take a decision for hiring your services than showing them a good list of happy and recognized customers (that makes them to feel that the risk in the decision is lower or almost doesn't exists)

One more thing before I forget - Jesse mentioned two interesting ideas to preserve upgradability: overlaying template files, and pre and post procedure callbacks (ability to execute code before and after a kernel proc is invoked without touching the kernel code). Something to think about for us perhaps.

The message interceptor concept is naturally supported in xotcl. Having said that, I have thought of implementing this into the service contracts package -- eventhough, it won't be a solution as good as xotcl it is the closest it gets with the current suite of tools we are using.

Making a slight change to ad_proc, so you can tack code onto it before or after would be pretty simple. Would let you say something like

ad_extend_proc (name-of-proc) before/after { doc } { code }

Problem of course is with functions which return a value. They'll have a "return" somewhere inside of them, and we'd need to figure out whether we'd let code attached to the end intercept that return value and change it, etc.

Also possible would be ad_replace_proc (name-of-proc) { doc } { code }


To those interested in RT,  Jesse is speaking in Cambridge/MIT on the same topic on 5/21:

I'll see you there if you go.

Also,  as an aside,  note that Request Tracker uses FastCGI for high performance web server portability.  Hmm...  😉

Anyone interested in dinner at Mary Chung's before hand?
<blockquote>> Also,  as an aside,  note that Request Tracker uses FastCGI for high performance web server portability.  Hmm...  😉 <<

Exactly. In fact, Jesse made it clear that he charged very little for installation support, because even if he didn't make any money, at least his competition wouldn't make any money either, and he'd have one more potential customer for later.

That's a pretty clear argument for why ease of installation is critical.

So how far is OpenACS on FastCGI away?


Posted by John Sequeira on
Currently,  I'm plugging away on making Oracle support smooth.  The FastCGI part is pretty stable,  with the limitations noted below.  I expect most of the limitations to go away when,  as Don and Andrew suggested,  I replace nstcl calls with calls to the unbundled AOLServer libraries. I'm crossing my fingers that they expose the template engine.

I programmer days,  that's a few weeks of work away.  I calendar days,  well,  you know how it goes with open source.  I'm shooting for June.

RELEASE NOTES for portable.nsd 0.7b


tclsh support for headless OpenACS code is quite good.  This means that writing tclsh installers,  running OpenACS scripts as cron jobs,  debugging them with TclPro, running inside Postgresql using pg/tcl etc. should work fine.  The most problematic routines revolve around HTML generation,  because they often interact with the template engine in ways not directly supported by nstcl.  Also, that seems to be where the most churn has occurred in OpenACS long history.

tclhttpd support is experimental.  It has not been extensively tested, and since it doesn't handle garbage collection.

FastCGI support for AppClass connections is broken due to a Tcl feature that has since gone unmaintained.  FastCGI External Server (TCP/IP) connections work well.  In practice that means that you can have a single Tcl interpreter sitting behind a single web server.  To make this perform acceptably you would want to use some sort of round robin proxy or load balancing.  AppClass connections can be set to recycle after a certain number of hits,  which means they would work well even without robust garbage collection.

All portable.nsd code assumes it's running in a single-threaded interpreter.  FastCGI is designed to handle this scenario,  but it puts serious constraints on implementing OpenACS+pnsd in native/threaded web server API's like Apache's mod_tcl and IIS's Active Server Pages.  Much of the AOLServer support for thread-safe globals has been implemented as simple globals,  which would choke mod_tcl and ASP.

Cache synchronization has been implemented by simply reading and writing cached values to the database.  This obviously doesn't really give you the speed increase of an in-memory cache,  but I believe between tequila or Michael C's shared nsset's (or shared memory, or tuplespaces etc.) this problem is solvable.

ns_xml has been replaced by tDom calls.


* portable.nsd only tested with postgresql 7.2.3  and OpenACS 4.5 at this time.  The majority of the framework is more concerned with web connectivity,  and is database agnostic.  I don't expect 4.6 support to be too painful,  but haven't tried it.

* right now only the tclhttpd implementation supports serving non-HTML files (ad_returnfile).  Apache supports it indirectly using mod_rewrite directives.

* Memoization and ns_cache have not been tested yet in a cluster.  ns_cache has been implemented using a database lookup table, so it's not the best performing.
* ns_register_proc, ns_register_filter, ns_register_adptag are not supported. This means ad_form is not supported.

* lobs are not supported by nstcl.  The underlying database libraries (ligpgtcl and oratcl) support them, so we just need to expose the functionality.

* no load testing has been performed.

John Sequeira