Quoting "Joshua A. Andler" <joshua@...533...>:

Well... if we don't share too much code, at the least, we should snag their rendering engine. ;)

If the license is compatible, and the code is clean, yes!

I would be so tremendously happy if we could just replace the whole SPCanvas stack and be done with it...

And, you know, it would not be at all incompatible with later Cairofication. Cairo is simply the lowest-level layer of the rendering stack.

Personally, I'd vote that we take our good bits and put it in their program. Theirs is far more feature complete, but could use stuff like our clone tiler (or even the context free version that Mental said he wants to do), grid arrange, etc. That's my .02

Well, the one thing that Xara doesn't do is it's not first and foremost an XML application.

A key goal for inkscape is to be able to put arbitrary XML in your SVG documents, make minor edits, and save again without disturbing those extra non-Inkscape/SVG XML bits. Very, very few other applications of any kind which use an XML-based file format attempt to do that.

I don't know, though. The main thing is keeping the AST in memory, linked to the application-domain model. Maybe we could do that with Xara.

I would be very interested to hear bulia's initial thoughts.

-mental

On Tue, 11 Oct 2005 15:04:36 -0400, mental-uFjFfPRxV21eoWH0uzbU5w wrote:

Ok, so if they want copyright assignment for dual-licensing, that's out of the question. I wouldn't mind throwing them some bones in the form of LGPLed libraries, but that's about as far as I'm willing to go.

The term copyright assignment isn't mentioned, they still seem to be figuring out what they can/can't/will/won't do with the code once it's been released.

It's worth remembering there is a middle ground: it doesn't have to be copyright assignment for them to be able to use your code. You just have to figure out what is acceptable for both parties and then agree to it in writing. I guess if you're happy with the way your code is being used and therefore aren't interested in suing them, who owns the copyright matters less.

I don't know what sort of things you'd find unacceptable. Personally (imagining for a moment I was an Inkscape hacker) I wouldn't mind them doing a commercial Windows release with stuff like Pantone, user manuals etc including my code. But I probably would mind them selling on my code for use in other proprietary products. Figuring out what is OK and what isn't would be a priority for me before contributing.

thanks -mike

On Tue, 11 Oct 2005 16:58:21 -0400, mental-uFjFfPRxV21eoWH0uzbU5w wrote:

Making individual agreements with contributors isn't practical.

No, but if on discussion it turns out there's a common theme amongst what people want then a GPL+exceptions type license could also work. Licenses are just agreements between people, and (hopefully) people are more flexible than code.

thanks -mike

Bryce Harrington wrote:

One thing to keep in mind is that one of the argues AGAINST a company open sourcing their codebase is a worry that "then they'll just take our code, and we'll fail." So I think it would be most prudent to talk not about snagging code, but _sharing_ it.

Oh Bryce, you're being so polite :) Seriously though, they need to figure out how they want to deal with the community. Until they define that publicly, I think most discussion here is speculation. I'd also imagine that they have engineers reading this list, and the fact that they haven't commented yet says that they're not entirely sure yet. Hopefully they've gotten some good ideas on how people will react to several scenarios.

...

And, you know, it would not be at all incompatible with later Cairofication. Cairo is simply the lowest-level layer of the rendering stack.

Charles and I also discussed Cairo a bit. They're aware of Cairo, and some collaboration is certainly possible there too in the future, but Xara's renderer is *tons* faster than Cairo at present, so that's even more of a concern for them than it's been for us.

While I see that, I think Cairo is the better horse for the long term. As the Cairo developers start moving towards hardware acceleration, comparing them with a piece of software is simply unfair. GPUs today are impressive, and if Cairo can tap into even a small percentage of that it'll be crazy. Now, I realize that a renderer includes more than Cairo, but unless they're interested in having their renderer interface with Cairo I think it is significantly less interesting. I'm not sure that WxWidgets is ever planing on interfacing with Cairo directly, so there may be some technical limitations as well. That will require more investigation, there may be ways to use both.

--Ted

Bryce Harrington wrote:

On Wed, Oct 12, 2005 at 10:23:39AM -0700, Ted Gould wrote:

