Skip to main content

Pirillo - Don’t Let Software Die

Don’t Let Software Die ~ Chris Pirillo

Interesting post regarding TuCow's decision a while back to stop updating Blogware. It reminded me a little of VFP in that it's a company that has decided to stop updating one of its software packages.

Chris' comments on the letter:
>> What worries me most about building communities on closed platforms is that as soon as those platforms change direction or stop innovating, you’re locked into a toolset that has nowhere to go but down

Whoa! Does this sound like VFP and FoxPro? Read on...

>> Tucows has given absolutely no indication that they’re interested in opening the platform at all - leaving you in more of a no-win situation.

You can't fault Microsoft for not wanting to open up the VFP engine - as that has given a lot of its other products some definite improvements but the re-licensing of the xBase components certainly does show that they were interested in not killing it outright. Indeed, I think Microsoft deserves some kudos for a lot of the openness they have shown recently (VSX, etc).

Before you criticize my "blind support", of course, it's for the good of their business. Why else would someone do anything? You want developers to be using the Visual Studio Shell, to make their development "home" beyond everything else. But it's great that they have opened it up to let others create their own environment within it.

>> My “continued support of Tucows” is completely contingent on what they decide to do with Blogware now… aside from abandoning it. Don’t let software die, please? If nobody wants to pick up the ball and run with it, at least you would have given them the opportunity to do so.

At a recent Microsoft event, I ran into some developers who offered the comment "When was your last version?" (or something to that effect). My response? "If you're waiting for Microsoft to be the only one to improve a product's offering, then you're in the wrong business". That isn't a slant against Microsoft - but rather against those who would say "well, it can't do it out of the box so therefore, I'll wait for it to do it INSIDE the box".

Microsoft has offered FoxPro developers this - "you can't have the rubber that makes up the ball, but here's the ball - run with it."

So when people ask what's the latest version of FoxPro, I simply say "VFPX". There has been and will always be more innovation inside a product's community than just what is inside a product vendor's corporation. And that is good for the entire community. If you ever get into a situation where the only people offering new features or uses for an (existing) product is the actual company making it,  be forewarned.

(note: I say existing because obviously that is very often the case for startup products)

The only thing we have to figure out is how to ensure people can continue to purchase VFP proper...can a third-party organization possibly get a "distribution license" for perpetuity?

Comments

Anonymous said…
Hi Andrew,

There's also another part of Microsofts decision to end FoxPro's development: There's a huge damage to the economy. Last week I had a discussion with one of our multinational customers, where we have a mission-critical application running with several thousand users worldwide. This software is in constant development due to the ever changing needs, and over the last 10 years we had the perfect tool as each version of VFP allowed us to just recompile and go on. Now we are faced with a complete rewrite (of course not today, but somewhere in the next 5 years or so). This means that the whole investment of this customer has to get payed again!

Now lets do some math:
Say there are only 10.000 VFP-based developers worldwide, who each sold about 100.000$ worth of work per year. Over the last 5 years (this would be the VFP8/VFP9 cycle), this group made about 10.000 * 5 * 100.000 = 5 Billion$ work, which is now obsolete and has to get repayed by the customers again, who are taken by surprise, because you are used to a constant enhancement of VFP-applications. (Those numbers are surely way underestimated, for example my customers are faced with a total of 9 million Euros loss)

Just because MS doesn't take a longterm responsibility for their product.

I wonder how long it takes until a big customer is taking action and sues MS for that damage.
lena said…
The comments regarding Tucows' decision to stop updating Blogware and Microsoft's decision to discontinue Visual FoxPro (VFP) highlight the importance of utilizing SRD (Status Check) in project management. Just as Chris expressed concerns about being locked into closed platforms without room for growth, the decision to stop updating Blogware left users in a no-win situation. Similarly, Microsoft's move limited the innovation within VFP. However, the re-licensing of the xBase components showed Microsoft's interest in not completely abandoning the technology. https://sassasrdstatuscheck.net.za/ provides a proactive approach to assess project status, identify risks, and foster collaboration. By regularly evaluating the state of a project or software package, like Blogware or VFP, potential issues can be addressed, alternative paths explored, and community-driven innovation encouraged, ensuring continuous improvement and success.

Anonymous said…
Microsoft’s re-licensing of xBase components shows a commitment to the technology, but it limits community-driven innovation. To fully empower the community, https://sassacheck.net.za/sassa-referred-status/ Microsoft could consider open-sourcing the components or adopting a hybrid model.

Popular posts from this blog

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction

FoxInCloud Stats

FoxInCloud sent this link a while back about their statistics regarding visits to their site: http://foxincloud.com/blog/2017/12/27/VFP-community-lessons-from-foxincloud-site.html What's interesting here is the breakdown of people. Yes, I think it's understandable that the Fox community is getting older. Another factor is the growth of the mobile and web environments taking over development. These environments really do push people towards the newer non-SQL or free SQL/hosted environments but more towards hosted storage options like Amazon and Google. A tool like FoxInCloud that helps MOVE existing applications to the cloud inherently competes with those environments. But FoxInCloud also allows developers to extend their application further by giving them a starting point using Javascript and the basic CSS (such as Bootstrap). If you're not rebuilding your application from scratch, it's certainly a great step forward. FoxPro VFP