Embarcadero Delphi is sold!

[JuhaManninen]

I sent a mail to BergSoft about their Next components. I offered to help their porting process for free if they decide to do it. I am planning to contact some other vendors, too.
The biggest obstacle for vendors until now has been the delivery of binary-only evaluation and demo versions. For a cross-platform open source system it is just too difficult. That is why most component vendors decided not to support Lazarus.
In practice they must change their delivery policy. They must include source code always, maybe including a dual licence or otherwise restricting it for evaluation purposes only.
Let's see what BergSoft says ...

Well, BergSoft did not say anything. Not even a "Sorry, we are not interested" reply.
Partly it is understandable. Open source developers want everything for free. Market for commercial Lazarus libraries is small, for a company it does not make sense to put resources into it.
Pity.

About the license change idea, I should have explained it better when taazz suggested dynamic packages. I had thought about different options only in my head.
Zeljko discussed with some component vendors few years ago. Even if dynamic binary packages were supported, the biggest question was how to deliver evaluation versions of their components.
For Delphi VCL it is enough to support few Windows versions.
For Lazarus LCL the number of platforms skyrockets. There are a few Mac OSX versions, even if you stick with Intel CPUs. Then there is Linux. Even with Intel x86 and x86_64 you cannot trust that a certain library or library version is there. And there are other CPUs, ARM based gadgets are already usable as personal computers and in future more so.
If a component vendor puts time and energy to support all the platforms it can think of, soon somebody surely asks support for his new MIPS based gadget where FPC/Lazarus can be installed ... or some other new platform.

Dynamic binary packages can solve the problem only in some corner cases. It will not be a generic solution for component vendors.
The biggest benefit of dynamic packages will be that Lazarus binary installed in a write-protected directory can stay there. Only packages need to be compiled.

The only real solution is to provide source code always.
There are successful commercial SW libraries with a dual license. QT comes to mind but there are more. It however requires a fundamental change in the business model. If somebody is in close contact with component vendors, please communicate this idea to them.
Still, it may turn out we must stick with open source components. Business models around Delphi are so different.

[taazz]

I sent a mail to BergSoft about their Next components. I offered to help their porting process for free if they decide to do it. I am planning to contact some other vendors, too.
The biggest obstacle for vendors until now has been the delivery of binary-only evaluation and demo versions. For a cross-platform open source system it is just too difficult. That is why most component vendors decided not to support Lazarus.
In practice they must change their delivery policy. They must include source code always, maybe including a dual licence or otherwise restricting it for evaluation purposes only.
Let's see what BergSoft says ...

Well, BergSoft did not say anything. Not even a "Sorry, we are not interested" reply.
Partly it is understandable. Open source developers want everything for free. Market for commercial Lazarus libraries is small, for a company it does not make sense to put resources into it.
Pity.

They even might interpret your offer as a scam to get your hands on their source. we can talk about what ifs some other time though.

About the license change idea, I should have explained it better when taazz suggested dynamic packages. I had thought about different options only in my head.
Zeljko discussed with some component vendors few years ago. Even if dynamic binary packages were supported, the biggest question was how to deliver evaluation versions of their components.

What do you mean how? a zip file with dynamic packages would do for now how did they provided them for delphi before all this nice installers existed?

For Delphi VCL it is enough to support few Windows versions.

Then again they don't have to support them all, they could say minimum windows version is vista or windows 7. As far as I remember delphi supports more platforms than windows I do not see them having any problems with out supporting them too.

For Lazarus LCL the number of platforms skyrockets. There are a few Mac OSX versions, even if you stick with Intel CPUs. Then there is Linux. Even with Intel x86 and x86_64 you cannot trust that a certain library or library version is there. And there are other CPUs, ARM based gadgets are already usable as personal computers and in future more so.
If a component vendor puts time and energy to support all the platforms it can think of, soon somebody surely asks support for his new MIPS based gadget where FPC/Lazarus can be installed ... or some other new platform.

True and what stops them to say they do not currently support that platform exactly?

Dynamic binary packages can solve the problem only in some corner cases. It will not be a generic solution for component vendors.

