MONO - lost it's way?
-
I was very excited about MONO for a couple of years there and posted here about it but I'm starting to get the impression it has badly lost it's way. The original concept was to be able to build cross platform .net apps that would run in windows under Microsoft .net or on a mac or linux box etc. So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software, things like being able to set the cursor to a waitcursor which predates even .net 2. That being said they are now apparently leaping ahead to some .net 3 stuff and promising silverlight support in a couple of months. It has all the hallmarks of a project where everyone is leaping ahead to the fun bits and dropping the ball on the fundamental bits. The other big glaring problem is there is no 3rd party library support worth mentioning, so no reporting, no ui stuff etc. I tried to get Telerik and Infragistics and DevExpress together with MONO, in fact the MONO head dude did get in talks with them. Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work. Although they all seem to use the same fundamentel p/invokes which led the MONO people to say that they would come up with some sort of shim layer to support that which would instantly give everyone using all those nifty 3rd party component libraries the MONO market as well. That never materialized and has since not been mentioned at all. In fact they point people to a list of "MONO" supported .net libraries but there is nothing on there that would work for a serious commercial application developer and besides it breaks the whole point of write once run everywhere that was the original promise. Sadly I think MONO is still years away from being what it was supposed to be this year. Sure you can write trivial little sample apps that run on mono.net and ms.net but try to do anything more and you better write it for MONO and accept it's going to be very limited compared to other apps out there.
"110%" - it's the new 70%
With WINFORM developement PInvoke was common. With .NET3, WPF, there is great hope to reduce PInvoke to naught, making much more portable. It makles sense they rush to .NET3/WPF, here there would be real portability!! I shall hope...
-
John Cardinal wrote:
Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work.
<nelson>hA-ha!</nelson> As for the rest of it... Frankly, it doesn't surprise me. .NET is freakin' huge. I just can't imagine too many people sitting down and thinking, "yeah, i'm gonna spend my day going down a list of APIs, writing test cases and implementations based on a spec just in case someone ever wants it." I mean, OSS is all about scratching itches, right? EMACS was RMS's desire for an editor, Linux was Torvalds' desire for a OS to play with, GNOME was... someone's desire to turn the GIMP's UI toolkit into a whole desktop platform... :~ Anyway... i'm thinking it'll take a good few apps with lotsa needs using MONO to motivate its completion. If everyone sticks to graphics demos, no one will ever bother fleshing out Decimal, etc...
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
Well technically speaking I'm pretty sure Novell is paying their own developers to work on MONO at this point. It's not a classic OSS project and there is a lot more behind it than fun or hobby, it's a real business case Novell has behind it.
"110%" - it's the new 70%
-
Don't they give you source to their framework ? Perhaps they hoped that they'd achieve open source bliss by having users post solutions to simpler problems like Decimal.Round. Either way, I have always viewed the 'Mono rocks' people with suspicion. It seems to me like it will always be like Christian rock music. It's only good for those people who assume that rock music is of the devil, and so need an alternative, and will excuse it, just because it's all they've got.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
The idea of mono truly "rocks". That's not from any kind of culty point of view, strictly a capitalist one (unless of course you feel capitalism is a cult, maybe it is ;) ). If my Visual Studio created .net app contains all the methods that are implemented in MONO I can literally say on my download page of my trial software that the same binary runs on windows and Linux, OSX etc under MONO. Instant market share I didn't have before, nothing to recompile, no separate version to post online, build and maintain etc. It's frustrating because it's close, a lot of simpler apps *do* work that way right now, but for what I do it's not quite there. To be fair decimal.round *is* implemented, just the MidPointRounding attribute isn't supported but that's critical for any financial software. I could contribute to it, anyone can, but I don't have the time.
"110%" - it's the new 70%
-
Well technically speaking I'm pretty sure Novell is paying their own developers to work on MONO at this point. It's not a classic OSS project and there is a lot more behind it than fun or hobby, it's a real business case Novell has behind it.
"110%" - it's the new 70%
Yeah... Any idea what projects Novell is using it for? I know they had some sort of WebDAV / Sharepoint-ish thing at one time, but haven't paid much attention lately.
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
-
Yeah... Any idea what projects Novell is using it for? I know they had some sort of WebDAV / Sharepoint-ish thing at one time, but haven't paid much attention lately.
----
Yes, but can you blame them for doing so if that's the only legal way they can hire programmers they want at the rate they can afford?
-- Nish on sketchy hiring practices
Not sure, but I think it's more an overall bigger picture thing they have going on with their own linux distro etc. I've always assumed they are trying to get more commercial apps that can run on Linux, this is one way to do that.
"110%" - it's the new 70%
-
I was very excited about MONO for a couple of years there and posted here about it but I'm starting to get the impression it has badly lost it's way. The original concept was to be able to build cross platform .net apps that would run in windows under Microsoft .net or on a mac or linux box etc. So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software, things like being able to set the cursor to a waitcursor which predates even .net 2. That being said they are now apparently leaping ahead to some .net 3 stuff and promising silverlight support in a couple of months. It has all the hallmarks of a project where everyone is leaping ahead to the fun bits and dropping the ball on the fundamental bits. The other big glaring problem is there is no 3rd party library support worth mentioning, so no reporting, no ui stuff etc. I tried to get Telerik and Infragistics and DevExpress together with MONO, in fact the MONO head dude did get in talks with them. Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work. Although they all seem to use the same fundamentel p/invokes which led the MONO people to say that they would come up with some sort of shim layer to support that which would instantly give everyone using all those nifty 3rd party component libraries the MONO market as well. That never materialized and has since not been mentioned at all. In fact they point people to a list of "MONO" supported .net libraries but there is nothing on there that would work for a serious commercial application developer and besides it breaks the whole point of write once run everywhere that was the original promise. Sadly I think MONO is still years away from being what it was supposed to be this year. Sure you can write trivial little sample apps that run on mono.net and ms.net but try to do anything more and you better write it for MONO and accept it's going to be very limited compared to other apps out there.
"110%" - it's the new 70%
-
I was very excited about MONO for a couple of years there and posted here about it but I'm starting to get the impression it has badly lost it's way. The original concept was to be able to build cross platform .net apps that would run in windows under Microsoft .net or on a mac or linux box etc. So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software, things like being able to set the cursor to a waitcursor which predates even .net 2. That being said they are now apparently leaping ahead to some .net 3 stuff and promising silverlight support in a couple of months. It has all the hallmarks of a project where everyone is leaping ahead to the fun bits and dropping the ball on the fundamental bits. The other big glaring problem is there is no 3rd party library support worth mentioning, so no reporting, no ui stuff etc. I tried to get Telerik and Infragistics and DevExpress together with MONO, in fact the MONO head dude did get in talks with them. Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work. Although they all seem to use the same fundamentel p/invokes which led the MONO people to say that they would come up with some sort of shim layer to support that which would instantly give everyone using all those nifty 3rd party component libraries the MONO market as well. That never materialized and has since not been mentioned at all. In fact they point people to a list of "MONO" supported .net libraries but there is nothing on there that would work for a serious commercial application developer and besides it breaks the whole point of write once run everywhere that was the original promise. Sadly I think MONO is still years away from being what it was supposed to be this year. Sure you can write trivial little sample apps that run on mono.net and ms.net but try to do anything more and you better write it for MONO and accept it's going to be very limited compared to other apps out there.
"110%" - it's the new 70%
Just some thought: I would rather the mono team selectively implement features grouped by functional areas, instead of what they are currently doing; building a wireframe of the entire fx and then fill the holes later. For instance, they can completely unsupport Asp.Net, yet, allocate their full resources to implement a solid WindowsForm areas, or the other way around. .NET is a framework, application built with it will inherit any bugs and design issues. A framework may not neccessary be features-rich, but it must be solid. The ultimate goal of Mono is to be able to run .net application on other platform, and that people will actually use mono for that. What the team doing now is completely opposing this goal. If support for a particular OS is blocking the project, drop that OS support; If certain UI components are just very hard to be implemented in cross-platform, exclude such components completely until a better solution comes up, or leave that area to third party. The last thing I want is to have halfly implemented code as the foundation of my project. The moment I know they are going to support .NET 3.X at this very point make me shrink my head. When mono isn't yet fully supporting .NET 1 to .NET 2, why bother .NET 3? They are just wasting their time. The big company behide the project is just wasting money.
-
I was very excited about MONO for a couple of years there and posted here about it but I'm starting to get the impression it has badly lost it's way. The original concept was to be able to build cross platform .net apps that would run in windows under Microsoft .net or on a mac or linux box etc. So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software, things like being able to set the cursor to a waitcursor which predates even .net 2. That being said they are now apparently leaping ahead to some .net 3 stuff and promising silverlight support in a couple of months. It has all the hallmarks of a project where everyone is leaping ahead to the fun bits and dropping the ball on the fundamental bits. The other big glaring problem is there is no 3rd party library support worth mentioning, so no reporting, no ui stuff etc. I tried to get Telerik and Infragistics and DevExpress together with MONO, in fact the MONO head dude did get in talks with them. Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work. Although they all seem to use the same fundamentel p/invokes which led the MONO people to say that they would come up with some sort of shim layer to support that which would instantly give everyone using all those nifty 3rd party component libraries the MONO market as well. That never materialized and has since not been mentioned at all. In fact they point people to a list of "MONO" supported .net libraries but there is nothing on there that would work for a serious commercial application developer and besides it breaks the whole point of write once run everywhere that was the original promise. Sadly I think MONO is still years away from being what it was supposed to be this year. Sure you can write trivial little sample apps that run on mono.net and ms.net but try to do anything more and you better write it for MONO and accept it's going to be very limited compared to other apps out there.
"110%" - it's the new 70%
Yup - I agree. I didn't need too much of the .NET stuff, just enough to have a fairly streamlined GUI to control and display results from some image processing functions I write in my job... mono was going to be a nice way for me to keep the simplicity of "knocking up a GUI" while allowing me to be cross platform (I'm more a Linux than a windows developer). I tried for a few days to get something usable written... it just wasn't straight forward, and .NET is just so much more easier to knock up quick and dirty demo's that have a polished feel and run fairly quickly. I love SharpDevelop though... I found MonoDevelop (or whatever they call it) just isn't as stable.
-
JimmyRopes wrote:
Since it is an open source project perhaps, if you are so inclined, you could devote some time into getting the basics implemented. It may not be glamorous but you will learn a lot along the way.
I agree with you !!!
Greets! Joel
You got my vote on that too. The true nature of Open Source is that if it's broken, *YOU* can fix it. So get your tool belt on and start hammering.
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
-
I was very excited about MONO for a couple of years there and posted here about it but I'm starting to get the impression it has badly lost it's way. The original concept was to be able to build cross platform .net apps that would run in windows under Microsoft .net or on a mac or linux box etc. So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software, things like being able to set the cursor to a waitcursor which predates even .net 2. That being said they are now apparently leaping ahead to some .net 3 stuff and promising silverlight support in a couple of months. It has all the hallmarks of a project where everyone is leaping ahead to the fun bits and dropping the ball on the fundamental bits. The other big glaring problem is there is no 3rd party library support worth mentioning, so no reporting, no ui stuff etc. I tried to get Telerik and Infragistics and DevExpress together with MONO, in fact the MONO head dude did get in talks with them. Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work. Although they all seem to use the same fundamentel p/invokes which led the MONO people to say that they would come up with some sort of shim layer to support that which would instantly give everyone using all those nifty 3rd party component libraries the MONO market as well. That never materialized and has since not been mentioned at all. In fact they point people to a list of "MONO" supported .net libraries but there is nothing on there that would work for a serious commercial application developer and besides it breaks the whole point of write once run everywhere that was the original promise. Sadly I think MONO is still years away from being what it was supposed to be this year. Sure you can write trivial little sample apps that run on mono.net and ms.net but try to do anything more and you better write it for MONO and accept it's going to be very limited compared to other apps out there.
"110%" - it's the new 70%
"Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work." Actually, the .NET Framework makes heavy of P/Invoke too. Are you going to slam that too while your on a roll?
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
-
I was very excited about MONO for a couple of years there and posted here about it but I'm starting to get the impression it has badly lost it's way. The original concept was to be able to build cross platform .net apps that would run in windows under Microsoft .net or on a mac or linux box etc. So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software, things like being able to set the cursor to a waitcursor which predates even .net 2. That being said they are now apparently leaping ahead to some .net 3 stuff and promising silverlight support in a couple of months. It has all the hallmarks of a project where everyone is leaping ahead to the fun bits and dropping the ball on the fundamental bits. The other big glaring problem is there is no 3rd party library support worth mentioning, so no reporting, no ui stuff etc. I tried to get Telerik and Infragistics and DevExpress together with MONO, in fact the MONO head dude did get in talks with them. Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work. Although they all seem to use the same fundamentel p/invokes which led the MONO people to say that they would come up with some sort of shim layer to support that which would instantly give everyone using all those nifty 3rd party component libraries the MONO market as well. That never materialized and has since not been mentioned at all. In fact they point people to a list of "MONO" supported .net libraries but there is nothing on there that would work for a serious commercial application developer and besides it breaks the whole point of write once run everywhere that was the original promise. Sadly I think MONO is still years away from being what it was supposed to be this year. Sure you can write trivial little sample apps that run on mono.net and ms.net but try to do anything more and you better write it for MONO and accept it's going to be very limited compared to other apps out there.
"110%" - it's the new 70%
John Cardinal wrote:
So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software...
Why don't you just derive a Decimal subclass and overload the Round() method? It sounds easy enough to me but I don't know the situation...
############################################# A comment from some code: "The devision operations in the SET function calls are intentional, do not change them, they will prevent a software bug from causing the robot to drive through twelve cubical walls"
-
John Cardinal wrote:
So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software...
Why don't you just derive a Decimal subclass and overload the Round() method? It sounds easy enough to me but I don't know the situation...
############################################# A comment from some code: "The devision operations in the SET function calls are intentional, do not change them, they will prevent a software bug from causing the robot to drive through twelve cubical walls"
That's just an example, for my main application there are over a 250 methods either not implemented yet or flagged as todo with issues. I'm not even counting the p/invokes in there that are a result of the 3rd party ui and reporting components I use. The whole point was supposed to be that you can take a binary built for microsoft.net and simply run it in MONO, no need to change the code at all. I and most other commercial developers are not going to change a single line of working, tested, released to the public code simply to cater to an unknown market size that we might get with MONO. If it was really just able to run under MONO then it's all good.
"110%" - it's the new 70%
-
"Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work." Actually, the .NET Framework makes heavy of P/Invoke too. Are you going to slam that too while your on a roll?
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
Neil Cowburn wrote:
Are you going to slam that too while your on a roll?
Yikes! slam is a pretty loaded word, I've brought up perfectly valid points here. P/Invokes are the tip of the iceberg really, there are over 250 methods that are still not implemented or flagged as TODO in MONO when I scan it with MOMA for my main application I was thinking would benefit if it could run in MONO. The real issue is that over a year ago when I scanned the same app with MOMA it was pretty much the same situation. So in a year there has been no progress on fundamental basic items in the framework, however I see they are leaping ahead to .net 3 and silverlight etc. It's clearly lost it's way when the fundamentals aren't being taken care of. As for the .net framework making heavy use of p/invoke, I have no personal knowledge of that nor do I really understand your point either way. The goal of MONO is to have a complete reproduction of the microsoft .net framework as per the submitted spec. In a completely separate issue 3rd party component library vendors are advertising 100% managed .net code which turns out to be false advertising. Would have been a non issue if MONO hadn't come along, now it's clear that they won't be supported on MONO and MONO themselves have backed away from the promise of a support library of some kind for the p/invokes that are most commonly used. Which turns the whole thing around to where it was at the start: useless for anything more than a very primitive application.
"110%" - it's the new 70%
-
If Mono is open source, you can fix what is not working for you. That's the purpose of Open Source, me thinks. If everybody waits for somebody to do it we'll never get there.
I didn't start the project, I don't have the resources of Novell who is using in-house developers to supposedly complete it. I'm merely pointing out that they have lost their way, they were supposed to be much further along than they are now. This is not a classic open source project by any stretch of the imagination although it appears to be suffering from the same factors that doom most open source projects: no one wants to work on the boring stuff.
"110%" - it's the new 70%
-
Neil Cowburn wrote:
Are you going to slam that too while your on a roll?
Yikes! slam is a pretty loaded word, I've brought up perfectly valid points here. P/Invokes are the tip of the iceberg really, there are over 250 methods that are still not implemented or flagged as TODO in MONO when I scan it with MOMA for my main application I was thinking would benefit if it could run in MONO. The real issue is that over a year ago when I scanned the same app with MOMA it was pretty much the same situation. So in a year there has been no progress on fundamental basic items in the framework, however I see they are leaping ahead to .net 3 and silverlight etc. It's clearly lost it's way when the fundamentals aren't being taken care of. As for the .net framework making heavy use of p/invoke, I have no personal knowledge of that nor do I really understand your point either way. The goal of MONO is to have a complete reproduction of the microsoft .net framework as per the submitted spec. In a completely separate issue 3rd party component library vendors are advertising 100% managed .net code which turns out to be false advertising. Would have been a non issue if MONO hadn't come along, now it's clear that they won't be supported on MONO and MONO themselves have backed away from the promise of a support library of some kind for the p/invokes that are most commonly used. Which turns the whole thing around to where it was at the start: useless for anything more than a very primitive application.
"110%" - it's the new 70%
There's an old saying, "If you're not part of the solution, you're part of the problem." If you have issues with the "fundamentals" not being present in Mono, why don't you implement them yourself and contribute them back to the community instead of moaning?
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
-
There's an old saying, "If you're not part of the solution, you're part of the problem." If you have issues with the "fundamentals" not being present in Mono, why don't you implement them yourself and contribute them back to the community instead of moaning?
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
You're taking this all very personally for some odd reason. Signing up with an account just to reply to this thread. Whatever the case welcome to CodeProject and know that we tend to have opinions here that you might not agree with from time to time. Saying it's better to light a candle than curse the darkness doesn't in my opinion negate the quality of the information I provided. Perhaps you are not aware that I was a major proponent of MONO here for some time. I'm not moaning about it, I'm rectifying my prior posts which were all very supportive of MONO. As the person that kept bringing it to the attention of the community when it seemed to be going somewhere fast and had big promise and relevance to people here. I felt an obligation to ensure that I report the facts on how it all turned out.
"110%" - it's the new 70%
-
You're taking this all very personally for some odd reason. Signing up with an account just to reply to this thread. Whatever the case welcome to CodeProject and know that we tend to have opinions here that you might not agree with from time to time. Saying it's better to light a candle than curse the darkness doesn't in my opinion negate the quality of the information I provided. Perhaps you are not aware that I was a major proponent of MONO here for some time. I'm not moaning about it, I'm rectifying my prior posts which were all very supportive of MONO. As the person that kept bringing it to the attention of the community when it seemed to be going somewhere fast and had big promise and relevance to people here. I felt an obligation to ensure that I report the facts on how it all turned out.
"110%" - it's the new 70%
BTW, it's Mono, not MONO :) I'm not the one taking this personally. You are. You're miffed because after a year, no one was implemented the class you need. Did you attempt to implement it yourself? Probably not. You seem to be missing the point of one the core principles of Open Source -- growth is achieved through community contribution. Not once in this thread have I seen you say anything along the lines of "Hey, something is not quite right here. Let's get together and do something about it", which would be in the spirit of the Open Source movement. Have you reported these facts back to the Mono community? I'd say that would be a better course of action.
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
-
BTW, it's Mono, not MONO :) I'm not the one taking this personally. You are. You're miffed because after a year, no one was implemented the class you need. Did you attempt to implement it yourself? Probably not. You seem to be missing the point of one the core principles of Open Source -- growth is achieved through community contribution. Not once in this thread have I seen you say anything along the lines of "Hey, something is not quite right here. Let's get together and do something about it", which would be in the spirit of the Open Source movement. Have you reported these facts back to the Mono community? I'd say that would be a better course of action.
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
Neil Cowburn wrote:
You're miffed because after a year, no one was implemented the class you need
Miffed wouldn't be accurate, disillusioned would be closer to the mark and for the record it isn't "one" class it's over 250 methods which have seen no movement in over a year. To say I need them is inaccurate, I really don't "need" Mono at all, I was excited about it, I thought it would be a good way to add sales to our existing market. I'm a business person besides being a developer and I think it's not an exaggeration to say that rather than myself needing Mono, Mono actually needs the opinions of people like myself for a long term future. When you still can't set a wait cursor after all this time it's pretty obvious no one is putting a priority on commercial application developers that can't afford to throw away all consideration of usability.
Neil Cowburn wrote:
Have you reported these facts back to the Mono community? I'd say that would be a better course of action.
Yes Miguel is aware of my concerns and I've faithfully run and submitted my MOMA reports every quarter since it first became available as a tool.
Neil Cowburn wrote:
You seem to be missing the point of one the core principles of Open Source -- growth is achieved through community contribution.
I'm well aware of the core principles of open source. In fact I oppose the idea of open source software on principle for any purpose except infrastructure; the category that Mono falls into which is nuts and bolts "plumbing" that supports applications. For example the Firebird project falls in that category as well which I support wholeheartedly. As a full time working developer with a small software company I have no spare time to involve myself with Mono development other than a potentially half-assed, when-I-can kind of effort which I don't think is appropriate for any serious work. I do have the perspective and share the views of a *lot* of commercial software developers who, last time I checked, were one of the coveted target markets for Mono. I'm sure Novell would have more than a passing interest in attracting more commercial apps to Linux and they *do* have and are applying the resources appropriate to the project. Sadly it seems to be losing it's way in exactly the manner that most open source projects do: no one wants to do the dirty work.
-
Neil Cowburn wrote:
You're miffed because after a year, no one was implemented the class you need
Miffed wouldn't be accurate, disillusioned would be closer to the mark and for the record it isn't "one" class it's over 250 methods which have seen no movement in over a year. To say I need them is inaccurate, I really don't "need" Mono at all, I was excited about it, I thought it would be a good way to add sales to our existing market. I'm a business person besides being a developer and I think it's not an exaggeration to say that rather than myself needing Mono, Mono actually needs the opinions of people like myself for a long term future. When you still can't set a wait cursor after all this time it's pretty obvious no one is putting a priority on commercial application developers that can't afford to throw away all consideration of usability.
Neil Cowburn wrote:
Have you reported these facts back to the Mono community? I'd say that would be a better course of action.
Yes Miguel is aware of my concerns and I've faithfully run and submitted my MOMA reports every quarter since it first became available as a tool.
Neil Cowburn wrote:
You seem to be missing the point of one the core principles of Open Source -- growth is achieved through community contribution.
I'm well aware of the core principles of open source. In fact I oppose the idea of open source software on principle for any purpose except infrastructure; the category that Mono falls into which is nuts and bolts "plumbing" that supports applications. For example the Firebird project falls in that category as well which I support wholeheartedly. As a full time working developer with a small software company I have no spare time to involve myself with Mono development other than a potentially half-assed, when-I-can kind of effort which I don't think is appropriate for any serious work. I do have the perspective and share the views of a *lot* of commercial software developers who, last time I checked, were one of the coveted target markets for Mono. I'm sure Novell would have more than a passing interest in attracting more commercial apps to Linux and they *do* have and are applying the resources appropriate to the project. Sadly it seems to be losing it's way in exactly the manner that most open source projects do: no one wants to do the dirty work.
I'm amazed that even after all this discussion, you still have yet to take the intiative propose a solid, constructive solution. Maybe you're just apathetic. Afterall, by your own admission, "... no one wants to do the dirty work.
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
-
I'm amazed that even after all this discussion, you still have yet to take the intiative propose a solid, constructive solution. Maybe you're just apathetic. Afterall, by your own admission, "... no one wants to do the dirty work.
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------