Unrelated to Delphi, but a good example to follow!
Unrelated to Delphi, but a good example to follow!
http://www.linux.com/news/featured-blogs/158-jim-zemlin/834610-apples-decision-to-open-source-swift-met-with-developer-applause
http://www.linux.com/news/featured-blogs/158-jim-zemlin/834610-apples-decision-to-open-source-swift-met-with-developer-applause
They had to. Good that they did it.
ReplyDeleteI don't mind if they don't open source Delphi (as in free to modify and redistribute) since that might hurt their business model, selling licenses, but I do wish they would 'open the source', as in stick it on GitHub with a commercial-only license or on their own, login-only server, make it possible for us to see it, to modify it, and to submit back changes, which are then quickly accepted and integrated.
ReplyDeleteIf we buy Delphi and have a license, we should see the source; and as a modern, responsive, developer-centric company, they should welcome patches and submissions and accept and integrate them with fast turnaround.
It would strongly help their level of quality, too.
Sure, and we finally see bugs solved!!!
ReplyDeleteWith recent MS decisions that is what Apple had to do. They both are not making the main money with selling developer tools but they want to bind customers to their platforms. And by open sourcing their languages that's a huge step. EMBT is a different story because their entire business is selling Delphi (and other tools).
ReplyDeleteStefan Glienke I'm just not sure that EMBT makes it right...
ReplyDeleteStefan Glienke Yes, Delphi has a different business model, but from my point of view the main problem for the success of Delphi right now is its quality. A lot of Delphi developers (including me) would be happy to contribute if we had the chance.
ReplyDeleteHans Lavdal Jakobsen What quality? The compiler? Missing language features? Stability and features in the IDE? The RTL/VCL/FMX?
ReplyDeleteKeep in mind that they did not open source XCode or VisualStudio code. So we are talking about compiler and libraries/framework here. Every one that bought Delphi has the code and can report any issue he finds and suggestions how to fix or extend that. So we are "just" missing access to the compiler to fix issues there or add new features. And I guess that not many people could be of any help in that area. And even if it would require a significant amount of resources from EMBT to look through changes and discussions with people about why this or that is so and so.
And with the continued leaking of things (like beta builds) even though people sign NDAs I understand they don't want to do anything like that.
Stefan Glienke Sure we all have access to the RTL/VCL/FMX code, but we can't submit patches. And who cares if only a few people would work on the compiler? A few is better than none, and the compiler has so much potential if they would only open it up... You can tell from how the language moves, and how few targets it has, and how split / divided it is, how difficult they must find it to do work on it themselves. Otherwise it would look completely different.
ReplyDeleteI don't see many NDA leaks, but perhaps it's a sign how restrictive and old-fashioned the NDA approach is, that people find it hard to adhere to. "Normal" is that we would all know what's in the next release, and the new normal is that we can all contribute patches and features to it too.
The resource cost to vet and accept patches from developers is part of being a open, modern company. The benefits of getting a large number of new features and bugfixes would far, far outweigh the cost of their allowing it.
More than that, the attitude of being open to developers is part of being a modern company. This is a move they need to make and it's a move they need to make now, not later this year, not next year, not next decade. (I hope they've already had this discussion internally, since ever since MS's move with .Net you could see it coming with Apple and others. So I hope for an announcement soon. But if it came as a surprise to them, then they should start thinking now and announce in July. I hope they (Marco Cantù, Allen Bauer) realise quite how important, and how urgent, a move like this is.)
The attitude of being open to developers is, as you say, an attitude. I don't think there is a mandatory approach in doing that, like having library source on a version control system. You can do that if you have an open source solution, which is something out of the realm of today's possibilities for RAD Studio.
ReplyDeleteI can see the point of customers sending patches, and we do appreciate bug reports with suggestions. However in the real world experience we also know that in many cases those patches solve a specific problem, but fall short as general solutions, so they have to be extensively reworked. At times, the suggested code can send the developer off the best path, and end up taking more time. Would we reject the suggested update and work on a new solution help the relationship? Or would developers get upset that their code is rejected and get into endless discussions?
> The resource cost to vet and accept patches from developers is part of being a open, modern company. The benefits of getting a large number of new features and bugfixes would far, far outweigh the cost of their allowing it.
I disagree. I don't think either Microsoft or Apple are opening their libraries for this reason. They are not looking for contributions in significant terms. They are fighting Java and other more open system, for developers mindshare. And legally, accepting features from users is delicate. Would everyone just give us rights to their work? I really doubt. If a solution is not open source, accepting contributions is not trivial from a legal standpoint.
Overall, I agree there is room for improvement. I think some steps in the right direction have been taken (like the new quality portal). But jumping on the "open source" bandwagon is OK if you are selling something else (phone hardware, operating systems, services, app store access), a little more difficult if that code (compiler, library) is your main company asset.
Marco Cantù Thanks for the reply. I am not advocating jumping on the open source bandwagon at all - I am advocating becoming more open (you own the source, but it is visible to us.)
ReplyDelete> They are fighting Java and other more open system, for developers mindshare.
Aren't you doing this too?
(And one reason for what I'm advocating, apart from being great for us existing developers, is to give an attractive appearance for new developers. I really do think Embarcadero needs to look and behave more modern-ly.)
> And legally, accepting features from users is delicate. Would everyone just give us rights to their work? I really doubt.
Why not? If you contribute back, you sign something saying it is either (a) MPL (a license for which you already can and do include code into Delphi) or (b) assign rights to Embarcadero. That seems a very reasonable requirement for submitting patches back.
> Would we reject the suggested update and work on a new solution help the relationship? Or would developers get upset that their code is rejected and get into endless discussions?
Look to the open source community here - they regularly have contributions from a wide variety of folk, and strict submission quality requirements. It is quite normal to reject a submission for reasons of architecture, code style, introducing bugs, etc -- and what happens here is that the developer will go away and address those problems and re-submit it.
So long as code is rejected for good reasons, I can't see this being a problem...
> a little more difficult if that code (compiler, library) is your main company asset.
I understand, but that's not what I'm advocating. *I don't want you to open-source Delphi.* I would like you you to (please) let us licensed, registered Delphi users, whose names and identities you know, whose money you take, see the source and submit patches and features.
David Millington Understood. I agree you have some good points, but I still thing there are multiple ways to address them. We do accept contributions already, just in a different way.
ReplyDelete> So long as code is rejected for good reasons
That is what worries me. Who determines "good reasons"? Might be tricky, given our developer community
Again, not ruling out this at all. We could possibly try to make easier to submit patches, but there is a way today and it is used a lot (or should I say, already overused?). Let me explain actually. We do get bug reports saying "you should change this code to this code. period." there is no reason why, which problem this is solving and which advantage it is giving. If done because it "seems better", I'd argue against taking the change.
Also we have a flow, QA validation, R&D applying the fix, QA building a test case, doc team updating the doc accordingly, QA revalidating all is good, ship the fix. We certainly don't want to miss any of the steps, with a short-circuit submitter/developer. It might seem a better way to build stuff faster, but it is not a good approach for quality/long terms support/ doc/ etc.
Thanks for the reply. I get what you're saying - I think - you feel that you do accept patches, and that allowing more people to submit more directly (as they would via, eg, git pull requests instead of via code in bug reports in QP) would not result in better quality/support/etc results, long term?
ReplyDeleteI suppose my response is that accepting patches via QP is perhaps possible, but it's not nearly as flexible as allowing people to, eg, have their own branch of the VCL code and simply submit pull requests. In one, code stands alone, is out of context, is separated from the workflow etc; in the other, it's easily integrated, can be seen in context, and integrates with a source control workflow.
I certainly see your concerns with the developer community ;) As well as what makes "good" reasons. But, have clear guidelines? Pull requests without information are refused. Pull requests without unit tests are refused. Pull requests without an attached QP report number are refused. Pull requests from rude people are rejected. Etc. Plus, you're unlikely to get things out of the blue - what if someone files a QP report saying "I'd like this", a developer comments, "Sounds good, we'll add it if you code it" and /then/ someone starts work and starts submitting pull requests? Or some members of the community can get involved in internal future planning discussions, and can code based on what they know you want? Also, perhaps you can limit the community at first - perhaps initially only MVPs, then later only those who apply, then later expanded to those with valid licenses? *Start small, and with the members who are most likely to contribute valuably. See what you get and expand it if the scheme works.*
There's no problem being strict - in fact it's valuable, I'd encourage it! - so long as things that truly are useful or good are accepted. To be honest as a personal comment, the situation that worries me is NIH syndrome on the reviewer's side, not the ability to work to your standards on our side. I think we can do that :)
> It might seem a better way to build stuff faster, but it is not a good approach for quality/long terms support/ doc/ etc.
Doc - sure, I mean every patch adds a documentation cost. (But you know - I want to be able to edit the wiki, too. Seems weird to have a wiki we can't edit.) Support and quality I think is somewhere where we disagree: I think patches submitted by good Delphi developers - and there are lots in the community - would reduce your support cost via reduced problems, and increase your quality level. It doesn't have to sidestep QA either; in fact, separate branches actually make that easier. I'll take one /big/ example of what might be possible: FMX. Suppose we could fork the FMX codebase and refactor it and clean it up, as a community effort? WOW. Plus, accepting patches doesn't mean you have to put all of them into the trunk. You can still merge things into the core product in stages.
My points here are ones of general enthusiasm and "it can work if you try it"-ishness. :)
(You might underestimate the number of people capable of working on the compiler toolchain (or IDE) too. I reckon I could contribute, for example. I can think of several Delphi developers I personally know who would do way better than me too. Let alone others in the community.)
> Again, not ruling out this at all.
:) I don't know how far to take that sentence, but that is great to read. Thankyou.
Marco Cantù I'm with David on this. 20 years ago, only the best developers worked on Delphi, sadly that's not really the case today (only have to look at some of the issues introduced over recent releases).
ReplyDeleteThere's a whole community of experienced high quality delphi developers out there who would be more than willing to contribute. Yes, there are legal hurdles such as contributor license agreements (which can be done by a bot, not that difficult), and organisational hurdles (putting in the right team/management structure) but the benefits are vast.
As with any open source project, you do not have to accept substandard contributions (no matter how well meaning). I rejected a pull request for DUnitX a while back that was full of all sorts of good stuff, because it was too big and hard to merge and the risk too high. I don't think any developers out there who contribute to open source projects think their code is perfect, and we've all had pull requests declined over the years (probably for good reason), it's how it works, there are no guarantees that if I work on something it will be accepted.
There are plenty of open source projects that have high standards before contributions are accepted. If clear rules and guidelines exist then I see no reason why it couldn't be the same for delphi. A lot of the projects I use have a policy that any change has to have unit tests that cover the affected area to show that it is safe.
Obviously, Embarcadero needs to get something out of this, ie have something left that customers would still purchase. As much as I'd love to get my hands on the compiler source code and fool myself into thinking I can add the language features I've always wanted , the reality is it's a highly specialised field and probably best left to the experts.
It's a delicate balancing act.. I think open sourcing the VCL and FMX would be a great way to advance the frameworks whilst also getting a lot of long standing quality issues resolved. I would imagine that over time, some of embarcadero's resources could be redirected towards the compiler and IDE teams..
Stefan Glienke The open sourcing of Swift has little to do with MS. Swift was always going to be open sourced. This was clearly stated when the language was first announced.
ReplyDelete