What are you talking about with out binary dynamic packages the tool is unusable with binary dynamics packages the tool is usable but to much work? Let me ask you this how are the devexpress controls used in the macos from delphi? If they are not used then why its a problem to only support windows in lazarus too? What makes them think that they have to support all the platofrms?

The biggest benefit of dynamic packages will be that Lazarus binary installed in a write-protected directory can stay there. Only packages need to be compiled.

The dynamic packages solve two main problems 1) I can mix and match open and closed source as I see feet. 2) I can give the same feature to my clients. That's it, everything else is wishful thinking.

The only real solution is to provide source code always.

Solution to what problem? if the only solution is the source code then why I'm not able to cross compile for raspberryPI from my windows installation? isn't the source there? Why haven't you provided that option yet? how about remote debugging? why there is no installation to help me do that from lazarus? You as an open source project can leave some things for the end user to solve they as a commercial entity must provide solution having the end user compiling the source for unsupported platforms might in end prove to be more support intensive than providing ready binaries for that platform your self.

There are successful commercial SW libraries with a dual license. QT comes to mind but there are more. It however requires a fundamental change in the business model. If somebody is in close contact with component vendors, please communicate this idea to them.

I'm sorry I do not see the fundamental change that you talk about so I'm going to simple smile and let it go for now.

Still, it may turn out we must stick with open source components. Business models around Delphi are so different.

Well that is your choice, in one hand you "demand" that only open source component can be used in your tool and all the commercial vendor will stay away as they already do, on the other hand you provide them with the opportunity for their libraries to be used in other systems, systems that delphi does not support and  some vendors might take advantage of these and use the tool. In both cases you as an open source community might not benefit from it. Its up to you if you want to put the effort or not. I can say for sure that if I had dynamic packages for windows today I would stop supporting linux application until they where available for linux too or I might try to make them work on linux my self.

In any way it seams to me that you are trying to solves problems that should be solved from the vendor not you if the vendor wants to use the "build once compile everywhere" in his site he has to support at least all the major platforms otherwise he can simple advertise the platforms he supports. That's all the tool can do and it shouldn't try to exit it boundaries.

Any way, you provide the tools let them choose if they want to use them the only thing sure is that as it is they seam to stay away.

[JuhaManninen]

taazz, there is at least one misunderstanding now. I am not against dynamic package feature in Lazarus. Quite the opposite, it is one of the missing pieces together with project groups, proper Unicode support, Pascal debugger, bug-free docked IDE, high-DPI support etc.
Support for dynamic packages must be implemented in FPC before it can be implemented in Lazarus.

The problem with binary packages was explained by component vendors at 2011 when Lazarus 1.0 was released. Was it Devart which already supports Lazarus or some other vendor, not sure. Maybe Zeljko could tell.
The idea was to sell big amounts of components and then many platforms should be supported.
Your customers have a limited selection of platforms, maybe just Windows. I believe a dynamic package is the right solution for you. I did not think about all use cases clearly.

I believe many Delphi VCL comp vendors think about the future. VCL is Windows only. Windows is loosing its position as a dominant platform.
How are components for FireMonkey + its platforms delivered? I have no idea.
Anyway, Lazarus is different from Delphi. The IDE itself can be installed in many platforms. Easier cross-compilation would be nice but it does not really help with component installation. To utilize the full potential of Lazarus all its platforms should be supported, and that requires source code.

I'm sorry I do not see the fundamental change that you talk about so I'm going to simple smile and let it go for now.

The change is to give sources for free to anybody under an open source license, compared to giving them to paying customers only.
That's what a dual license is about.
In case of QT the open source license is used more often than the commercial license, yet there are enough paying customers to make it profitable.

[marcov]

The problem with BPLs is that they suffer from the same versioning as delivering .o's and .ppu's.

So basically evaluation versions are not really helped by .BPL, since the number of precompiled versions is the same.

It is just that the .o's for designtime-only units disappear. (but you have two sets of .ppu's with and without packages, just like in Delphi)

See e.g. http://wiki.freepascal.org/packages#What_problems_do_packages_not_solve.3F

