The problem is a disconnect between the effort that would be required from the various developers of Markdown implementations/derivatives, and the relative lack of benefit that they(we) would see.
For example, I am happy with how MultiMarkdown works. There are a few minor tweaks I have planned after I get a few other projects finished, but in general it's close to "feature-complete" as far as I'm concerned. Similarly, John MacFarlane is happy with how Pandoc works. (And yes we do exchange emails fairly regularly...) I imagine most other developers feel about the same - they eat their own dog food and they're very happy with it. The idea of a "standards" group is not a new one. It has been proposed on this very list every year or two. And every time it is has been met with a resounding silence. I recently brought up the idea of a kickstarter project with a couple of other developers. The idea would be to raise financial support for the development and implementation of such a "standards" group. The kickstarter idea would allow a gauge of community interest/support as measured by willingness to financially support the project. How much would it be worth to the community at large for various developers to devote the several months (or more) it would probably take to approach this task and do it right? Would it be enough to justify the time away from other (paying) projects that they would otherwise be working on? What happens at the end if a system designed by committee is not suitable, and some (all?) of the developers decide not to implement it? A couple of us bounced around this idea and decided that for us at least, now is not the right time. In principle, we agreed that there is a theoretical amount of money that would balance the effort required and make this an attractive prospect. But that amount is probably higher than would be realistic, after accounting for other projects that would have to be abandoned/delayed. None of us created these projects (which are often open-source) because we thought they would make us rich. While all of us felt a passion for creating a tool that performed a specific job that we ourselves needed (e.g. a way to turn text into HTML that was written in Microsoft Basic), I suspect that none of us feels a passion for creating a committee to attempt to bash other developers over the head until they comply. It's probably going to take some other form of a carrot; a stick is unlikely to work. To do this right would require: * developing and agreeing on a list of key principles (there needs to be a way to judge whether one proposal is "better" than another) * developing and agreeing on a list of edge cases and how to resolve them * developing and agreeing on a list of extended syntax features, the "proper" syntax to use them, and the proper syntax for output (e.g. HTML or LaTeX, etc) * there would have to be a way to incorporate input from the Markdown community at large, while remembering that if the individual developers strongly disagree with the results, there might be no real world implementations * some sort of plan for a name - Markdown belongs to John Gruber, whom I suspect would not be involved in any of this given his longstanding absence from the world of Markdown. * some system for maintaining this going forward - who is responsible for fixes? For arranging the next round 1,3,7 years from now? * developing test suites * "certifying" compliance amongst implementations that claim to be compliant * etc, etc. It's not a small undertaking. And in the end, the developers who participate put in a lot of time and effort, and come away with a product that is likely to be a little *less* like their own vision than what they started with. Perhaps you could argue that standardization might be good for allowing users to move from one app to another and know how things will work. But I have that already - everything I do works just how I want (short of unintended bugs). Sure, I sometimes wish that a web site (e.g. github) would implement more of my features, but those situations are fairly rare. My suggestion for anyone who feels strongly about seeing this happen: 1) decide on the scope of what you want as a "deliverable" 2) decide on how you are going to convince developers to go along to justify whatever level of effort they are going to have to put in (keeping in mind that if the standards are developed without input from them, implementation rates might be low. Getting their involvement, however, might be more expensive in some way - perhaps not in dollars, but in some other way 3) gather "provable" support from the community that demonstrates how #2 is going to be met I suspect that only then will such an effort as this actually move forward, and not just be a bunch of hot air on a list-serve..... Or maybe I'm entirely wrong... F- On May 30, 2012, at 12:52 PM, bowerb...@aol.com wrote: > i did write a long post in response to this thread... > > but i guess it's best to just let this listserve wither. > > -bowerbird > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss@six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss -- Fletcher T. Penney fletc...@fletcherpenney.net
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
