i wanted to start a thread here, because i was thinking about the state of the open source development process of the platform lately. Especially the solution to my problem on this
topic got me thinking about.
So what i thought about here is how the development in the open works from the perspective of an outsider. Since it has been already about 6 month since the first open source release (which i found pretty amazing btw.), i thought we (as a community) should have a conversation about the current state of how we “work” together to bring the platform forward in one form or the other.
For me at least it was especially interesting to see the reasons for open souring the platform in this very
honest and open article.
So, perhaps we can use this thread for everyone to either give their two cents on what could be improved and brainstorm and discuss on ideas.
Here are my opinions on what could be improved:
Generally i looked at an article about successful github development
public issue tracker
This is a point that is quite important in my opinion. I sometimes look at the commit history on github and thinking to myself that it would be quite beneficial to not only look at the result, but also look at the underlying discussion of a commit that it relates to. Since i’m not into the details of the different classes that are part of the commit its quite interesting to look at the commits, but probably not the most efficient way to get an idea what this commit should do or in which context it has to be placed.
Additionally i think it makes it much easier to track which bugs / improvements will make it in which release.
When i look at other open source projects that are developed “in the open” like Spring Data JPA or Rails or EntityFramework, a well structured issue tracker can make a huge difference. I found the term “develop in the open” that a quite good description of the mindset behind this kind of development which i first heard about when Microsoft (Scott Hanselman) annouced .NET as OSS.
What we have here in this forum is in some sense the same idea, but (for good reasons) much more unstructured. I sometimes found it a bit problematic that when a potential bug is contributed, there is no transparent path between the submit and the resolve of an bug (although you lately added comments when implemented in a particular version, which is quite a good starting point).
As i imagine, this is not only one of the most important points, but probably one of the most exhausting things for your to implement as well. Since it requires major changes in the way you work internally and what information are now publicly available and would be afterwards is kind of hard i could imagine.
When i look at it, the project has in comparison to other project a fairly low pull requests to commits ratio.
I think this could potentially be improved by writing down more information about how to contribute,
what types of tests you expect, potential things like coding styles etc.
Additionally a lot of open source projects even encourage participation through something like labels on issues
that indicate good starting points for beginners (in Rails it’s called good-first-patch).
public CI system for testing
having a public CI system for running the tests gives another level of confidence in the project. Additionally its required
when starting to working “in the open”. Since something like travis is for free for open source projects,
it shouldn’t be a big deal, right?
Last thing that comes to my mind for now is the issue of a missing roadmap (as asked here).
Although spotty information are valuable as well, an updated roadmap on a very high level would be very good
to get a good grasp on what is planned in the future, what features will be added and also what features will not be part of the platform
So these are my ideas. I hope not only Haulmont employees could add their opinions here (although i would appreciate that as well), but also users from the outside like me, since my opinions are probably not representitive for the outside world