[rtusrghsdfhsfdhsdfhsfdhs]

@JuhaManninen:

Windows is loosing the position? Windows has ~95% market share currently. Oh btw Linux compiler is in the works
for Delphi. Coming most likely March 2016

[JuhaManninen]

Windows is loosing the position? Windows has ~95% market share currently.

Yes if you leave out the majority of world's computers from your statistics.
However the trend and future are more interesting than the current situation. Personal computing is moving from Windows to other OS/platforms in a rapid pace.

Oh btw Linux compiler is in the works for Delphi. Coming most likely March 2016

Do you know for how many platform variations the vendors deliver FireMonkey components?
My knowledge is only about VCL components.

[ykot]

Windows is loosing the position? Windows has ~95% market share currently.

Again, can you please better inform yourself before posting stuff like this? And if you do, please cite your sources. If you look, for instance, on this page regarding share of operating systems, Windows is pretty much "no go", except on desktop only and even there it's 91.45%, not 95% as you state. However, since desktop is losing market share, by number of devices sold, Android is really the predominant platform with 48.1% market share.

Edit: also, please state your sources regarding:

Oh btw Linux compiler is in the works
for Delphi. Coming most likely March 2016

[taazz]

taazz, there is at least one misunderstanding now. I am not against dynamic package feature in Lazarus. Quite the opposite, it is one of the missing pieces together with project groups, proper Unicode support, Pascal debugger, bug-free docked IDE, high-DPI support etc.
Support for dynamic packages must be implemented in FPC before it can be implemented in Lazarus.

The problem with binary packages was explained by component vendors at 2011 when Lazarus 1.0 was released. Was it Devart which already supports Lazarus or some other vendor, not sure. Maybe Zeljko could tell.
The idea was to sell big amounts of components and then many platforms should be supported.
Your customers have a limited selection of platforms, maybe just Windows. I believe a dynamic package is the right solution for you. I did not think about all use cases clearly.

I believe many Delphi VCL comp vendors think about the future. VCL is Windows only. Windows is loosing its position as a dominant platform.
How are components for FireMonkey + its platforms delivered? I have no idea.
Anyway, Lazarus is different from Delphi. The IDE itself can be installed in many platforms. Easier cross-compilation would be nice but it does not really help with component installation. To utilize the full potential of Lazarus all its platforms should be supported, and that requires source code.

I'm sorry I do not see the fundamental change that you talk about so I'm going to simple smile and let it go for now.

The change is to give sources for free to anybody under an open source license, compared to giving them to paying customers only.
That's what a dual license is about.
In case of QT the open source license is used more often than the commercial license, yet there are enough paying customers to make it profitable.

I'm not trying to make a case for or against packages although it seems that I have being pushing for packages in my messages. I'm only trying to 1) distinguish between facts and misconceptions and 2) define the boundaries of what is or is not the tools responsibilities. In your posts you talk about following the open source model to make money which is a bit ironic because the fpc and lazarus project are following this model and yet they don't make enough to support a development team. As far as I can see no one on the lazarus team (or the fpc for that matter) has managed to attract funds that would allow a single person (eg a support personal) to be hired. In combination with my inability to understand the open source model or make money from it I have no confidence that it works at least not in the way we are trying to make it work. So excuse me if I'm not supporting a model that is clearly not working for us.

Now if we go beyond the business model, lazarus is a tool and a good tool. what are its responsibilities? Its use cases?

I don't think its place is to dictate that you have to use a transaction no matter what, or you have to share the source, what ever you might think those should be choices a user makes for his target environment. The focus should be to make it easy, clean, stable to use and cover ones needs with out hacks and short circuits.

You are not responsible if my binary destribution does not work with the custom made fpc and lazarus the user X created, that is my problem. You are responsible if my distribution made with lazarus 1.4.2 win32 does not work with a clean 1.4.2 win32 lazarus installation and that's it, if some one wants to build a custom fpc and lazarus then its hes responsibility to make sure that the controls he is using will work with his custom build not mine not yours.

Well it feels that I'm rehashing the same points over and over again I hope that my choice of examples is clear enough if not I'll try to clarify even more.

