Forum OpenACS Q&A: Ignore the competition?

Posted by Dave Bauer on 07/24/06 01:18 PM

Over at Creating Passionate Users (a weblog by one of the creators of the excellent Head First series of books for programmers) is a new post called Ignore the competition. It's a good reminder that the best way to please your users is not to just add all the features the other guy has, but to actually listen and understand what they need the software to do.

I think overall OpenACS has successfully done this, adding features when a client has asked for it, and a personal whim has been fulfilled. This doesn't mean OpenACS _always_ does just what the community asks, but I think, we have overall not added features without any demand from the users. Of course, there has been comparisons to Zope, Plone, recenetly Rails, but the discussions and comparisons always happen, and OpenACS still just goes along at a steady (slow sometimes) pace.

I want to make sure the folks driving .LRN do the same thing, especially in regards to Moodle. Moodle, is interesting, but it is definitely not the easiest and most friendly, system around. It is just different from .LRN, and pretty ,much everything else. That makes it successful because it serves users who have a specific need.

It makes sense for the .LRN community to decide where .LRN should go next, getting an actual release out is a good start! Soon it will be time to decide on what .LRN should become for the future.

2: Re: Ignore the competition? (response to 1)

Posted by Dave Bauer on 07/24/06 01:22 PM

This is so good I am going to quote it here!

1) The Feature Arms Race. We're afraid of falling behind our competitors.

OK, I'd say OpenACS and .LRN don't really do this, even if we might talk about it in the community, the code isn't driven except by actual needs by at least one user.

2) We assume that if one of the leading competitors added something, it's something users will want.

This we might do, but again, usually at least one user asks for a feature before we add it.

3) We assume that potential users will buy off a checklist, and we don't want to come up short in a side-by-side feature comparison.

I think the community again, thinks a checklist is important, but lack of resources naturally limits the amount of unecessary features.

4) We have a compulsive need to add, since the idea of an upgrade that subtracts features seems counterintuitive.

This we do, can't help it.

5) New features are easier to promote than better/working versions of existing ones. Or so we think...

This we do to a great deal and its the greatest problem OpenACS/.LRN have. Always adding new before we fix old bugs. Look at the bugtracker. This includes usability, improving the UI always falls behind adding new feautres, new features never improve the user interface.

3: Re: Ignore the competition? (response to 1)

Posted by Torben Brosten on 07/25/06 05:24 AM

Right.

Sometimes fixing an awkward ui involves more work than adding a feature or two. That seems to be a pattern in most software evolution.

Sometimes a package rewrite provides a way to improve the UI using newer features while re-directing programming efforts to goals of an evolved user base... by listening and understanding end-user needs. Isn't the forums package a rewrite of the bboard package that did just that?

Perhaps OpenACS 5.4 (6.0?) should have a goal of identifying best practices in programing, and then begin an initiative in recycling existing code to meet them. Practice makes perfect! =)

4: Re: Re: Ignore the competition? (response to 3)

Posted by Matthew Dodwell on 07/25/06 11:10 AM

Practice makes perfect! =)

One of the more efficient coding methods is write once, throw it all away and code again. Most of the design issues have been ironed out in the first write an a clean maintainable code solution can be crafted.

Mind you in most of my coding career commercial short-term pressures have meant that the prototype code goes out to the customer and is then patched forever! 😟

Cheers
Matthew