Scott Hanselman

What is Abandonware?

October 4, '06 Comments [7] Posted in Musings | XML
Sponsored By

TumbleweedI referred to MbUnit once as "abandonware" only to be corrected (rightly so) by Andy Stopford (here's a listserv about the issue). In this case, it was not clear at a cursory glance if it was being "actively developed."  Here's some metrics that were provided by Jay Flowers that prove that MbUnit is very alive:

Google Groups:
MbUnit.Dev - 62 Members with 60 posts last month
MbUnit.User - 120 Members with 35 posts last month

8 Dev Leaders with rights to Subversion

Here is the Svn FishEye:
http://www.mertner.com/fisheye/browse/MbUnit

4 Devs committing changes in Aug
264 files changes/28 revisions in Aug

Other folks have done the same thing to DasBlog that I did to MbUnit. Take a cursory glance at the DasBlog SF.NET Projects Page a few weeks back and you'd fine many unanswered questions. In both instances - DasBlog and MbUnit - the project owners needed to take into consideration the external perception by the community of the projects and tighten the screws a bit, all to avoid the label of "Abandonware."

Another word invented by Roy Osherove was "frozeablilty" (or chance of being frozen/abandoned. Perhaps frozeabilitishipfulness is a better word?:

MbUnit is also one of the topics that I continually have a dilemma about using. Since its not the de-facto standard out there, I always feel there's a chance of it being frozen in mid development, making all those who depend on it frozen along with it.

[Update: Andrew, one of the leads on mbUnit,  makes some good points on why he thinks this is far from happening - which is reassuring, and I'd like to hold out longer before making a final call on it's "frozeability".]

Now, we're picking on DasBlog and MbUnit here, but both actively developed projects that aren't abandoned. But let's talk about the real issue. Is software that has been abandoned bad? Is it un-usable? Should we only use software that is actively developed?

Abandonware Example - A .NET Implementation of Schematron

We recently needed to do some data import work, and we were using XML as the source format and XSD to describe the constraints of the validity of the data. Xml Schema isn't well suited for complex data with conditional interrelationships.

For example, if I have a Payment in Xml Schema, it might have a FromAccountID and an optional DateCompleted (and many other things):

 <xs:complexType name="Payment">
  <xs:sequence>
   <xs:element name="FromAccountID">
    <xs:simpleType>
     <xs:restriction base="xs:string">
      <xs:maxLength value="25"/>
      <xs:whiteSpace value="preserve"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:element>
   <xs:element name="DateCompleted" minOccurs="0">
    <xs:simpleType>
     <xs:restriction base="xs:date"/>
    </xs:simpleType>
   </xs:element>
...

But, there's a business rule that indicates that if FromAccountID is "PAID" then there must be a DateCompleted. This kind of condition isn't expressable in XSD. I started looking for other solutions like RelaxNG or Schematron.

Schematron is an interesting spec, but the nutshell explanation is that you can augment XSD with additional assertions using XPath. You can also (with some implementations) include Schematron patterns inside of existing Xml Schemas using the xs:annotation element. Schematron the spec is being actively talked about (article at IBM from this July), commented on by Microsoft PMs (quote from July) but there's a reference implementation using XSLT but it hasn't been looked at since 2001. Some bloggers have commented on the uneven state of Schematron.

I can extend this XSD with Schematron like this:

 <xs:complexType name="Payment">
  <xs:annotation>
   <xs:appinfo>
    <pattern name="Payment Rules" xmlns="
http://www.ascc.net/xml/schematron">
     <rule context="Payment">
      <assert test="(FromAccountID = 'PAID' and DateCompleted) or 
          (FromAccountID != 'PAID')">
             PAID Payments must have a Date Completed
      </assert>
     </rule>
    </pattern>
   </xs:appinfo>
  </xs:annotation>
...

And this simple example gives me the semantics I need and I get output like this from a console test application that are exactly what I need:

Results from Schematron validation
    From pattern "Payment Rules"
        Assert fails: PAID Payments must have a Date Completed
        At: /FI[1]/Relationship[1]/Payee[1]/Payment[2]
            <Payment>...</Payment>
            (Line: 73, Column: 5)

However, doubts about Schematron persist. Uche Ogbuji says:

"It has been a sketchy time for Schematron fans. Rick Jelliffe, the father of Schematron has had pressing matters that have prevented him from putting much work into Schematron for a while. Many questions still remain about the technology specification, and alas, there appears to be no place to keep discussions going on these and other matters (the mailing list on SourceForge appears to be defunct, with even the archives giving a 404. Here are some notes on recent Schematron developments I've come across."

However, it is moving towards being an ISO spec (or may already be?) and there's active talk going on at the SchematronLoveIn mailing list.

There's also a great (but oldish) article on Introducing the Schematron here. Looks like it might be a fine idea. The XSLT implementation worked group, but I also noticed a native C# .NET implementation at SourceForge. This implementation has the very much added benefit of giving me not only an event when a Schematron assertion fails, but also the line number and additional context. However, it's not been touched since 2002.

Is that a bad thing?

I asked the author of the .NET implementation of Schematron, Daniel Cazzulino, what he thought and he said:

"Mmm... schematron is mostly abandoned as the new compiled XSLT in .NET 2.0 makes the need for an "xpath native" implementation pretty much useless. If you use the reference meta-stylesheet and provide a nice .NET API over it (alongside better results reporting, such as an object model that can also be serialized into XML and/or XSLT'ed into HTML reports), you should be OK. And you would be in a better position feature-wise, as I never got to complete support for diagnostics elements, etc., which is readily implemented in the meta-stylesheet."

To translate Daniel's techno-speak into regular-guy-speak he's saying

"Ya, that sucks. You can write a wrapper around this other thing yourself, and that'd be a good idea in the long run, but ya, that sucks."

However, this project isn't using .NET 2.0 (client requirements) and the existing .NET Schematron stuff not only works, but it works great. It's many times faster than the XSLT implementation and did I mention, it's open source. That means, I have the source.

It's not like the Open Source Fairy is going to delete the software (and source) off my hard drive if a project disappears.

To quote Patrick Cauldwell, "Sure, we are assuming the burden of maintenance when we use it, but we're doing that anyway as there's no assurance that someone in the OS community would care about a bug we found."

This is exemplified by Stuart's recent spitting into the wind with a catastrophic but ignored Subversion case-sensitivity bug.

Moral: What you care about, often ain't what the other guy cares about.

Conclusion: The Schematron .NET implementation is total abandonware and I'm going to use it anyway. Since when did 3 year old software become abandoned. I haven't been in my backyard in 3 years, but if I catch you camping there I'll ask you to leave.


(If you'd like to receive ComputerZen.com via email, you can subscribe to this blog as a newsletter for free. Subscribe to Scott Hanselman - ComputerZen.com by Email)

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Thursday, October 05, 2006 12:02:51 AM UTC
Very well said.

An open source license is the best extended warranty you could hope for. If the product's mature, it doesn't need frequent updates. If it needs updates and it's worth your time, it's all yours.

This is part of the reason that picking the right license is one of the most important parts of open source development (http://weblogs.asp.net/jgalloway/archive/2006/08/16/CodeProject-_2D00_-Avoiding-software-licensing-makes-for-a-very-bad-license.aspx). As long as the license is right (BSD, MIT, etc.), the project's never really abandoned as long as someone wants to work on it. Not sure what Schematron's license is (Common Public License, Other/Proprietary License?), but if you want you could always fork it and keep right on trucking.
Thursday, October 05, 2006 1:22:54 AM UTC
I would have to agree. Mostly, a lot of open source projects out there get created to fill a specific need the author had and once that need has been met, even if the code is far from complete/perfect (i.e. it's "good enough") then they might just stop working on it and if no one else picks it up, too bad. BUT, as long as it's available and you have the source, then just take advantage of it.

Take my MemoryMappedFiles library (which is certainly open source): I did the initial development and did as much as I needed to get going. If someone asks for an issue with it, I'll do my best to help out, but I'm not actively developing it anymore, as I personally have no need. Quite a few people still use it and I get mails from time to time from people asking permission to use it on a given context (which I'm quite happy to give) and even the ocassional user contribution.

Heck, even if it was actively developed, support with most open source projects is still relying a lot on your own wit and if you're lucky, there's a mailing list around you can fall back on when you're stumped :)

Thursday, October 05, 2006 3:38:53 PM UTC
I think that a project requires more than an Open Source license to avoid becoming abandonware. It also requires a publicly accessible repository where people can continue to download the project, even if the original author(s) take down the project page/website. I was listening to a podcast by Larry Augustin who Founded VA Linux and SourceForge.net, and one of the primary reasons for launching sourceforge was to ensure that these projects would live on forever, even if the authors abandoned them. As an interesting aside, he said that people have even asked to have their project/files removed from SourceForge and were flatly rejected. So even if an author abandons a project, SourceForge never will.
Thursday, October 05, 2006 7:04:21 PM UTC

Sometimes I find good closed source utilities that got abandoned by their author and removed from their website. I always wondered why don't they open source it and put on sourceforge and let people continue use and extend then instead of dying like that.

One problem with Sourceforge is the number of projects that have 0 files and were opened long time ago. These projects are dead projects; 0 files, 0 activity on the discussion forum and 0 interest from the public. Might as well remove them.
Thank God now I can search projects by activity. Long due.

Abdu
Friday, October 06, 2006 4:10:21 PM UTC
Very good points Scott. The very reason why I like to put stuff in an opensource project is precisely that: so that others can benefit, regardless of my current time availability to help in a particular issue.
The license we picked for the project (Common Public License, Other/Proprietary License?) allows for both the CPL license, as well as comercial licenses for businesses that do not trust/want the CPL. For example, on the Mvp.Xml project we have a similar approach (BSD License, Other/Proprietary License), and we exercised the later by signing a license agreement with Microsoft so that they can do whatever they want with the code, in their own legal-approved terms. This turned out to be very valuable.
Friday, October 06, 2006 8:01:38 PM UTC
>> This is exemplified by Stuart's recent spitting into the wind with a catastrophic but ignored Subversion case-sensitivity bug

I read through the various discussions about Stuart's case sensitivity bug, and it sure didn't seem like spitting in the wind - in fact the bug was fixed within a few months. Now, that's certainly not overnight, but the discussions clearly indicated to me that the SVN developers were concerned about data corruption above anything else. They prefer that the service keel over rather than corrupt a user's data. While aborting a service is clearly not ideal, it certainly beats a continuously running service that loses your source depot.

Also, if I'm not mistaken, since the problem was in the Apache module, there were available workarounds - using svnserve instead of mod_dav_svn to access the repository or run the Apache server on a *nix system instead of Windows. I believe that these options were communicated to Stuart.

If you Google for comments about SourceSafe I think you'll find much more spitting in the wind.

Note, I don't even use Subversion (Perforce here) - I'm simply throwing in my 2 cents about the events that Stuart C describes in his blog.
mikeb
Saturday, October 07, 2006 7:25:21 AM UTC
I think a lot of people viewed NDoc as abandonware. I think that was one of the big reasons it died. You'd go to the sourceforge and home pages for NDoc and it looked deader than dead.
cs
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.