...

Oh Bryce, you're being so polite :) Seriously though, they need to figure out how they want to deal with the community. Until they define

This seems very simple to us, but I've had first hand experience at OSDL with the myriad of ways that companies run into trouble figuring out how to deal with the community. I think we all know how different open

I think Ted is right. As a graphics software only company they are directly in competition with Inkscape - thus, all this code merging talk sounds strange (I don't see Trolltech trying to merge their code with Gtk or vice-versa - interops yes, merging no). Most successful commercial companies in the open source community have made it thru services: part add-ons, part support, part operations, part packaging, part data warehousing, etc - I think to be viewed as an open source friendly company Xara needs to operate in terms of being a graphic design services company utilizing community software as a base - but they haven't exactly said what they are thinking along these lines and if they honestly don't know well maybe they should be flying us in for some strategic consulting!

On Thu, 2005-10-13 at 13:06 -0700, Bryce Harrington wrote:

This seems very simple to us, but I've had first hand experience at OSDL with the myriad of ways that companies run into trouble figuring out how to deal with the community.

Well, after reading the e-mail you've forwarded, I'm not optimistic. The reason being that they still seem focused on being in control. Now I don't think they should release a totally random project, but if they are going to never give an outside developer access to their version control, the barrier for contribution is too high. I think we've got roots in a project where one entity controlled the repository and rewrote all the patches ;)

It's in our best interest to help them start communicating with us (if not on this list, then perhaps on some other forum or technology they're more comfortable with), because once that's established, a lot of our concerns can just be worked out normally.

One thing I found interesting in Linus' "Just for Fun" was when he was talking about Netscape open sourcing Mozilla. He mentioned how they still made decisions in conference rooms, and how that made outside contributions impossible. I don't care if it is on this list, but if they're not willing to make their product decisions transparent -- it is going to be difficult for others to get involved.

That is possible; I've invited Charles to encourage one of his engineers, testers, or sysadmins to join the list; if they're on, I hope they'll jump in and say hi.

I hope so too.

I would have to say that I'm not an optimist on this whole thing. I'd love to be proved wrong, but right now, I'm worried about it.

--Ted

Bryce Harrington wrote:

Trust me, I am *WELL* aware of this. Unlike Linus, I myself was one of the people from the open source community who jumped into the Mozilla project right from the start and was helping with coding, bug fixing, etc. And I got burned first hand from the conference room phenomenon. I had been working on some ideas I had with generalizing the toolbars into a general purpose syntax that would work across all of the platforms, when one day the Netscape guy I was assisting came back and said they'd had a face to face meeting and had a "really exciting idea" (XUL).

Needless to say, I was extremely disenchanted by the fact that this decision was made that totally invalidated all my own work, yet I'd had absolutely no say in the matter. I thought XUL was an interesting idea, and it was sort of cool that it was inspired in some fashion from what I'd done, but I wasn't included in the discussions that came up with it. This really burnt me out, and I basically gave up on Mozilla after that, and wandered off to better things.

Anyway, trust me, I know *exactly* the pain that can result from these sort of "smokey back room deals".

This is a great story, and I hope that you've told it to the people at Xara. I was reading "Things that make us Smart" and the author was talking about how storytelling is a very human interaction. When he observed business meetings he noticed that they usually started with someone giving a slide presentation containing lots of data, then everyone sat around and told stories about the problem, and then a decision was made. The stories were closer to the decision than the data.

Bryce, this is your story; tell it! (in 500 words or less, please ;)

Also, I don't think that Xara is getting beat up on, I think that we're debating strategy -- I like John's strategic consultant term (it's going on my resume). Hopefully they'll read the archives and learn some potential problems, so when the do announce their policies (and I'm more worried about policy than code) they'll impress us all.

--Ted

On Oct 14, 2005, at 12:02 AM, Ted Gould wrote:

Well, after reading the e-mail you've forwarded, I'm not optimistic. The reason being that they still seem focused on being in control. Now I don't think they should release a totally random project, but if they are going to never give an outside developer access to their version control, the barrier for contribution is too high. I think we've got roots in a project where one entity controlled the repository and rewrote all the patches ;)

