Rob Weir sent me some links to an open source effort called OpenProj which aims to take on Microsoft Project. Evidently the project owners would like to integrate it into OpenOffice.org or, I would guess, at least make it compatible.
- ZDNet Blogs: “Microsoft Project to get open source competition” (try to guess why there is a picture of the latest Harry Potter book near the bottom of the article)
- ComputerWorld: “LinuxWorld: SaaS rival to Microsoft Project goes open source”
- Linux-Watch.com: “Open-source replacement for Microsoft Project on its way”
This is available in beta now for Linux, the Mac, and Windows.
Personally, I think this is a terrific idea. I’ve been part of more than one team that did not want to pony up the money for multiple copies of Microsoft Project, and so we all just went without it. This could “bring project management to the masses,” so to speak, and really drive all sorts of efficiencies. I could see small and medium size businesses benefiting from this, as well as all sorts of non-profit organizations.
As the Linux desktop starts to take hold (thanks to all of the developers who created the software and, more recently, Dell and Lenovo), the idea of having machines come with this is pretty intriguing.
The ComputerWorld article says, in part:
Finally, Projity plans to invest “significant resources” into driving the creation of an open standards document format for project management that would be an alternative to the .mpp/.mpx formats used by Microsoft Project, and would eventually become a subset of the OpenDocument Format natively used by OpenOffice and StarOffice. OpenProj can open Project files and also runs on Windows, Mac OS X and Unix OSs.
Wow, consider that, ODF possibly continuing to evolve to handle new project management requirements. Any estimates from readers as to when we’ll have an XML spec for project management from Microsoft show up on ECMA’s doorstep for standardization? Or, how about everyone just works together starting RIGHT NOW to extend ODF to handle this functionality?
Representing the information for ‘resources’, ‘tasks’, ‘dependencies’, etc. needed by a project management application is hopefully a lot simpler than all the things Microsoft deem necessary for representing office productivity documents.
So if they do come to ECMA with a reasonable XML schema, it might be reusable for integration with ISO26300.
I keep hearing that governments want to knock our heads together (i.e. Microsoft, IBM, and other Information-Communucation-Technology providers) to get an integrated standard representation. For IBM, that means a representation that works under IBM Lotus Notes on Linux (because OS/2 has gone the way of the dodo, and SmartSuite is going that way too); presumably for Microsoft that means a representation that works under Microsoft Office on Microsoft Windows. What would Apple and SUN want to offer ? Oracle, RedHat, Novell ?
I wonder how large the budget of these governments is. We’d quote.
News just in: http://www.bbj.hu/main/news_29721_microsoft+%25E2%2580%2598monopoly%25E2%2580%2599+comes+under+fire.html
Excellent. They are not blind to the obvious.
I have seen this project thing mentioned on several blogs (e.g. Solveig Haugland http://openoffice.blogs.com/openoffice/2007/08/openproj-open-s.html) today and yesterday.
But what is this compared to GanttProject (http://www.ganttproject.org) ? GanttProject has already got ODF support.
As far as I can see, OpenProj is a far more comprehensive application, but not yet finished. Is OpenProj a fork ?
We should not make ODF as a super standard.
Ideally, there should be a *single* purpose for any single Open Standard, resulting in each Open Standard being specialised to meet a specific application domain.
Haren, you want consistent ways of representing things such as bold text and paragraphs, and they should be the same across all kinds of documents. On top of that you build document-specific extensions.
Another Open Source alternative to MS Project is already available : the good old “Project Manager Workbench” became “Open Workbench” (www.openworkbench.org) in 2000 or 2001.
Note however that AFAIK the (very powerful) scheduling engine part of the code is not open source.
An ODF extension to cover Project data files : this would be great !
There may be some overlapping areas (subset areas) but core information about project management is how task, resource, dependencies etc is going to representing.
I am suggesting that the file format for project management requirements should be separate Open Standard may be something like Open Project Format (and not extend ODF, it’s long enough as it is currently).
Project management software application could export information to ODF and PDF for example, however this is an issue at the software application layer.
Also, European Commission is interested in a minimal set of formats [1], that means ODF should not contain a numerous set of formats. A boundary needs to be drawn to avoid scope creeps.
1. http://www.openforumeurope.org/index.php?option=com_content&task=view&id=937&Itemid=1
How about a family of compatible standards that share common elements? That is, a well factored set of specs that use common structures when possible and are not needlessly redundant?
It sounds good but is IME is tough to actually do. The reason is the dreaded S-word combined with locale. It is similar to the problem of creating a data dictionary from multiple sources. How many meanings do you have for “eventType” or “incident”?
Semantic Web notwithstanding, this is the reason that markup systems prevailed over a common object-oriented framework. At that point, some of us realized that the only application we could all share semi-reliably was the syntax parser, and then we didn’t share that. We shared the syntax definition. Then we relentlessly moved on to the InfoSet. From abstraction to distraction, relentless unstoppable churn in the implementations make one-size-fits-all standard uncomfortable to wear and unprofitable to manufacture.
Remember GenCode, Bob. Remember Architectural Forms. Look at what you actually can share among markup element declarations and ask how many simply come down to “boxed thing” with a URI for the “thing”.
And so on. Today we can share URIs for things in boxes but even that major victory came at the cost of URIs being shoehorned into every conceivable use regardless of it being a good fit for the function and form. Thus XML Namespaces.
Have at but this is not a windmill. It is a fleshy full-grown and eternal fire breathing dragon called complexity brought about by local force vector scaling. It is a property of existence in systems bound to local space and time somewhat like evil and dark matter. No circular orbits, no predictable 3-body systems, and all rivers have tributaries and estuaries. Not being able to grasp the meaning of that wastes more design time than any other single cause and is the source of a not insignificant amount of friction and energy lost to heat in human to human communications. The answer is continuous negotiations and protocols. (That is what you really want from ISO: transparent negotiations and unambiguous protocols).
The sharing of some common elements is probably bound to happen.
The shared common elements/structure could become be separate Open Standard(s), that could be used by other Open Standards (by referencing to it, though you do not want reference individual sections of other Open Standards; you want to reference it as a whole).
(Some shared common elements already exist as an Open Standard, for example Dublin Core).
However, creating the common elements/structure needs to be done very carefully. The common elements/structure need to have a clear purpose and scope.
OK, so what are the governments going to do about things ?
There seem to be one set of laws requiring ‘fidelity for legacy documents’, and commercial reasons for ‘minimal disruption of existing automated business processes’; this leads to a migration path to ECMA-376.
And another set of laws requiring ‘citizens to have the right to use a choice of applications including no-charge open source tools’; this leads to a migration path to ISO 26300.
And IBM saying that it’s fine by IBM if OS/2 and SmartSuite go the way of the thermionic valve, the card punch, and the typewriter; that Linux, OpenOffice.org, and IBM Lotus Notes are the way of the future.
IBM’s used to handling what happens when a product line saturates the market; it’s the same as when the Space Shuttle drains all the fuel from its external tanks.
You let that stage of the rocket fall back to earth, and light the engine on the next stage.
The situation we’re in is akin to what happens if somebody gives you a 45 RPM ’single’ on vinyl, and a DVD player, and says ‘Play me the music please’. Microsoft are the only ones doing gramaphone players for the 45 RPM vinyl — very good gramaphone players, I might say — but everyone else in the world is saying that ISO-standard DVDs are the thing and it’s time to leave the vinyl behind.
Yes, I get the one size fits all data standard and for data it works sometimes but not always. It depends on the data. Bob probably remembers MIL-M-28001 and what replaced it. If I were king, I’d slice up OOXML AND ODF into smaller components and let them evolve independently. Even that has problems (is it easier to let parts evolve then integrate them or to evolve them in parallel so integration is easier: pick one).
1. Everyone in the world is not saying that, Chris, particularly with respect to document or office standards. You are saying that, specifically, IBM and Sun are saying that. Massachusetts just recanted and the goodly majority of the world is using MS Office so by your rules, ODF loses. Big time. That would be a bad outcome. ODF is necessary but not as the single format; it is necessary for competition.
2. Beta was better technology. VHS won because it was effective to stock in the video store shelves. Business costs in the low tier (say inexpensive mom and pop video stores) drove the emerging video market and in the low tier, more shelf space equalled more sales. So VHS won by stock numbers. Note that unnoticed feedback loop that came to dominate the market evolution. Nature and markets are weird that way: a path of least resistance for a high rate of exchange increased the purchase rate. (Frequency modulation dominates amplitude modulation when signal clarity is the dominating requirement: a good model for consumability).
3. HTML beat everything not by being a good design but by being a cheap easy to implement design with a language for which most could remember the basic elements. This is an aspect of ‘consumability’. Scaling out in the vertical not the horizontal. In longTailSpeak, the flatter curve has the high numbers and that is where consumability is critical.
Understand that I am not critiqueing ODF or the effort per se. I am critiqueing efforts to make a place for it by depriving space on the shelf for another choice by legal means that have no technical criteria. That is why Massachusetts backed off their initial position. To ascribe that to bribery or skullduggery as some have is to imply that the government of Massachusetts and the people of Massachusetts are without honor or brains, to claim that some/one are so much smarter that they can pick the standards for the state and force it for their own good. That is arrogance.
As long as ODF is increasing the overall consumability of its formats, ODF is winning the way that HTML and VHS won, by being easier to remember and apply and by fitting on the shelf. Yes there will be local inequities where requirements make that competition harder, but consider that Massachusetts did not say ODF cannot be used. They said it can’t be mandated for exclusive use. In other words, governments preserve options and when a choice is clearly better a better fit for the form and function, it will be on more shelves. Until then, they pay the costs of two video systems or accept that some video tapes won’t be available.
We’ve been surviving in a world with a lot more options than two for document formats for a very long time. We’ll keep on doing that with just two. My prediction is neither will prevail. A third option will emerge and it will probably be the simplest of them all. Will it be a common subset of both ODF and OOXML? That would be the smart bet. If that is what Bob is after, that will emerge naturally but I have to say today that is HTML and CSS for documents. What that is for spreadsheets is what we probably don’t know.
BTW: only the external tank is disposable on the Shuttle. The SRBs (solid rocket boosters) are recyclable. The decision to emphasize recyclable components led to the design that killed the crew in the first explosion because it led to the need to use segments to ship them for refurbishing thus, the O-rings. Thiokol didn’t like that design from day one and said so but costs were driving the design. By contrast, everything but the Apollo capsule was consumed in the Saturn systems and the one component that failed twic was the capsule. Saturn V systems were the most complex system built to that date but none failed (one came close: see POGO). Why? Two factors: a deeply experienced design team that failed together from Peenemunde to Huntsville before they build their last best system; two, emphasis on flight worthiness and readiness with zero defects. They had Zero Defects Days and this in a time when the plans were being drafted on boards using pens and slide rules while working in a converted turn of the century mill without air conditioning. Three: the only waste material was time. Everything else was wasted with abandon. Four: they refused to let manufacturers tell them how to cut costs or outsource. They built and tested it all locally then sent the plans to the vendors. The only thing they didn’t do was launch from Huntsville and they wanted to but were force to accept static testing. I grew up to the sound of those engines roaring. T’was lovely.
Today, NASA doesn’t know how to recreate the heat shields. They know the ingredients but not how the manufacturing was done and one of the last men who can tell them is dieing in a rehab hospital right now. So when you start arguing for ODF over OOXML, that is one argument in your favor regards long lifecycle systems. Unless someone can debug them, they did anyway.
Keep that in mind when you tell people that open source is better by nature. It isn’t always and in fact, web applications in general lead to some bad compromises in application designs once one quits designing portable documents. Statelessness is a bitch. The saving grace is lots of us know how to get around it not that getting around it is a good thing for the applications. It just makes the data more consumable.
No free lunch.
I think it would be rather natural to extend ODF with another file type: Project. An this will, of cause, be with respect of what is already in other open standards.
But first we must convince the developers of OpenProj, that XML should be used in file formats. As far as I can see, they use binary files at the moment.
But hey: Don’t talk too loud about the idea. We don’t want you-know-who to get there first, do we ?
Earlier, Haren said,
“Ideally, there should be a *single* purpose for any single Open Standard, resulting in each Open Standard being specialised to meet a specific application domain.”
ODF is one of a trio of open document standards currently maintained at OASIS, the other two being DocBook and DITA (the Darwin Information Typing Architecture). Considering the very wide diversity of document types covering hundreds of years of publishing conventions, its surprising how much of that ground is covered by just these three standards. ODF answers well to the full range of highly diverse “office” content (which itself is too limiting a term any more); DocBook has served well since SGML days for importing and managing narrative technical content (again, only a generalization–all these formats have escaped “office” and “techpubs”); and DITA, the newest (but already mature at 6 years of use), which parallels the componentization history of programming. OASIS sees no duplication in these standards, but rather sees hosting them as a way of helping industries find the standard get the best fit to their particular content requirements.
DITA’s strong point is specialization, which the “Darwin” in its full name alludes to. More than just a DTD, the architecture is based on an archetype “topic” that can be specialized to support either different types of information (reference, procedures, conceptual, and more) or different domains of semantic markup within topics. By moving the definition of types and domains out of standards and into the communities of use, it is now possible for consortia of companies with a common vocabulary to define shared specializations that apply uniquely to them, and which can be as rich as their semantic needs require. OASIS already hosts specialization subcommittees working on DITA specializations for Learning Content, Machine Industry, Semiconductor, and more on the horizon. Informal specializations include type and domain markup for API reference (which defines an intermediate class that unifies the “different-but-same” terminology and conventions for C++ and Java documentation), thesaurus, music collection descriptions, and more).
Because DITA and SL objects both depend on the same concepts of instancing and subclassing for more specific behaviors, I can readily see some interesting uses for DITA in Second Life: notecards could support hierarchies or regular structures for writers, collections of objects could provide documentation aggregated from the descriptions for the parts, products could provide catalogs with more descriptive fields (which would help solve the problem of name collisions or finding-by-synonym in search). Not only is the DITA definition an Open Standard, but it is supported by an Open Source processing toolkit that can serve up a range of outputs depending on what a user or application needs (such as HTML, PDF, or even venerable man pages–tantamount to structured notecards).
I just wanted to point out that Haren’s suggestion is far more prescient than may have been expected!
–Don Day, Chair of the OASIS DITA Technical Committee and IBM DITA maven
I wrote to Dave at Gantthead as a reader of his PM blog that is quite popular in the PM community…
all about Lotus Conections (Activities)
here is the outcome..
http://www.gantthead.com/blog/blogView.cfm?blogID=24
well worth consideration..
Chris, ECMA-376 on the long run will not be able to maintain fidelity for legacy documents, it’s a disaster waiting to happen.
Creating a new Open Standard for project management requirements does not stop OpenOffice.org, IBM Lotus Notes and other software implementing it.
ODF still remains relevant even if a new Open Standard for project management requirements is created.
By creating minimal set of format for each new Open Standard, the adoption of Open Standards can be done gradually case-by-case and also reduces the cost of implementation and increase the number of application choice. This achieves the long term goals for using Open Standards.
Increasing the set of formats in ODF, increases implementation cost thus lower adoption and higher risk of rejection.
I know your interested in the big picture.