In short yes releasing a lazarus version in binary form could be challenging but they only need to support the version they are using or have the less problems/bugs with their controls.

Its Lazarus job to make it easy for them to support as many releases as possible with out sacrificing features in the process.

Lets focus on extending and fine tuning lazarus to a stable release cycle that has the same behavior between platforms for the absolute minimum controls needed, everything else will start to fall in place the community will stop using custom builds (eg fpcup) and rely on the installer provided by the team for installation/update in order to make sure that their commercial controls will support their version and the vendors will start to rely on the lazarus stable releases and so on and so forth.

The problem with BPLs is that they suffer from the same versioning as delivering .o's and .ppu's.

So basically evaluation versions are not really helped by .BPL, since the number of precompiled versions is the same.

It is just that the .o's for designtime-only units disappear. (but you have two sets of .ppu's with and without packages, just like in Delphi)

See e.g. http://wiki.freepascal.org/packages#What_problems_do_packages_not_solve.3F

I'm aware of some of the problems that packages have, never tried to build a package solution or support one so far so I'm aware that there are technical details that I can not even envision at the moment but I'm confident that we can establish some rules of contact that will allow us to minimize any conflicts or misbehavior we might have and in time stabilize the release cycle enough to allow binary compatibility between releases (or not) but first lets have something to moan about. Its far better to have a stone axe to  build your hut than to wait around until the copper is discovered, which I think it has already been discovered.

All moaning rights reserved.

[rtusrghsdfhsfdhsdfhsfdhs]

This guy apparently has a source inside Embarcadero... 
https://jonlennartaasenden.wordpress.com/2015/09/18/delphi-for-linux-immanent/

Win 7 + Win 10 + Win 8.1 + Win XP + Win Vista = 92.48%

[Graeme]

Now FPC cannot compile my old Delphi 4 code anymore

Then change those units to use the Delphi compiler mode:   {$mode delphi}
Various units (even in the same project) can have different compiler modes.
Or compile your whole project with Mode Delphi. That is what the various compiler modes are for. The OBJFPC mode is probably the most strict - but also the most "correct" in terms of the Object Pascal language.

Regards,
  G.

[Graeme]

It has an even number  . 4,6,8 were disasters. 3,5,7 were highly stable and D7 is still highly regarded and much used.

+1

[x2nie]

taazz, there is at least one misunderstanding now. I am not against dynamic package feature in Lazarus. Quite the opposite, it is one of the missing pieces ....

Your customers have a limited selection of platforms, maybe just Windows. I believe a dynamic package is the right solution for you. I did not think about all use cases clearly.

The problem with BPLs is that they suffer from the same versioning as delivering .o's and .ppu's. ...

...
 Its far better to have a stone axe to  build your ...
than to wait around until the copper is discovered, which I think it has already been discovered.

In my humble opinion, tazz's suggestion (about dynamic package) is the most reasonable:
Dynamic package is the highest priority bottle neck that's needed to be solved soon over other pending features of Lazarus/fpc. This way seem as clear in several many case, such as :

• Delphi is sold, Lazarus is demanded to allow proprietary pascal code used by Pascal community.?
  --> it maybe solved by dynamic-package
• enrich Lazarus design tools / editor productivity, gain more (multi) purpose IDE, more customizable to user need, etc.
  --> it maybe possible by dynamic-package (similar to Delphi 'expert' things)
• start funding (finance) and enhance Lazarus/FPC development tasks
  --> by commercial vendor's joining
• reduce time on user-side of developing a component (bacause IDE wouldn't need to be recompiled each time component's modified). ==> Disk is cheap, but time is cost.
  --> by dinamic type / dynamic package allowed.
• Any other IDE provider has their own marketplace / code-exchange, Lazarus has wiki which is not trully integrated over its pages (hard to search). Dynamic package would be a new commodity to Lazarus community. ?
  --> just similar to iTunes for music commodity, we need a serious place for package-exchange/market
• and so on.

Let we go more detail.
If I may sum up, the side-effect (known problems) of dynamic package implementation are:

• Commercial component vendor, don't want to share their proprietary source code
• Commercial vendor, maybe want to to share only their binary (compiled) component
• Component (LCL/RTL) in binary format for Lazarus should be available for all platform supported by Lazarus/FPC
• The number for platform supported by Lazarus/FPC is skyrocketing, let say : a component in binary format should be compiled 100 times because of the amount of OS multiplied with Processor multiplied to Widgetset (OS x Processor x Widgetset)
• In fact, current commercial vendor must provide twice of amount above in case to support both FPC 3 + FPC 2.x to gain maximum possibilities of various developer need.
• Finally, Lazarus+binary_(commerical)_packages would be very very very large to download.
• conclusion: That situation can be simplified, can be eliminated by just distribute their (commercial) source code, which is impossible.

Anyway, Lazarus is different from Delphi. The IDE itself can be installed in many platforms. Easier cross-compilation would be nice but it does not really help with component installation. To utilize the full potential of Lazarus all its platforms should be supported, and that requires source code.

Well, the solution by tazz (at least in my own comprehension) is to let the component provider to solve this problem by them self.
It mean: when you open your gate, everyone could enter and join. If you close the gate, nobody would join.
It also mean, component vendor want to say : "don't worry about your 'problem', I have my own solution to run business gracefully over that limitation. When you have solved that, that's better for me too."


So, if I were one of Commercial Component for Lazarus/fpc, Sure I have many solution :

• I can provide all 200 binary combination downloaded from my website (disk is cheap nowdays)
  or keep all binaries in sourceforge or github
• I can provide a few binaries for major platform, and provide addition one by request
• I will provide those binaries for evalutation only, such as will stop running when run outside Lazarus debug, so it only for evalution in debug mode. So only serious/paid user got the source code.
• I can suggest to Lazarus team to provide only my binary to be included in related Lazarus download, so my Win32 binary included in Lazarus for win32 download, not the whole combination. When user require cross-compile, they should download what they need separately from my website by just opening my metapackage file (*.lpk)
• I can provide the download of files needed by cross-compile inside my component via Property Inspector, just similar as About property dialog box +download links, you know.
• Sure, I have many hidden+unpredicable solution over this hard situation, you and I will know when later we make more progress.

It is clear that non-opensource's source code is not a must. The package it self will be.
if we could build a good dynamic-package ecosystem, no matter source code or binary, it would be okay.
IMHO, the only way required by both component's provider + component user is = easy access.


Yes !!!!, it's the good time for Lazarus community to have similar market of Eclipse's MarketPlace, Python's Pypy, or what ubuntu have had.

Meaning: developer doesn't require the whole binaries, just what they need when they need them (such when crosscompiling): the package should be available, somewhere, by easy access (command line, download click?)

Its far better to have a stone axe  ...than to wait around until the copper is discovered, ..

Lazarus/FPC team's sould supply a nice place of what tools/component available in the market for Lazarus/FPC, by providing a dedicated website of this demand. (before somebody else take over this opportunity by stale this great idea) 

[gonz0]

Oh boy this doesn't look good at all. Allen Bauer left (got kicked?) the company and predicts a black future.

https://forums.embarcadero.com/thread.jspa?threadID=176355&start=30&tstart=0

Hopefully Delphi doesn't die

[argb32]

Lazarus/FPC team's sould supply a nice place of what tools/component available in the market for Lazarus/FPC, by providing a dedicated website of this demand. (before somebody else take over this opportunity by stale this great idea) 

It's much better to have a public repository containing available components/libs and a dependency management tool like Pip, Bower or Maven.
The tool could manage binary (.ppu + .o) packages as well as source based.

[JuhaManninen]

Lazarus/FPC team's sould supply a nice place of what tools/component available in the market for Lazarus/FPC, by providing a dedicated website of this demand. (before somebody else take over this opportunity by stale this great idea) 

It's much better to have a public repository containing available components/libs and a dependency management tool like Pip, Bower or Maven.
The tool could manage binary (.ppu + .o) packages as well as source based.

Why so many people here explain what should be done but nobody wants to actually implement those things?