I've been in touch a little with at least one person inside over there since the announcement.

From all things taken together, I'm getting a very different impression from yours. They seem to be getting a good balance on things, and seem honestly interested in getting those barriers as low as possible. Of course, if they listen to us properly, we can get even more done for both sides. I know the people on our side can really make this work, and it's looking like the people "over there" on that side want to do things well.

Besides, I have a personal vested interest to keep Software Engineering a paying profession for quite some time, so helping them refine a good business model to keep that alive is a win-win for most people.

One thing I found interesting in Linus' "Just for Fun" was when he was talking about Netscape open sourcing Mozilla. He mentioned how they still made decisions in conference rooms, and how that made outside contributions impossible. I don't care if it is on this list, but if they're not willing to make their product decisions transparent -- it is going to be difficult for others to get involved.

Well... I do have *some* interest on that angle (and with those projects). First off, the state of their initial code might make a huge difference. After that, then the corporate interest is something to keep an eye on. I recall, however, that one of the huge criticisms of the project was that management at "the company" was making all the decisions, ignoring most of the input from engineering. Even to the point of ignoring the technical lead of the project who happened to be on the corporate payload. So it wasn't even outside contribution that was hard... (you can look up the news items of the time to see details on that)

Many people have a good feel for the things that caused Mozilla the most problems, so as long as we keep an eye out we can probably avoid the worst of them here.

On Fri, 2005-10-14 at 00:54 -0700, Jon A. Cruz wrote:

Besides, I have a personal vested interest to keep Software Engineering a paying profession for quite some time, so helping them refine a good business model to keep that alive is a win-win for most people.

Not to put too fine a point on it, but the entire shrinkwrap software industry could curl up and die tomorrow and 90% of software engineers would still have jobs.

In contrast to the usual shrinkwrap model of "We will write this software for free[1], and try to subsidize the effort after-the-fact through licensing fees[2]," the business model for the remaining 90% of the industry is, "We are paid directly for the work of {writing,customizing} software to perform [needed function]."

While the latter does include contractors, most such software engineers are not; they work for companies in various industries, writing software for in-house use.

For them, unlike the shrinkwrap industry, Free Software is clearly an asset.

"Ah," you ask, "but what about specialized industries? Surely there's not enough of a pool of Free Software developers with specialized knowledge out there to produce the software they need? Surely we need the proprietary model to fund the production of that sort of thing?"

What would happen, in the absence of a proprietary vendor to supply specialized software, is that the companies in the particular specialized industry would get together, form a consortium, and pool their efforts to get the needed software written. The short-term costs would be a little higher, but there is a long-term economic advantage from the absence of ongoing licensing fees (which in most specialized industries tend to be inordinately high[3]).

I know they would do that, incidentally, because it's what happens today. Not all industries have a proprietary vendor ready to supply them. However, even when they do, those sorts of efforts go into providing interchange standards and tools for migrating data between the various proprietary vendor silos (which the vendors have comparatively little interest in providing -- until the consortium develops the standard/tools, and the vendors forced to support them due to customer demand).

If you think that's a good thing, economically, I'd suggest reading up on the Broken Window Fallacy.

Now, I realize Xara is trying to do something different[4], and that in Xara's case they can also benefit from the artificial market created by Pantone's IP licensing, but whether they succeed or they fail, programmers are still going to be eating.

-mental

[1] Sure, the individual programmers get paid right away (most of the time). But the company doesn't.

[2] Of course, the programmers don't normally get to share directly in the licensing revenue either.

[3] Anecdotal extreme example: at one company I worked for, we were paying seven figures/yr for what was essentially a steaming pile of ASP scripts on top of an MS Access database (though it had later been ported to MSSQL). It was developed, apparently, by a summer student who had never really learned about databases or a lot of other important things. No normalization. No transactions. No consideration of concurrency. Successful installation took a team of two engineers from the vendor three days. I'm not going to say it was overpriced, because clearly the demand was there, but ... man ...

I think an industry consortium could have done just a wee bit better, cheaper.

[4] In fact, it's entirely possible that this Xara-Inkscape situation may end up becoming an industry consortium sort of thing. A lot of professional design places have programmers on staff these days for web work, and Xara is in a better position to tap into this than Inkscape is alone. They're certainly in a position to provide the things that the big vendors, "Macrobe", and Microsoft, won't.

My thoughts on this:

1. WOW. We live in interesting times.

2. In the near term, it's a win-win. We get access to the Xara code and can borrow from it. Xara gets a publicity boost and good carma.

3. In the long term, it's a bit less rosy. Only a few bits of code are easy to borrow from program to program; most are difficult to impossible. Merging the two programs is not too realistic. Living side by side is more probable, but that means competition. Competition is tough. There's only so many Linux people interested in vector graphics, and they will need to decide which project to contribute to. Few if any people will be able to learn both codebases to contribute to both. This will hurt us (developers drain) and this will hurt Xara ("hey, we went open source, why so few contributors?").

4. In the end, the two most likely results are:

4a. Programs diversify enough so that each can stand on its own merits. Things like the connector tool in Inkscape are a step in this direction. Unfortunately for me personally, I'm not involved in this; things that interest me and that I work on are generic vector editing capabilities. Xara seems to have some sort of focus on web graphics (they have a tool for navigation buttons for example), but it's not enough to diversify. So if this happens, chances are it's Inkscape that will diversify into areas such as technical drawing, diagramming, maps, animation, complete SVG support etc. whereas Xara will more likely stay focused on plain vector drawing.

4b. One of the programs wins and cannibalizes the other. If Xara wins, Inkscape will stagnate and many people will feel betrayed and/or abandoned. If Inkscape wins, Xara will be hurt, and it will scare away other companies who might be considering going the same road. In proprietary software, the winner is not the best product but the one with better marketing (Xara itself is an example of that). In open source, the winner is also not the best product, but the one with better community. So, the critical question is how Xara is going to build and steer its community. They say the good words about "combine the best of Inkscape and Xara", but it remains to be seen what exactly they consider the best in us and in them, and how exactly they will go about combining it.

5. The things that first come to mind with regard to borrowing from Xara are its renderer and the CDR import support. Unlike Mental I don't consider Inkscape's SPCanvas to be that bad; it's small and reasonably transparent. What's really bad and scary is the livarot renderer, and that's where the slowness lies. Xara's renderer is indeed very fast, and I would love to see it incorporated into Inkscape and/or Cairo.

6. I would be very interested to see which toolkit Xara will use on Linux, if any. To me, perhaps the worst part of Inkscape is the GTK, because I have little control over it. It has problems even on Linux (such as the open dialog not working properly, see bug 1018798) but it's much worse on Windows (and no, I'm not referring to win98; there are other extreme annoyances, such as menus not working properly (bugs 954797, 1250240) and the dialogs-not-on-top (bug 969321) as well as the general clunkiness and clumsiness). I don't know if there exists a better cross-platform toolkit but I would like to find out. So I will be very interested to see how Xara does its porting; to me it seems that their UI has too many Windows-specific things to be ported easily.

-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

Quoting bulia byak <buliabyak@...400...>:

4. In the end, the two most likely results are:

4b. One of the programs wins and cannibalizes the other.

I think it is fairly likely that Inkscape will end up cannibalizing Xara; code flow is likely to be mostly one-way because the Xara folks have introduced extra barriers to contributing code on their side (particularly if they want copyright assignment).

Xara's advanced features may give it some leverage, but I don't know how much.

5. The things that first come to mind with regard to borrowing

from Xara are its renderer and the CDR import support. Unlike Mental I don't consider Inkscape's SPCanvas to be that bad; it's small and reasonably transparent. What's really bad and scary is the livarot renderer, and that's where the slowness lies. Xara's renderer is indeed very fast, and I would love to see it incorporated into Inkscape and/or Cairo.

Let's not forget livarot for computational geometry either. If Xara has boolean shape operations, then it would also have computational geometry code which we could use to replace the livarot in its other capacity as a comptuational geometry library.

In principle, anyway.

Although I hope it is not the case, we cannot rule out the Xara code being as opaque as livarot; proprietary software tends to fester because there is not a priority on aesthetics of code, limited code review, and no public exposure to shame sloppy programmers.

6. I would be very interested to see which toolkit Xara will use

on Linux, if any. To me, perhaps the worst part of Inkscape is the GTK, because I have little control over it. It has problems even on Linux (such as the open dialog not working properly, see bug 1018798) but it's much worse on Windows (and no, I'm not referring to win98; there are other extreme annoyances, such as menus not working properly (bugs 954797, 1250240) and the dialogs-not-on-top (bug 969321) as well as the general clunkiness and clumsiness). I don't know if there exists a better cross-platform toolkit but I would like to find out. So I will be very interested to see how Xara does its porting; to me it seems that their UI has too many Windows-specific things to be ported easily.

I think, as far as many of these annoyances go, Qt is the best cross-platform toolkit. However, it doesn't solve all problems (e.g. Rosegarden has problems with "trasientization" of their transport dialog just as we have).

Additionally, use of Qt signals/slots requries a non-standard dialect of C++ (MOC, handled by a special preprocessor), and it does not play so well with STL and other standard C++ library facilities.

Given that, there's a strong bias towards using Qt's own container classes and such, so Qt has a tendency to "infect" non-GUI code too, much like MFC on Windows.

gtkmm, despite the deficiencies it inherits by being built on GTK, works very hard to stay within standard C++ and be compatible with STL idioms.

-mental

On Tue, Oct 11, 2005 at 08:04:49PM -0300, bulia byak wrote:

Overall, I can't help feeling very positive about this whole thing. I love it that their motivation - to create the best vector editor on Earth - is exactly the same as mine. And no matter which of our two programs gobbles the other, we now have significantly better chances of reaching that goal than we did yesterday. As for increased competition for Inkscape, I agree with Mental that this is healthy.

At this stage, I think what we need to do is find the "common ground" between our two projects.

There are many differences that we *could* focus on. They're commercial oriented, they communicate and work in different ways than us, they have a different codebase using a different widgetset, we hold SVG to be the main purpose while they are geared for drawing in general, and on and on. We could easily allow these differences to define us as distinct groups and keep us separate, to the detriment of both. It's easy in human nature to divide into us-vs.-them groupings.

But consider that we do have a lot in common. Both of us want to bring a very powerful open source graphics tool to the world. We want to have the best open source vector drawing tool, Xara wants to have the best vector drawing tool period (wouldn't it be great to achieve that!) We want to have a really good alternative to Adobe and Microsoft products; they do too, perhaps even more fervently than us! Looking at the GUI, it's also evident that we share ideas on how the GUI should look - the differences between us are in the details, not the fundamentals.

There is strong potential for some solid common ground between us. Also look at the steps they've already taken to try to bridge our differences. They've ported their application to Linux, so it will be easier for us to try it out (think about how painful it'd be to us Linux guys if they'd have only released code for the Windows version), they've open sourced their code under the GPL (thank god they didn't choose some incompatible OSS license), and are funding someone related to Inkscape in an effort to bridge the file format issue between us.

I see a lot of potential benefits for us in working with them. As others have mentioned, it opens several alternatives for us to finally address the Pantone issue. Several people have mentioned other problems that we could finally solve by leveraging their codebase, like Corel Draw support, a better renderer, various features we lack, and the best performance in the industry.

We also have strengths that we can lend Xara. They're new to this whole open source thing, so will need to learn the types of best practices that we've benefitted from with Inkscape; we can help teach them this culture. We've got some excellent processes for involving users in solving issues that come up. We have built a strong name in the open source community and with our cooperation they can leverage our community successes. We know how to do iterative development using an evolutionary release approach. And perhaps most importantly, we have skilled developers to lend to the cause. We have expertise in areas that they don't, especially in packaging and supporting multiple operating systems. Mike Hearn has already taken the initiative to share some of this experience with them, I'm sure we can give them a lot more tips and suggestions going forward.

Looking at other organizations that combine open source and commercial aspects, we can see how others have benefitted. The Linux kernel community has benefitted greatly from symbiosis with Redhat, Novell, IBM, etc. in terms of funding, jobs, increased visibility, and so forth. Commercial organizations can also provide a level of QA that goes beyond what the community can achieve alone; Ubuntu/Debian and Netscape/Mozilla give good models of how this can be a win-win-win relationship for the community, business, and users. I bet Inkscape can achieve the same with Xara.

However, building good relationships takes work, it's not something that just happens. It's way too easy to fall into the us-vs-them trap, and gain nothing; it will take work on our part to help show them how open source works, to encourage them to brave the risks, and forgive their missteps as they learn the dos and don'ts. We need to find ways to try out new ways to communicate with them, and look for opportunities where we can work together on things and get to know each other. Success builds on success, so even small collaborative achievements in the near term can lay good groundwork for future possibilities. I have no idea how this will turn out in the long term, but the trick is going to be to get off on the right footing here at the start; if we do good things now, we can get ourselves on a good path that will lead someplace very cool down the road.

Bryce

On Tue, Oct 11, 2005 at 04:50:10PM -0400, mental@...3... wrote:

In some areas, it might work best for us to "meet in the middle" and do some things as LGPLed libraries which could be used equally by a commercial Xara and the GPLed side (Inkscape or GPL-Xara).

In those cases, there would be no asymmetrical barriers to contribution -- to the extent they both used those libraries, both projects would benefit equally from any work on them.

This (LGPLing code) was one of the things we talked about. It makes sense and sounds doable on their end. On our end it's a bit more complicated by the fact that the original copyright holder for much of our code is still Lauris, so it's not in our ability to relicense code as LGPL. For stuff where Inkscapers have been the original creator, it'd be more feasible.

I agree that requiring copyright assignment would be asking too much.

Bryce

On Tue, Oct 11, 2005 at 08:22:39PM -0300, bulia byak wrote:

Another focus of Xara is on bitmap manipulation. They have a built-in Picture Editor, something like a primitive Photoshop. I think it's safe to bet Inkscape will never have such a thing - why do it if we can just call Gimp instead.

Well, depends what you mean by "have such a thing": calling gimp code would count as having such a thing; though currently we don't do that at all to my knowledge, and we certainly don't currently make it easy to edit embedded bitmaps, or have gimp layers implemented as separate <image/>s, or allow other vector objects to be visible when editing a bitmap.

pjrm.

On Tue, 11 Oct 2005, bulia byak wrote:

6. I would be very interested to see which toolkit Xara will use on

Linux, if any.

The download page says "We have a new cross-platform code base, WXWidgets based, that is cross platform C++..."

Michael

On 10/11/05, bulia byak <buliabyak@...400...> wrote:

6. I would be very interested to see which toolkit Xara will use on

Linux, if any.

The very first question I had about Inkscape was "why on Earth gtkmm and not wxWidgets, which would give Inkscape portability and native look on any OS"?

So, Xara went wxWidgets and specifically wxGTK on Linux.

Alexandre

but it's much worse on Windows (and no, I'm not referring to win98; there are other extreme annoyances, such as menus not working properly (bugs 954797, 1250240) and the dialogs-not-on-top (bug 969321) as well as the general clunkiness and clumsiness).

...and if you think the UI is clunky, then the development experience is even clunkier. If Xara were releasing their Windows stuff and it used the Microsoft toolchain I wouldn't hesitate to defect, and I'm saying that even before I've know whether their source code is legible. A debugger that doesn't crash just as you think you're finding the bug, a compiler with precompiled headers that (mostly) don't cause internal compiler errors, debug builds that don't require a gig of physical RAM to be able to link in finite time, the list goes on. Developing on Inkscape is just not as much fun as it should be, and I've always wanted a single programme that is both Artworks and Impression.

OK, rant over. The main purpose of this post is because I've remembered that Xara's offices aren't far from where I live (27 miles as the Google Maps flies, to be precise). I'm not sure whether this is going to be useful information, but I figured it's worth pointing out just in case it needs to be known (for the purpose of launching a daring midnight raid to steal their Pantone licence, perhaps? :-) ).

Richard.